软件工程实践者的思想(PDF格式)-第7部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！





京做一个名为“Delphi　&　Delphi　　源码分析”的专题　



培训。我用了近两周的时间，做了　50　　页的幻灯，全面讲　



述　Delphi　和　Delphi　　。然而在临行前的一晚，我辗转　



反彻，总是在思考一个问题：我究竟做了些什么？或者说，　



我究竟想告诉学员些什么？　　



　　　　凌晨　5　点，我在幻灯的末页后插入了一张幻灯，标题　



是“语言只是工具”，而幻灯的内容是一张图：　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　



　　　　这是与培训完全无关的一张幻灯。然而，这是自从　



1997　年我接触到管理，以及从　1998　年我接触到工程以来，　



我第一次正视“软件工程”这四个字。我第一次看清楚代　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…70


…………………………………………………………Page　75……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



码、方法、过程、工程与组织的关系！　　



　　　对于一个程序员，或者以程序员自命的人来说，看清　



楚这一切的第一步，竟是一句“语言只是工具”！　　



　　　　　



　　　猿之于为人，“学会制作和使用工具”是最重要的标　



志。因而我不知道“语言只是工具”这句话，究竟是对语　



言的膜拜，还是漠视。　　



　　　然而从那一刻开始，我才真正地知道工程。　　



　　　2。　　　程序　　



　　　上面的这个图中，在最内层的环里，是“程序＝算法　



＋结构”。这是编程的本源定义，也是原始的状态。与代　



码相关的任何工作，最终仍旧会落足于这样的一条规则。　　



　　　编程的精义于此。从有开发行为开始，它就存在了。　



愚公在数千年前就在用类同的行为做编程实践，而几十万　



年前智人，也在循环与分支所构成的逻辑中打转。　　



　　　3。　　　方法　　



　　　推动这种逻辑向前发展的，是“方法”和“方法论”　



的出现。长期的编程实践，自然的归演与总结，必须沉淀　



为某种（软件开发）方法，于是“过程”出现了，于是“对　



象”出现了，于是相关的方法论也就出现了。　　



　　　这是实践的成果。方法不是某个人或者某个组织创造　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…71


…………………………………………………………Page　76……………………………………………………………

第　6　章　　从编程到工程　　



的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出　



某个方法，IBM　也会提出这个方法。即便他们都不提出，　



可能你自己已经在使用这个方法了。　　



　　　方法并不神秘，因为它就是你今天正在做的、从事的　



和实现的。正如“模式”是一种方法，而模式就是你昨天　



书写代码的那个行为。只不过，GoF　归纳、抽取、提升了　



这些行为的内在规律。　　



　　　你看不到你做事的行为，也就不能理解“模式”作为　



一种方法的价值。所以大师们众口一词：模式需要一定的　



编程经验才能理解。　　



　　　同理，理解过程也需要编程经验，理解对象也需要编　



程经验，理解　MDA　与　SOA　还是需要编程经验。　　



　　　——这可能就发生在你去回顾你上一行代码编写的　



经过，或者上一个项目失败的经历的那一瞬息。经验来源　



于回顾、理解与分析，而不是你将要写的下一行代码。　　



　　　　　



　　　有人在寺院扫了一辈子的落叶而得道，也有人因为一　



句话而得道。　　



　　　GoF　　因为无数次的代码回顾而得道。　　



　　　4。　　　过程　　



　　　过程伴生工程而出现。过程解决的是工程中角色间的　



关系问题。　　



　　　过程说的是很多的人（　团队）　如何组织在一起进行开　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…72


…………………………………………………………Page　77……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



发的问题。它首先把工程中的环节分解出来。这样，有了　



环节，就有了角色；有了角色，就有了沟通。　　



　　　　因此过程中的问题，就是角色、沟通和环节的问题。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　



　　　　哪些环节重要取决于具体的编程行为，也就是具体的　



项目。　　



　　　　例如产品开发的周期可以一再拖延，因为对产品来　



说，更重要的品质和技术壁垒。因此你可以看到暴雪公司　



的游戏总是一再跳票，而它从来都是将大幅的玩家测试和　



开发人员的个性特征放在第一位。相应的，DOOM　　　　　　　　　　　　　　　　　　　　　　　　与　



QUAKE　系列的灵魂就是在游戏引擎的开发和设计上。　　



