《人月神话》读书记录：
缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学生思维来衡量工作量，跟进工作进度。他们没有发现，如今的工作已经远非小学的应用题。那些稚子玩闹的应用题，在人生和工作的大部分场景中，实际上根本无法“应用”。
如果进度偏慢，下意识的反应是增加人力或者催促加班。实际上，这两种方式都是饮鸩止渴——增加人力的话，并不意味着更多人加入解决原先的工作量，增加人力本身就会导致工作量的增加。小型、精干队伍是最好的--尽可能的少。
需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法--既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
“人月神话”为什么会成为“神话”的原因，如原文所述，“因为一些意想不到的交互会产生许多不易察觉的bug，测试工作将会非常耗时，因此相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。”，“人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。”。当任务复杂度逐渐增加时，我们习惯于计算工作量的两个单位“人”和“月”就不再能够互相转化了，“人月”神话最终走向破灭。
《梦断代码》读书记录：
《梦断代码》中，一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。
在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任。
书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。而且，交流也会花大量的时间。
我们知道交流很重要，但是软件不是在QQ 群中交流出来的，而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。做过了的决定，就要执行，不要反复。
《程序员的修炼之道》读书记录：
1.本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。
经营知识资产可以从以下方面进行：
定期投资：定期投入时间学习，即使很小的投资也是很重要的。
多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。
管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。
低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。
这些知道方针里最重要也是最简单的就是：定期为你的知识资产投资。
2.有时候你确切的知道自己需要什么以及怎么做，但请求许可这件事往往会遭遇拖延和漠然，每个人都会护卫他们自己的资源，这让事情变得复杂，这叫“启动杂役”（start-up fatigue）。这时候我们不应该等着所有事情都准备好，而应该先拿出“石头”煮起来，就是想让事情启动起来。只要是有益的事情，你把做出的一部分结果拿给别人看，然后告诉他们如果加的别的什么会更好，大家一般都会帮忙的。
3.在黑暗中发光的代码。通常一个项目的开发是非常复杂的，如果只是一个模块一个模块的开发，我们可能直到最后才能确认项目运行情况。更好的做法是，我们要让系统尽早的跑起来，然后根据需要给它完善细节。这样会有以下好处：
用户能够及早看到能工作的东西。
开发者构建了一个能在其中工作的结构。
你有了可用于演示的东西。
你能够感觉到工作进展。
4.调试心理学。调试的目的是解决问题，不要因为别人提出 bug 而发起进攻。
当你目睹 bug 发生或者看到 bug 报告时，第一反应不要是“那不可能”。很明显已经发生了，把时间用在思考它为什么产生上面。
使数据可视化。例如循环引用问题，如果可视化的话可以很轻易地进行排查。
跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。
橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。
不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。
对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。
标签：记录,代码,知识,bug,工作量,我们,调试,读书 来源： https://www.cnblogs.com/gaowei970810/p/15854746.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。