人月神话读后感
首先, 这是一本非常好读的书😂😂😂, 基本是利用我最近被数电踩在地上蹂躏之余闲暇或者睡前的时间读完的......(数电好tmd难...), 然后很早之前就听说过这本书(我第一次听别人问我读没读过人月神话的时候, 我以为是穿越小说😂😂😂), 也很早就买了这本书, 也很早就翻过这本书😂, 今天读完了...(再过两个小时就要去参加水课辩论赛和考试🤷♀️🤷♀️🤷♀️). 就大概总结一下吧.
第一, 这本书其实更像一本技术散文集, 类似朝花夕拾, 人月神话只是众多散文集中比较有代表性的一篇, 所以拿来当书名, 所谓人月, 就是一个程序员一个月的工作力, 所谓神话就是人和月能相互转化是一种神话😂, 最最最通俗的比喻就是一个妇女生孩子要10个月, 100个妇女一起生孩子也得10个月(书中举的例子). 由于项目本身的连续性和不可分割性, 所以人和月只能在很有限的范围内做转化, 即通过投入更多人力来提高生产速度. 但是书中提到了一个Brooks法则: 向落后的项目中投入更多人力只会让项目更落后. 核心的意思就是, 新人加入无法迅速投入生产, 一定会产生沟通成本, 当剩余时间很短的时候, 投入人力, 只会让项目更加紧迫. 我觉得某种程度上没错吧, 人越多, 效率越低, 就看是人数增长影响更大, 还是效率降低影响更大了.(这也是为什么很多比赛都只允许3-5个人参赛...其实3个人真的足够了, 总觉得是人数不够导致比赛成绩不好的, 多半都是人的水平不够). 而且这本书里也讲到了(乔布斯传和乌合之众里也提过类似观点), 就是一个高水平的人和普通水平的人的差距比想象的差距还要大一个数量级.
另一个概念就是手术团队, 即一个项目可以有100人参与, 但是最好不要超过10个人对项目整体进行思考, 否则无法保证效率和整体一致性(几乎只有整体一致性和人月是全书反复提及的概念), 作者类比了手术团队, 只有一个主刀医师(即小团队的核心), 配合他的有麻醉师若干, 护士若干. 应用到软件工程, 就是一个10人小团队要有一个核心一流Programmer, 配合他的人员可以有若干, 这些人可以给他提供建议, 提供帮助, 但是一切生杀大权取决于这个Programmer(其实很有道理, 毕竟手术怎么做不能听护士的...), 我个人对这个理念深有同感(可能没有同感的概念我也没记住😂), 我觉得少数服从多数这种绝对民主管理只适合于体力劳动或者劳动密集型产业(关于这方面, 乌合之众这本书讨论的更多), 以我自身的经历和我旁观我一个好朋友的经历, 如果我是一个3-5人团队的核心输出, 那就应该勇敢的接过话语权, 当然了, 为此承担的代价就是如果结果不好要背负全部责任(但是原则这本书里讲过, 不要让追求面子的渴望盖过追求真理的渴望, 要做正确的事情而不是面子上过得去的事情). 如果我不是团队核心输出, 那就不要争夺话语权, 而是应该帮助团队的核心输出树立权威. 书中另外一个章节: 平民?贵族? 就讨论了上述两种团队风格, 作者也承认, 对于小型团队, 就是贵族(即核心输出)领导型效率最高.
最后一个是作者的一篇论文, No Silver Bullet, 即对于软件工程的核心困难而言没有很好地解决方案(作者在1975和1990年做出的预测), 嗯...我其实没有长期大型软件开发的经历, 只是旁观过, 没什么话语权, 只是觉得大佬挺nb的, 说话说得斩钉截铁, 而且说这种悲观论调的话更需要勇气(说一些大家听起来都开心但是毫无意义的废话真的不如不说), 而且是对未来做出10年的预测...就很cool, 就应该多听多看这种东西.