　　　　如果用这样的模式去做项目，可能软件公司没死掉，　



工程需求方也被拖死掉了。——你有看见客户因为你对技　



术的远景描述而憧憬吗？不，你只会看到他们因为项目的　



一再延迟而懊恼，而沮丧，或……暴怒。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…73


…………………………………………………………Page　78……………………………………………………………

第　6　章　　从编程到工程　　



　　　　憧憬这种事情，只会发生在那些个铁杆玩家的身上。　　



　　　　分不清玩家与客户的区别，对项目经理来说，是可怕　



的。这将意味着他不能清楚地知道哪个环节更加重要。　　



　　　　　　



　　　　角色的确定，以及角色间的沟通问题，在项目过程中　



也同样重要。工程组织是否合理，相互的协作是否紧密，　



是这个项目成功能的保障。　　



　　　　　“合作无间”通常是流于书面报告中的措辞。真正的　



　“无间”，应当是沟通的结果。然而UML　，则可能是你与　



客户，以及项目经理与开发人员被“离间”的第一因素。　　



　　　　5。　　　工程　　



　　　　最狭义的工程，是描述“做什么”和“做到什么”。　　



　　　　也就是说，是对目标的描述和成果的检测。至于这个　



工程目标的实现，是“过程”和“方法”的事；而有效、　



快速地实现“过程”和“方法”所需的，就是“工具”。　　



　　　　这　种　软　件　工　程　体　系　层　次　（Software　　　　　Engineering　　



Architectural　Layers）被描述成一张图，我很有幸地在第一　

次画它的时候①　，画成了一堆牛屎。因此我从此都把它叫　



　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　在　2001　年进行一次公司的内部培训时，我在幻灯片中画下这张　



图。半年后，我去北京读研时又看到了它，不过是画在《软件工　

程——实践者的研究方法》这本经典巨著中，第四层的“实现对　

象”是叫做“质量焦点”，名字则是“软件工程层次图”。其实所　

谓“经典”也是对既有知识的总结。大师们所知的，与你所思考　

的未必就有天壤之别。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…74


…………………………………………………………Page　79……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　“牛屎图”：　　



　　　　　　　　　　　　　　　　　　　　　　　工具　　

　　　　　　　　　　　　　　　　　　　　　　　方法　　



　　　　　　　　　　　　　　　　　　　　　　　过程　　



　　　　　　　　　　　　　　　　　　　　　实现对象　　



　　　　　　　　　　　　　　　　　　　　　　软件工程　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　



　　　　过程伴随工程而出现，解决的是工程中“步调一致”　



的协作问题。那么工程是因为什么而出现的呢？　　



　　　　很显然，软件规模的不断增大是根本的原因。所以你　



会看到在几年前的时候，开发一个小工具可以不讲工程；　



或者现在在你的　WORD　　　　　　　　　　中，为了将半角替换成全角字符　



而写的那个宏，也不需要工程。　　



　　　　　　



　　　　接下来，即使软件规模增大，如果有一个牛人中的超　



牛人，愿意用　20　年来写一个任意庞大和复杂的操作系统，　



他也是能做到的。然而现实中不会有软件公司给他这样的　



机会。　　



　　　　项目的“复杂”可能要求不同的知识领域的角色参与，　



而“庞大”则要求更多的（人力、技术与管理）　资源。“团　



队”作为开发行为的模式，是软件规模和复杂度渐次累积　



的结果。　　



　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…75


…………………………………………………………Page　80……………………………………………………………

第　6　章　　从编程到工程　　



　　　　团队必将越来越庞大，因为（与工程对应的）软件规模　



必将越来越复杂。没有团队意识的软件公司将在高度过程　

化、通晓方法理论①　、拥有大量工具的集团军面前必将一　



　　　　　　②　

触即溃　　。　　



　　　　6。　　　组织　　



　　　　工程理论其实是包含组织学的。然而我在上面的那张　



图中，将组织与工程分离开来，并在二者之间画下了一道　



纵向的线。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　《三十六计》更多的时候是被当成方法论来读的。其根源在于　



　“计谋”本身只是方法，而不是战略。　　



②　　　如今这样的战役正在国外软件与国内软件之间进行着。而战局，　



并不是民族热情或者政府保护可以扭转的。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…76


…………………………………………………………Page　81……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



　　　如果说工程关心的是“需求”、“配置”和“文档”等　



