代码改变世界

梦断代码阅读笔记3

2016-06-16 09:35  LUXIN123  阅读(193)  评论(0编辑  收藏  举报

                                                                                 

读完《梦断代码(Dream In Code)》样书,我感觉心情有点沉重,Chandler项目的结局,它失败了,它成了众多失败软件项目中的一个。这个结局让那个我感受到软件实在是太难了,对我来说软件业的大牛是无所不能的,几乎所有的问题都可以解决,然而我错了,我并不能理解写软件的艰辛,虽然他们失败了,但是我从心里佩服他们。
 
    今天的软件项目,已经成为一个错综复杂的建筑工程,不断变化的应用环境(包括使用者),使得软件需求被不断更新,今天100个需求,明天减10个、改5个、加80个,这在不断公开发布的升级版开源软件以及Web网站应用中表现的就颇为明显。为了满足这种需求及由此需求所带来的编程及调错成本,人们已经发明了众多方法,比如一旦项目被人们认为足够“大”,就用面向对象来代替面向过程,以及使用面向对象所衍生的面向组件-----但所有的这些,面对复杂的外部需求,程序员们感到还是远远不够。
 
     《梦断代码》里同样在反映这个现实,描述了大量导致软件项目进展困难的问题。作者无法给出一种灵丹妙药,甚至没有表达太多自己对于解决问题的倾向性意见。但其中提到了一种案例是“实用最小主义”:尽量少的人。这意味着沟通成本的降低,意味着更容易较为完整的相互理解彼此的思路,意味着软件团队开发中涉及最复杂的因素“人”的问题在理论上的减少。尽量少的时间。这意味着人出于谨慎原则会更青睐于选择自己最熟悉的解决方案,这里的解决方案指的是平台、框架、思路等等。尽量少的功能。这意味着只能选择最有把握实现且最为贴近根本需求的功能。大多数软件工作人员在继续研究和创造新的方法论,这种“实用最小主义”的论调对他们来说显然是一个保守以求项目安全的方案,归根结底,它是在减少问题的理论上限和发生的概率。
     我倒愿意多考虑一些乐观的因素,这么多年来,积累的方法实际上已经大大提高了我们解决问题的能力,类库和框架越来越庞大的同时也的确在为我们减少问题。“实用最小主义”这样的条款和“方法论”并不冲突,他们总是在相对的变化,也就是说,随着方法论的不断完善扩充,“实用最小主义”的门槛实际上也在不断提高:今天一个被3名程序员认为棘手的功能,可能2年后一个程序员独立就可以轻松在某个框架上完成。
 《梦断代码》中对软件工程所面临的种种困难与艰难的描述,即便再过5年读也许都不过时。因为正如原作者所说,书中描写的是一队人马并肩扛起代码大石,虽历经磨难仍欲将其推上山顶的故事,而正是这种故事成就着今天全世界亿万台服务器和PC机上运行的各种软件,成就着人类不断超越实现更伟大的梦想。