《梦断代码》读后感（第1~6章）
书名："Dreaming in Code"，作者：Scott Rosenberg（中译本：《梦断代码》，翻译：韩磊，电子工业出版社出版）。
- 第1章 【死定了】
在这一章中，作者主要讨论的一个问题是——在项目进展迟缓，面临延期交付窘境的情况下，是否应该征召新人加入团队？
很显然，这样做的好处是：会有更多的人参与到项目开发中来，更多的人阅读代码，从而获得更大的发现并解决错误的可能性。作者在书中援引瑞蒙德（Eric S. Raymond，《大教堂与集市（The Cathedral and the Bazaar）》一文的作者）的原话“只要有足够多的beta版测试人员和开发者队伍，几乎所有问题都会很快被发现，而且总有人知道该怎么修复。或者用不太正式的说法，‘眼球足够多，缺陷无处躲。’我把这叫做‘李纳斯法则’。“而Linux操作系统和许多开源项目成功的案例就为这条法则做了十分生动的注脚。
但是与‘李纳斯法则’相对应的，还有一条‘布鲁克斯法则’（《人月神话（The Mythical Man-Month）》，Frederick Brooks）：”往已延误的项目中补充人力，只会使其继续延误“。这条法则也有其合理的依据：每加入一个新人，都需要开发团队暂缓开发进度，为新人讲解工程结构，使其融入整个工程，而这个过程本身便会拖累项目进度。
我想这两条法则各有其成立的背景，而其中非常重要的一点就是团队内的交流成本。开源项目背后往往有一个庞大的开源社区，这个社区内的程序员们通常都是出于自己的个人爱好而为项目出力。一个新人在社区上提出的问题往往有很多人知道答案并能很快得到解答，这些人可能只是由于加入社区或关注项目更早，获得了更多的信息和经验，而非真正的核心开发人员，因而这个”帮助新人融合”的环节就不太会拖累工程的进度。总而言之，开源社区因其规模效应使得核心开发人员可以将精力集中在开发上，而每加入一个新人的“融合成本”均摊到余下的“社区志愿者”身上以后就变得十分渺小了。可是像卡普尔的这个规模相当有限的Chandler团队，成员是领受薪水的，每个人都承担了相当的任务，几乎都是项目开发中不可或缺的一员。这样的情况下，任何一个人的进度迟缓都会影响到整个项目的进展，因而布鲁克斯法则就会起主要作用。
对于我们这个Focus小组来说（其实其他的软工小组也一样），还是和Chandler更像一些：每个成员负责项目中的某一块，且一个成员的延误会拖累整个项目。况且征召新人对我们来说也不现实，因此，为了保证项目进度的正常进行，PM就要保证每个开发人员都在正常的运作，并且最关键的是：在关键的时间节点上能够出活。在这一点上，我们也是深有体会的：项目开发的初期阶段，PM早早地制定好了项目框架和接口设计，负责数据存取和与Google Calendar同步的开发人员也较快地完成了任务，UI部分则相对进展慢一些，尤其是负责实现Task Pool的成员，因为忙于其他事情而较晚将精力投入到项目开发中来。期间PM向组内不定期的发邮件通告项目各部分的进展，让进展较慢的开发人员时时感受到压力的存在。最终，进展较慢的开发人员也通过在alpha release前4天开始拼命干活完成了预定任务，保证了整个项目的正常进度。
 项目总结)
 电梯调度程序)
