第13章 软件测试
测试原则
一，测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。
二，程序员应该避免检查自己的程序，软件测试应该由第三方来负责。
三，设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下不要制造极端状态和意外状态。
四，应该充分注意测试中的群集现象。
五，对策就错误结果进行地一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题以及严重程度等。
六，制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成也有一个高水平的测试。
七，妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
第14章 质量保障
软件质量=程序质量+软件工程质量
第15章 稳定和发布阶段
15.2 发布之后——事后诸葛亮会议
会议的核心问题：“如果你可以重新来过，什么方面可以做得更好？” 既然有事后诸葛亮，那肯定也有事前诸葛亮，但事前无论想得再怎么全面，还是会有不足。所以事后诸葛亮会议是很重要的。
第16章 IT行业的创新
16.2 创新的时机
我们从G-number这个游戏可以领悟到3点：1，赢者通吃。2，螳臂当车。3，只先一步。 我们知道这游戏玩次数越多，答案越小。所以把握好创新的时机是非常重要的。
第17章 人，绩效和职业道德
17.5.2 磨合阶段
正确处理问题
1）对于技术能力强，并且通过实际工作得到大家认可的成员，应鼓励他们发挥更多技术领导的作用。
（2）对一些经常有不同意见，特立独行，看似拖团队后腿的成员，这时不应该妄下判断，其实他们很可能是不错的员工，只是没有掌握表达意见的适当方式，不懂如何说服别人，应该鼓励他们找到和团队共存、共事的途径。
（3）有的成员虽然自己的工作能应付，但他们不爱讨论、分享经验，似乎没有更高的要求。对这种类型的人，应该让他们与更自信、积极的同事合作，给予他们要求更高的工作，让富有挑战性的工作激发他们的热情。
（4）有的成员在实际工作中显示出较差的技能，不怎么胜任工作。对这类成员，要考虑安排他们做得来的事，调整在团队中的位置，做到人尽其用。