友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!
富士康小说网 返回本书目录 加入书签 我的书架 我的书签 TXT全本下载 『收藏到我的浏览器』

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

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



?…………………………………………………………Page 1……………………………………………………………

                                             



                                          



大 道 至 简   



                                         ——软件工程实践者的思想  



                                                                                      



                                                                                      



                                                                                      



                   周爱民(Aimingoo) 著  



    


…………………………………………………………Page 2……………………………………………………………

                          



                    序  



      



    2004 年 11 月初爱民(Aimingoo)第一次把他的书稿给 



我,我翻看了一下,第一反应讲的是感想。这不错,在技 



术界就是需要有真正实践经验的专家把他的思考和心得 



与我们分享。Aimingoo  在 Delphi  领域颇有名气,其技术 



钻研的深度直达系统核心层,从其著作《Delphi 源代码分 



析》可见一斑。不过接下来第二反应就是太薄了,能不能 



加厚啊。比如说这些感悟都是有其来源的,可以把实际案 



例啊,背景故事啊都加上。不然太薄了,出版社没有办法 



出版啊。——国家对于出版的书号是有严格控制的,所以 



书号是有成本的。一本讲技术高端的图书销量肯定是有限 



的,以现实情况而言,如果很薄定价就只能比较低,成本 



无法回收。而且内容只是心得,没有案例,读起来也很硬, 



对读者的要求也很高,销量可能就更少了。  



    爱民听完我的意见,还是坚持这本书就是这样的风 



格。出厚书违背了他的本意,要不然怎么叫“大道至简”。 



书稿在 2005 年 3 月杀青后,我从 7  月开始在《程序员》 



上陆续选择其中的三章发表,看看读者的反馈。不过限于 



篇幅,删掉了一些内容,不能完整体现出作者系统思考的 



脉络,也比较遗憾。  



    2005 年 11 月爱民跟我讨论到即使没有出版社愿意出 



版印刷,也要把他的作品用电子版问世,并邀我作序。我 



十分感慨,在这个浮躁功利的社会,难得还有这样的朋友。  



  


…………………………………………………………Page 3……………………………………………………………

                       



   现在,我又仔细从头到尾读了一遍。很多作者写书是 



为厚而厚,大部分内容都是水分,作者原创经验精华只有 



很少,甚至没有。而这本书是作者从事十年开发工作的总 



结,虽然不厚,却闪烁着独立思考的光芒。  



   世界“虽变化万端,而理为一贯。”作者在软件开发 



一线浸淫近十年,回头思考何为开发的本源?这些理论、 



方法的本质为何?粗粗一看,这些道理稀松平常,专家教 



授无数著作早就谈过,还用作者来写吗?其实不然,理论 



都是从实践而来,但我们学习软件开发的时候,是先掌握 



这些专家总结的果实,而不是探求本源,所谓“知其然而 



不知其所以然”。这些道理看似都知道,但却没有真正体 



会上身,在实践中最重要的去应用这些道理,而不是方法。  



   大多数人看书都希望学到一些招数、方法,能尽快在 



工作中用上,这是不错。但要想真正达到更高境界,就必 



须明白背后的道理。真正的专家是从根上解决问题的,所 



以大物理学家杨振宁在北京大学针对本科生讲物理学,讲 



得深入浅出,大受欢迎,就是因为杨先生可以从历史本源 



来剖析物理定律公式。  



   只有招数,不明道理,碰到变化的情况,就束手无策 



了。而在软件开发中,每个团队、每个项目都不是尽然相 



同的。明白道理,才能知变通之道。    



   这本小书不是一本教你项目管理,软件工程或者编程 



技巧的书籍,他是一本闪烁思考光芒的技术散文集,我衷 



心祝愿这本书的读者,能把这本书当作一位朋友的思考, 



     


…………………………………………………………Page 4……………………………………………………………

                                 



一位朋友的总结,来参照自身,这样就会有收获,有想法 



了。  



     我也和爱民建议,这本书的很多主题还可以展开,无 



论是批评,还是讨论,只要有兴趣的朋友,可以给爱民, 



我或者《程序员》杂志社写信,我们诚恳邀请各位来共同 



