《人月神话》读书记录：

　　缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学生思维来衡量工作量，跟进工作进度。他们没有发现，如今的工作已经远非小学的应用题。那些稚子玩闹的应用题，在人生和工作的大部分场景中，实际上根本无法“应用”。

　　如果进度偏慢，下意识的反应是增加人力或者催促加班。实际上，这两种方式都是饮鸩止渴——增加人力的话，并不意味着更多人加入解决原先的工作量，增加人力本身就会导致工作量的增加。小型、精干队伍是最好的--尽可能的少。

　　需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法--既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

　　“人月神话”为什么会成为“神话”的原因，如原文所述，“因为一些意想不到的交互会产生许多不易察觉的bug，测试工作将会非常耗时，因此相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。”，“人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。”。当任务复杂度逐渐增加时，我们习惯于计算工作量的两个单位“人”和“月”就不再能够互相转化了，“人月”神话最终走向破灭。

《梦断代码》读书记录：

　　《梦断代码》中，一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。

　　在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任。

　　书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。而且，交流也会花大量的时间。

　　我们知道交流很重要，但是软件不是在QQ 群中交流出来的，而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。做过了的决定，就要执行，不要反复。

《程序员的修炼之道》读书记录：

　　1.本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。

　　经营知识资产可以从以下方面进行：

　　　　定期投资：定期投入时间学习，即使很小的投资也是很重要的。

　　　　多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。

　　　　管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。

　　　　低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。

　　这些知道方针里最重要也是最简单的就是：定期为你的知识资产投资。

 

　　2.有时候你确切的知道自己需要什么以及怎么做，但请求许可这件事往往会遭遇拖延和漠然，每个人都会护卫他们自己的资源，这让事情变得复杂，这叫“启动杂役”（start-up fatigue）。这时候我们不应该等着所有事情都准备好，而应该先拿出“石头”煮起来，就是想让事情启动起来。只要是有益的事情，你把做出的一部分结果拿给别人看，然后告诉他们如果加的别的什么会更好，大家一般都会帮忙的。

　　3.在黑暗中发光的代码。通常一个项目的开发是非常复杂的，如果只是一个模块一个模块的开发，我们可能直到最后才能确认项目运行情况。更好的做法是，我们要让系统尽早的跑起来，然后根据需要给它完善细节。这样会有以下好处：

　　　　用户能够及早看到能工作的东西。

　　　　开发者构建了一个能在其中工作的结构。

　　　　你有了可用于演示的东西。

　　　　你能够感觉到工作进展。

　　4.调试心理学。调试的目的是解决问题，不要因为别人提出 bug 而发起进攻。

　　当你目睹 bug 发生或者看到 bug 报告时，第一反应不要是“那不可能”。很明显已经发生了，把时间用在思考它为什么产生上面。

使数据可视化。例如循环引用问题，如果可视化的话可以很轻易地进行排查。

　　跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。

　　橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。

　　不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。

　　对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。