等这样一些要素，那么这样的工程还是停留在技术层面　



的：关注的还是工程的实现细节，而非目标。从角色的角　



度来看，这是项目经理和技术经理所共同关注的那一部　



分。　　



　　　然而项目经理还必须关注于人力资源、项目资金以及　



多个项目之间的协调等等。这些与工程本身并没有直接关　



系，而是“组织”方面的内容。　　



　　　所以在工程环节中“文档管理”和“配置管理”等等　



中的那个词汇“管理”，是管理的具体技术和方法；而在　



　“组织”这个环节中的这个“管理”，才是真正的管理学　



上的用词。　　



　　　我在这张图上，试图从这个角度上来说明：作为项目　



经理，你必须有一部分的工作是非技术性的。甚至，你可　



能绝大部分的工作是非技术性的。——因为与技术相关的　



管理技能（　需求、配置、过程管理等）可以由开发经理来做，　



或者公司对于这一方面有较统一且成熟的规范，因而无需　



投入过多的精力。　　



　　　你必须更关注于对这个（或这些）工程的组织与计划。　



站在“组织者”这个角色上，你现在要考虑的内容可能会　



是：　　



　　　）　　为项目的各个阶段建立计划，并逐渐地细化计划　



　　　　　的内容，以及确立项目过程中每一个环节、每一　



　　　　　个计划阶段的优先级和复杂度；　　



　　　）　　确立项目或者产品阶段目标，成果的准确描述、　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…77


…………………………………………………………Page　82……………………………………………………………

第　6　章　　从编程到工程　　



　　　　　　定位，以及整个项目的质量目标及其评核办法；　　



　　　）　　对团队中的不同角色展开培训，以指导并协调角　



　　　　　　色间的工作，从而消除因为工作习惯的差异带来　



　　　　　　的影响；　　



　　　）　　为每一个人准备他所需要的资源，这不单单是把　



　　　　　　一套　shareware　变成正式版或者把　512M　　内存变　



　　　　　　成　2G　，还包括准确地评估他的工作量，以及决　



　　　　　　定是否为他增加一个（　能协同工作的）　副手；　　



　　　）　　决定在哪些环节上反复审核和回顾，而在哪些环　



　　　　　　节上采用较为宽松的方式以加快进度；　　



　　　）　　习惯于开会、组织更短而有效的会议以及建立激　



　　　　　　励机制，当然也不要忘记让每一个成员意识到这　



　　　　　　一项目的风险；　　



　　　）　　不要乐观。　　



　　　即使你做好这一切，可能项目的结果仍然不够理想。　



但是你应该知道，好的项目经理并不是不犯错误的人，而　



是以尽可能少的失败来获得成功的那个人。　　



　　　无论是你的团队成员，还是你的老板，对重复的错误　



以及可预料的错误都是不会宽容的。——在一个团队中，　



失去了组员的信任比失去老板的信任更为可怕。　　



　　　所以回顾每一个项目，或者项目中的每一个阶段，以　



及与每一个团队成员交流的细节，是你的日常工作。　　



　　　7。　　　BOSS　　



　　　很多人以为　BOSS　是给自己发钱的那个人，这其实是　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…78


…………………………………………………………Page　83……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



错误的。发钱的决策通常是由三个角色来做出的：　　



　　　　）　　部门／团队经理。你的直接上司，他是雇佣你的　



　　　　　　　人，是他用薪金的多少来衡量你的价值，或者反　



　　　　　　　之。　　



　　　　）　　纪效经理。如果你的公司有这个角色的话，那么　



　　　　　　　他总是盯着你的错误以决定从你的薪水里的扣　

　　　　　　　除比例①　。　　



　　　　）　　财务经理。有钱？没钱？没钱？有钱？……　　



　　　　BOSS　并不决定你的薪水。　　



　　　　　　



　　　　BOSS　在公司中解决的是“经营”问题。这其实是在　



比“组织”更靠外侧的一层。——在前面的图例中并没有　



给出，这也意味着“经营者”与“工程”基本没有关系。　　



　　　　在一个更大规模的组织机构里，你可以会更直接地观　



察到“经营者”与“组织者”之间的差异。例如公司的大　



小股东是“经营者”，董事会通常是解决经营问题的地方；　



而总经理、执行经理以及各个部门经理则是各级的“组织　



