梦断代码 读书笔记 01

第0章 软件时间
作者迷恋于一个开放代码并可以由游戏玩家更改程序的一个游戏，并为在它的基础上创新和增添一些功能而乐此不疲。

0代表程序员的思维方式，因为计算机从0开始计数。

"Hello World " 程序能够唤醒每个程序员心中乐观的一面。既然能叫它说话，就能让它做任何事！

为什么就是不能像造桥那样造软件？

人类文明运行于软件之上。软件创建艺术却隐于暗处，即便对于专家们也是如此。互联网时间带来了快速发展的技术产生、公司创立、创造财富等也同时带来了程序的缺陷问题。而对软件开发者来说，则过的是时快时慢：如果灵感到了，一切顺利，则全然忘记时间，全心投入高速的开发之中。反之遇到瓶颈，则举步维艰的软件时间。软件不能像建造桥梁那样一劳永逸可以造福上百年。反而漏洞百出，麻烦不断，错误不停。带来无穷尽的改进和苦恼。

第1章 死定了
一个错误就可能让一个项目“死定了”。往往带来不可知因素的时间陷阱。

记录于Bugzilla 中的第44 个缺陷，最初于2003 年1 月19 日登记，描述信息是“ 当修改窗体大小时出现闪烁”。。安德森认为这是个小问题，不过还是应该查实和修正。可直到将近六个月之后的今天，他仍然没能修正。问题不在自己和同事编写的代码上，出错的根源在于一个称作wxWidgets 的软件里面，Chandler 小组采用该软件作为项目的构造块。安德森要么等着wxWidgets的开发者修正代码，要么就得绕过问题所在。

软件项目难以按进度安排实现，这种情况极为常见。在软件开发的世界里，进度延误普遍到人们特意生造出—个委婉词来描述它：slippage（失速）。

软件时间自我扭曲再头尾相接，如同莫比乌斯环。一般令人费解。进度忽而突飞猛进，忽而不知何故驻足道中。在你以为大功即将告成之时，却又山穷水尽， 花上整半年时间，一无所得。

IBM System/360 主机操作系统是当时规模最大的软件项目。那台巨大而昂贵的大型计算机，本应是后来二十年中生意场上的中流砾柱，但它的孕育和诞生却饱受延误和成本超支之苦。正如布鲁克斯所言，它变成了一个“沥青坑”， 一个能粘住大企业的陷阱，哪怕对于IBM这样“孔武有力”的公司也不例外。

布鲁克斯法则：

向已延误的项目中补充人力，只会使其继续延误。

布鲁克斯写道，软件开发者通常都是乐天派，他们认定每个缺陷都可以被迅速修正，且修正旧缺陷必能减少新缺陷的数量。

布鲁克斯发现，在实际开发中，编码只占软件项目开发时间的1/6, 有一半时间用于测试和修正缺陷。但只有少数项目经理会真正按照这种思路来安排开发人员的工作时间。
所谓“人月", 是一种科学管理概念，它假定生产力可被拆分为不连续、无差异、可替换的单元。

布鲁克斯观察到，“只有在任务能分派给许多互相之间无须沟通的工作者时，人和月才是可互换品。

“对于软件而言，项目各有差异、工具不断升级，每当团队中加入一个新组员，老组员就得放下手边的工作，帮助新组员进入角色，每位组员都要等待重新分派任务，好让新组员有事可做。在你意识到这一切之前，已经远远落后于进度了。也就是说，每次重新安排进度计划，都导致雇用更多人力，于是又不得不重新安排进度。

制作软件的大量工作受困于“序列约束＂，它限制了任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。

布鲁克斯法则暗示最理想的开发组规模是一个人——无须停下工作与同事沟通的单个开发者。

一切均顺序进行，确保项目维持布鲁克斯所谓“概念上完整”的状态· 项目中所有环节目标一致，且按计划完美结合。

但是对于庞大且涉及面极广的一个程序来说几乎不可能。从理论上团队开发就是不得不被认可的，何况实践上它几乎必不可少。

开放源代码软件开发(open source software development)，它能彻底改变软件开发的具体过程——将其从少数隐士手里拿出来，散播到广大人群中。在它之前，软件开发都采用大教堂模式。即“最重要的软件……需要像建教堂一般，由独立的巫师或一队相互隔离的魔法师精心打造，在面世之前绝不发布beta 版本。”

开发源码开发方式（又叫开源集市）在一方面，低成本、广泛地接入像互联网那样的网络， 让开发者之间能建立迅速、可信的沟通渠道，存储可被开放访问的共享知识和代码池；另一方面，围绕一种领导方式——如托瓦茨那样的方式——形成合作团队的良好风气，欢迎新人进入、鼓励成员做出贡献，同时尽可能增加合格成员。

开源运动的新集市模式在很多方面改变了计算世界，但说到能比大教堂模式更快地让新产品面世，却并无显著建树。