八宝书库 > 文学其他电子书 > 软件工程实践者的思想(PDF格式) >

第10部分

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

小说: 软件工程实践者的思想(PDF格式) 字数: 每页4000字

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 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 ,还包括准确地评估他的工作量,以及决 



      定是否为他增加一个( 能协同工作的) 副手;  



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



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



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



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



      一项目的风险;  



   )  不要乐观。  



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



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



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



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



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



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



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



及与每一个团队成员交流

返回目录 上一页 下一页 回到顶部 0 0

你可能喜欢的