没有魔法——《梦断代码》0~3章读书笔记

  在长达半个世纪的研究和实践之后,编程已不再处于萌芽期,但是为什么还是很难做到按时限、按预算做出计算机软件呢?《梦断代码》的第0章首先表达的作者的困惑——软件难做!现实的世界可能并没有魔法和奇迹的出现,正如布鲁克斯所声称的:“无论编写计算机程序是如何令我们倍感挫折,也永远无法找到一种魔法般的突破——我们只能期待渐次前行。”

  正如第1章所展示的那样,项目开发的过程中有诸多的问题困扰着项目经理和程序员,比如说“黑洞”、“蛇”等问题。“黑洞”指的是充满不确定甚至不可知因素的时间陷阱。“蛇”并非只是难题,而是一种“大家没能一致同意如何解决的问题”。与此同时,软件开发的进度并不是能够预料的。在软件开发项目中暗藏有一条线缆。线缆系紧时,进展迅速。线缆断开时,工作停滞。对于改进软件开发所做的努力,都是为了让线缆保持系紧。既然项目的进度难以预料,就非常有可能出现项目延期,这种情况出现之时,古今中外的项目经理通常是如何决策的呢——搬救兵、加人手。无可厚非,这是通常意义上正常人都会想到的办法。然后,布鲁克斯却提出了相反的看法,那便是著名的布鲁克斯法则:往已延误的项目中补充人力,只会使其继续延误。人生仿佛充满了绝望。然而开源方法的出现带来一丝曙光:“杂乱”、集市风格的做法,也可用来制造大型、有用、不断改进的软件。在开源领域,有一种说法叫“眼球足够多,缺陷无处躲”,这就是“李纳斯法则”。在《大教堂与集市》中,更多的体现于看到互联网和托瓦茨式的领导方式在让接触源代码更具有价值方面的重要性,而不在于解释为什么应该让程序员接触源代码。令人遗憾,《大教堂与集市》并未解决软件开发中的时间难题。它只是描绘了一个理想的编程世界:时间无关大局,志愿者们因为乐趣和自我而协同工作,不求物质回报。

  第2章首先介绍了卡普尔早年做出的著名应用——Agenda.用户不用关心软件的存储结构,只管输入数据就好;用户应该能够容易地扩展和修改数据结构、添加新分类,且不会导致数据丢失;用户应该能够用自己创建的新方式查看数据——也可以在自己创建的视图中操作和修改数据。Chandler项目在一开始,卡普尔就确立了三个要素:它应当开源;它应当挠到Exchange的痒处;它应当继承Agenda之精髓。至于开源,“传统软件就像是魔法。历史上,魔法最终消亡了。历史将在软件开发中重演。当问题趋于严重,就不能允许个人或个别公司保有秘密。应该让所有人共享知识。”在设想Chandler项目之初,卡普拉并没有做到“理智上悲观,意志上乐观”这种二分法头脑,而是一个纯粹的乐天派。

  程序“几乎全是纯思考”的产物,但不会永远停留在思考阶段,否则就什么也做不出来了。程序员从思维的沃土上摘取点子,再用一行行具有实际功能的代码实现它——让它在计算机世界中“有了居所和名字”。这就是第3章阐释的内容——Chandler项目之初的技术选型。首当其冲的就是编程语言的选择。比较一番之后,项目最终采用了Python,这一当时看起来并不是很成熟的语言。Python具有高级语言的特性,面向对象,高度抽象,语法简单,边解释边运行。虽然Python在速度上差强人意,但是项目组押宝在速度上——这种语言本身能给予OSPF程序员的额外速度,以及摩尔定律给予最终用户机器的额外速度,希望能抵消Python自身的性能疲软。

 

posted on 2018-09-23 17:01  kathos  阅读(116)  评论(0编辑  收藏  举报