思考,共同把实践经验与大家分享,这样意义也就更大了。  



     期望大家的参与,谢谢。  



       



                                                      蒋涛  

                                              2005.11月  

                                      jiangtao@csdn  

  

  

注:关于书的序的讨论,参见附录之一。  



  


…………………………………………………………Page 5……………………………………………………………

                            



           电子版发布前言  



      



    我终于决定发布这本书的电子版了。  



    完成这本书的时候,我已经在这个行业里做了十年 



了。这十年来,我对自己的经历做过两次回顾。第一次是 



关于技术的,这造就了那本《Delphi             源代码分析》,是讨 



论开发的技术和方法细节的。第二次就催生了这本《大道 



至简》,讨论的则是工程、管理中的思想。  



    我其实是很希望这本书能放在读者的书架案头,而不 



是放在电脑的某一个目录中。因为它应当是一本可以阅读 



和品味的书,而不是在电脑中备查的技术资料。  



    然而,我在决定担任这家公司的软件架构师的同时, 



我就意识到,我没有足够的精力来运作这本书。——我的 



意思是如果要把他做成纸质的书的话,我没有足够的精 



力。  



    出版商是要寻求利润的。——于此,我一早就知道。 



但我从来不知道:到底一本书簿一点或者厚一点,哪个会 



让出版商更有利润。  



    我只想写一本“阐明软件工程的思想核心”的书。这 



本书要很容易就读明白,还要很容易就想通,还要很容易 



就知道:工程其实很简单,只是大家把它做复杂了。  



      



     


…………………………………………………………Page 6……………………………………………………………

                             



    然而问题是:我把它写得太简单了,以至于只写了 



110 页,就没有必要再写下去了。  



    我当然可以把一本书写得很复杂,或者很厚。这很容 



易,就如做 Coder 一样:把代码写烂或者写乱都很容易, 



要想写得简洁却远非易事。  



    代码写得太简洁,老板会认为你在偷懒;书写得太薄, 



出版社就不愿意出。我看来是忘掉了侯捷先生说过的“买 



书如买纸”,以书的厚薄来论价值的故事。  



    忘掉了就忘掉吧。好的一面是现在书变成了电子版, 



大家终于可以读到它了。不好的呢?我想大概不要钱的东 



西很难得到珍视吧:如果下载这本书只是因为收集,而不 



是阅读,那会是让我感到比讨论“买书如买纸”这样的事 



更为难过的。  



    好吧。希望你能象对待纸质书籍那样来阅读这本《大 



道至简》。放心,我并不介意你把它打印出来放在床头。  



    补充声明:我保留在传统媒体(书籍、杂志)上刊载、 



出版本书的权利。但允许任何人在网络上非商业性地、自 



由地、不加修改地传播这本书的电子版本。  



  



  



周爱民 2005年10月14日  

http://doany/ 

mailto:aim@263 



  


…………………………………………………………Page 7……………………………………………………………

                                            



                              目              录  



        



1。 编程的精义  



   1。    编程的精义 ······················································· 11  



   2。    会或者不会写程序 ············································· 13  



   3。    程序  =   算法  +   结构 ········································ 14  



   4。    语言 ·································································· 16  



   5。    在没有工程的时代 ············································· 16  

  



2。 是懒人造就了方法  



   1。    是懒人造就了方法············································· 18  



   2。    一百万行代码是可以写在一个文件里的 ············ 20  



   3。    你桌上的书是乱的吗 ········································· 23  



   4。    我的第一次思考:程序=算法+ 结构+方法 ·········· 25  

  



3。 团队缺乏的不只是管理  



   1。    三个人的团队 ···················································· 29  



   2。    做项目  =   死亡游戏  ?······································· 31  



   3。    做 ISO 质量体系的教训 ····································· 33  



   4。    谁动摇了你的制度? ········································· 36  



   5。     “那我们就开始开发吧”·································· 38  



   6。    组织的学问:角色 ············································· 39  



   7。    跟随蚂蚁。但不要栽进蚂蚁洞里。 ··················· 42  



   8。     “什么是增值税发票?”·································· 44  

  



       


…………………………………………………………Page 8……………………………………………………………

                                                 