者”，经理办公会则是解决组织问题的地方。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　②　

　　　　你应该清楚，真正的BOSS　是经营者　　。　　



　　　　这有助于你明确你被雇来的原因，你的工作是面向哪　



一个层面的，以及你或者你的上司有没有权限来决定是一　



个项目是否应该立项，或中止。　　



　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　顺便告诉你一个秘密，给予你奖励的决定通常是你的上司，而　



不是纪效经理作出的。　　

②　　　不过，可能你仅受雇于你的上司，你习惯于把他叫作BOOOOSS　



则是另外一回事。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…79


…………………………………………………………Page　84……………………………………………………………

第　6　章　　从编程到工程　　



　　　　　　



　　　　BOSS（　经营者）　决定了一个方向，组织者保证决策与　



这个方向是同步的，而工程是在这样的一个方向、决策的　



构架下的一个具体行为。　　



　　　　工程中没有　BOSS　。　　



　　　　8。　　　上帝之手　　



　　　　从最初的简单编程开始，到现在工程团队的组织开　



发，实现（一个软件）都是最终的目的。所以可以这样说：　



实现，是软件开发的本质需求。　　



　　　　　　



　　　　我们看到，正是出于实现的需要，我们才设计了一些　



数据结构或逻辑结构来映射物理模型。因此类似于过程、　



单元、记录（结构）　、对象等的出现，其实都是出于编程实　



现的需要：　　



　　　　　　　　　　　　　　　程序　　=　　　算法　　＋　　　结构　　　　



　　　　　　　过程与单元的出现　　　　　　　　　　　　　　记录与对象的出现　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　而后，基于某种数据结构的编程实践（　的不断积累）　，　



决定了软件开发方法理论的产生。　　



　　　　从这一点可以看出：方法，是对既有行为的归纳总结。　　



　　　　因而实现方法总是最先出现的，而后才有分析和设计　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…80


…………………………………………………………Page　85……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　



方法。　



　　　　可以看到面向对象分析（OOA）　、设计（OOD）　与编程　



（OOP）　的出现顺序，与它们在工程过程中的实作顺序正好　



相反，而与编程实践行为的顺序则正好相同。　



　　　　为了实现更大规模的软件系统而有了团队组织模式，　



而团队的协作决定了过程模型的产生，在过程环节中的沟　



　　　　　　　　　　　　（　　　　　）　

通问题导致了　模型化　语言的出现。　



　　　　如同编程工具中的编译器和集成开发环境（IDE）　一　



样，开发中的编程语言、过程中的模型语言都只是一种工　



具。　



　　　　　　　　　　甲骨文　　　　　　象棋　　　　　　　石头　　



　　　　　　　　　：　

　　符号语言　文字　



　　　　　　　　　　　　　　　：　

　　最自然的沟通方式　语言　



　　项目案其实是可以用甲骨文来写　

　　　　　　　　　　　　　的　



　　　　　　　　　　　图图形形也也是是一一种种符符号号文文字字　　　



　　　　　　　　　　　　　　　　　　　　　　　模模型型也也是是一一种种符符号号文文字字　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）　

　　　　工具的产生仍旧是出于　“（软件　实现”的需要。不可　



能从软件开发实践中产生出轮子和指南针，因为那不是　



　“软件开发的本质需求”可以推动的。　



　　　　软件工程的体系中，“实现”作为软件开发的本质需　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…81


…………………………………………………………Page　86……………………………………………………………

第　6　章　　从编程到工程　　



求和基本动因，如同上帝之手在推动这几十年来的软件工　



程理论体系的形成。　　



　　　　　　　　　　　　　　　　　　　　工具　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　方法　　　　　　　　　　　　　　　因　动　　本　基　



　　　　　　　　　　　　　　　　　　　　过程　　



　　　　　　　　　　　　　　　　　实现对象　　



　　　　　　　　　　　　　　　　　　软件工程　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…82


…………………………………………………………Page　87……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　第7章　　现实中的软件工程　　



　　　　　“王不如远交而近攻，得寸，则王之寸；得尺，亦王　



之尺也。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《战国策．秦策》　　



　　　　1。　　　大公司手中的算盘　　



　　　　从最早仅仅关注于软件开发工具到现在，软件行业中　



的巨头们已经在层出不穷的思想中涅槃了一回又一回。　　



　　　　R