笔记

【35】
『现在，开发者的时间才是紧缺和昂贵的资源。』

【38页】
『在理解一个问题的时候，需要渐次地问5个以上的“为什么”。』

【39页】
『“这个，我不知道”是一个好的起点，应该由此进行更进一步的调查，而不应在此戛然而止。』

【70页】
『大部分用户其实都是希望现在就有一个够用的软件，而不是在一年之后得到一个超级好用的软件。』

【78页】
『最近一次修改有没有无意中破坏了什么功能？』

关于测试，自己之前也认为是“其他人的工作”，然而最近工作的感触则是，编写易于测试或者“能产生反馈”的代码、能有明确的输入输出的代码，是非常有价值的：代码便于维护、调试以及测试。可以提高可靠性。

【93页】度量真实的进度
『在你最后真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。我们希望这能作为下一次的参考。在为下一个任务估计工作量时，可以根据这次经验调整评估。』

【96页】倾听用户的声音
『当出了错误，你要尽可能地提供详细信息。黑屏和含义不明的“退出”按钮是很不友好的行为。更糟糕的是，在得到用户反馈的时候，还嘲笑用户愚蠢，而不去真正地解决问题。』
每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。

【146页】敏捷协作
『面对面的会议仍然是最有效的沟通方式。』
深有感触。

【153页】新系统的设计者
『新系统的设计者必须要亲自投入到实现中去。』
—— Donald E. Knuth

【155页】实行代码集体所有制
『任何一位团队成员，只要理解某段代码的来龙去脉，就应该可以对其进行处理。如果某一段代码只有一位开发人员能够处理，项目的风险无形中也就增加了。』
个人的感触是，每个人都应该对项目的各个模块有足够的了解，对整体架构有了解，能够在任何一个成员缺席的时候可以补上去完成他的后续功能开发以及维护他之前写过的代码。

【157页】成为指导者
『如果你用你的蜡烛点燃了我的，我在得到光明的同时，也没有让你的周围变暗。好主意就像火，可以引领这个世界，同时不削弱自己。』
所谓教学相长也。

【162页】准备好后再共享代码
『通常情况下，提交的文件应与一个特定的任务或是一个bug的解决相关。而且应该是同时提交相关的文件，并注有日志信息，将来也能够知道修改了哪些地方，以及为什么要做修改。一旦需要对变更采取回滚操作，这种“原子”提交也是有帮助的。』
这本书的英文原版是2006年出版的，所以写书的时间大致在2005年。而 Git 是在2005年才在社区中诞生并慢慢壮大的。所以本书的版本控制理念还是以 SVN 这样的集中式版本控制系统为背景进行阐述的。

【166页】做代码复查
『这里是一个可供启动的最基本的检查列表：
+ 代码能否被读懂和理解？
+ 是否有任何明显的错误？
+ 代码是否会对应用的其他部分产生不良影响？
+ 是否存在重复的代码？
是否存在可以改进或重构的部分？』
代码复查，即 code review，是最有效的且必要的过程之一了。

『』『』『』『』『』『』『』『』