4。 流于形式的沟通  



    1。    客户不会用 C ,难道就会用 UML  吗?·············· 48  



    2。    项目文档真的可以用甲骨文来写 ······················· 50  



    3。    最简沟通 ··························································· 53  



    4。    为不存在的角色留下沟通的渠道 ······················· 57  



    5。    流于形式的沟通 ················································ 60  

  



5。 失败的过程也是过程  



    1。    做过程不是做工程 ············································· 63  



    2。    做过场 ······························································· 65  



    3。    实现,才是目的 ················································ 65  



    4。    过程不是死模型 ················································ 66  



    5。     “刻鹄类鹜”与“画虎类狗”·························· 69  



    6。    工程不是做的,是组织的 ·································· 71  

  



6。 从编程到工程  



    1。    语言只是工具 ···················································· 73  



    2。    程序 ·································································· 75  



    3。    方法 ·································································· 75  



    4。    过程 ·································································· 76  



    5。    工程 ·································································· 78  



    6。    组织 ·································································· 80  

    7。    BOSS································································· 82  

    8。    上帝之手 ··························································· 84  

  

  



  


…………………………………………………………Page 9……………………………………………………………

                                             



7。 现实中的软件工程  



   1。    大公司手中的算盘 ············································· 87  



   2。     回到工程的关键点············································· 92  



   3。    思考项目成本的经理 ········································· 94  



   4。    审视 AOP ·························································· 97  



   5。    审视 MDA ························································100  

  



8。 是思考还是思想  



   1。    软件工程三个要素的价值 ·································103  



   2。    其实 RUP 是一个杂物箱 ···································104  



   3。    UML 与甲骨文之间的异同 ·······························105  



   4。    经营者离开发者很远,反之亦然 ······················106  



   5。    矛盾:实现目标与保障质量 ·····························107  



   6。    枝节与细节 ······················································108  



   7。    灵活的软件工程 ···············································110 



        


…………………………………………………………Page 10……………………………………………………………


…………………………………………………………Page 11……………………………………………………………

                               



            第1章  编程的精义  



     



      “虽我之死,有子存焉;子又生孙,孙又生子;子又 



有子,子又有孙。子子孙孙,无穷匮也。而山不加增,何 



苦而不平?”  



                   ——《愚公移山》,《列子·汤问篇》  



     



1。  编程的精义  



   仅仅就编程序来说,实在是一件很简单的事,甚至 



可以说是一件劳力活。两千年前的寓言中,已经成就 



了一位工程名家:愚公。在这位名家的身上,浓缩了 



项目组织者、团队经理、编程人员、技术分析师等众 



多角色的优秀素质。他的出现,远远早于计算机发展 



的历史,甚至早于一些西方国家的文明史。  

     

    汤问篇中所述的愚公移山这一事件,我们看到了原 



始需求的产生:  



    “惩山北之塞,出入之迂”  



   我们也看到了项目沟通的基本方式:  



    “聚室而谋曰”  



   然后,我们看到愚公确定了一个项目的目标:  



      

                                                …7 


…………………………………………………………Page 12……………………………………………………………

第 1 章  编程的精义  



   “毕力平险,指通豫南,达于汉阴”  



   并通过研讨,择定了一个井然有序的、可以实现的 



技术方案:  



   “扣石垦壤,箕畚运于渤海之尾”  

     

   在这个项目中,动用了三名技术人员和一名工程管 



理人员:  



   “( 愚公) 率子孙荷担者三夫”  



   并获得了一名力量较弱,但满富工作激情的外协:  



   “邻人京城氏之孀妻,有遗男,始龀,跳往助之”  

     

   基本上,这已经描述了“愚公移山”整个工程的概 



况。接下来,我们应该注意到愚公作为编程人员的基 



本素质。在与“河曲智叟”的对答中,他叙述了整个 



工程的实现程序:  



   “虽我之死,有子存焉”,这里描述了可能存在的 



分支结构,即“IF ”条件判断。  



   “子又生孙,孙又生子;……子子孙孙,无穷匮也”, 



这里描述了完成这个工程所必须的循环结构。  



   作为优秀的程序分析师,愚公论述了这个循环的可 



行性:由于“山不加增”,所以条件“山平”必将成立 



(  “何苦而不平”) ,所以这不会是一个死循环。  

     

 
返回目录 下一页 回到顶部 9 9
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!