《梦断代码》读书笔记 第2篇
第7章：细节视图
第8章：白板上的即时贴
第9章：方法
第10章：工程师和艺术家
第11章：通往狗食版之路
“读书时我喜欢上数学课——这类东西之所以能吸引我，是因为我知道自己做对了。”在书里面我找到了自己刚接触计算机时不喜欢编程可能的原因：我不知道自己是否做对了，也没有很顺利就做对的时候，慢慢地导致排斥编程，特别是一点思路也没有，或者知道这个程序将会花费我很多时间时情绪很糟糕，所以它不能吸引我。到现在，每次找到程序中不对的地方再修改正确，即使消耗很多时间，也会有一点点喜欢这种成就感，然后继续测试，找bug，修改。
话又说回来，有些小缺陷可能考虑到了（例如数值越界或溢出、要求输入数字却相反输入特殊字符、缺少判断......），但是测试时个人的意识驱使我们按照合法的要求输入，得到结果并没有影响，也就让它们随之而去，觉得自己不提出，别人也不会去验证，因此也不了了之。看到最后书中例举了几个事件，那些令人警醒的惊人灾难。“1962年，水手一号探测飞船在发射后5min偏离轨道，问题在于导航控制程序中缺少了一个连字符；1991年海湾战争中，导弹的一个电池未能成功点火，原因在软件中存在一个累计计算的错误。”“那些致命的缺陷，导致财产和经济的损失。人们指责软件问题导致了停电，航班延误和机场关闭、银行账户混淆......”甚至有些就确实发生在自己的身边，或者有一天自己就在使用这些有缺陷的软件，扰乱了正常的秩序，就不再单单是个人兴趣和能力的问题，也是一种责任！
“最大的挑战是咱们不能让野心泛滥，但也要防止灵感丧失。”这句话让我想到了几次的结对开发，最开始我们总害怕太难的做不出，所以想着用特殊的简单的数据和例子来作为测试的对象，或者直接就作为固定的数据，但做完后感觉那样完全没有意义，它不适用除了自己以外的其他对象。后来我们都尽量修改成提示使用者任意输入，或者随机产生，并且保证最基本的功能可以实现，而不是太过于“个性”。
马上就要进入到团队开发的阶段了，《方法》章节里，汉弗列出了几点这时需要注意的：1、我们都为组织工作；2、组织需要计划；3、除非你的工作足够独立，否则必须按进度工作；4、如果你不自己做进度安排，别人就会给你做安排；5、这样别人就会控制你的工作。重点强调了组织、计划、进度对团队里每个成员的要求，现在我们可能不能完全感受到在一个项目里这些有多么重要，但却是无形的原则和约束。“约束是环境的产物——预算少、时间紧、目标有限。团队项目，不是1个人、2个人或3个人。”
“像计算机一样思考，编程是一种创造性写作。”写程序并不像都完这三个字那么简单，值得驻足思量。多数程序员太过求快，只关注如何把自己的那部分代码敲完，如何把功能化简，如何让计算机达到客户需求的...那做出来的可以说真不咋地。“读代码难于写代码”，大多数没有文档、没有注释。在前几次的结对开发中深有体会，代码并不是全部由两个人一起完成的，有些代码方法测试方可能看不太懂。
“由于重复的周期和无限期的延误，编程工作让人想到薛西弗斯的劳役，没完没了地推巨石上山。”让我觉得有时候确实做了很多无用功，一想到编程就感觉好困难，不愿进行。然而困难有不同类别：养孩子难，葬先亲难，出生和成长，与人同住或无人相伴；软件？另一个困难的世界。没有捷径，永远也到不了目的地。许多情况我们会一次又一次否定自己，一次又一次发现自己所需之物总与现实之物差异甚大，只能重新编写，但是换个角度，可以看作已经有很多方法，我们一一排除，最后找到可行的。看到最后，很遗憾，书中的团队还是失败了的，他们接受了现实。一个团队经历了许多，为着一个共同的目标，他们一直都在努力，在不断修改完善代码，在无限的付出，对于一个软件产品来说是没有成功，但把发生的做了很好的总结，以及每个成员的精神都是值得学习的。老师说过，无论对错都是一个积累的过程，感觉永远也做不出来的，坚持了总会有回报的。