《人月神话》读书小记
- 发布于
目录
人月神话这本书从在大学就听说过，说是软件工程的必读，当时还好奇一本软件工程的书籍为什么名字这么奇怪：人和月的神话，名字起的像是高中看的玄幻小说。
我是没有读书的好习惯的，作为程序员却一直错过了它，最近在 B 站看到了一位 up 主又推荐了这本书
一下子就被激起了兴趣，突然就想起了对这本书的疑问，怎么个人月？怎么个神话？于是马上打开京东找到了 up 主推荐的《人月神话》纪念典藏版即刻下单了。 没错，up 主有点广告的嫌疑，但是人家文案写的确实不错，吸引到我了。
我读书喜欢由着性子来，喜欢就往下读，随时想停下就停下了，因此这篇读书小记也是随时读到哪里便写到哪里了
焦油坑
首先将大型软件工程项目的开发维护比做是史前野兽在焦油坑中苦苦挣扎，越是挣扎反而束缚的越紧，作者这比喻真是相当生动形象了！一下子就把我的认识提高了一大截。
然后后半部分主要阐述了作为编程人员的职业乐趣和苦恼
乐趣
- 构造的成就感
- 劳动成果被他人使用的获得感
- 系统可以完美运行的精妙绝伦的自我感叹
- 持续的学习进步，编程工作具有非重复性，我们总会
说的可谓是深得我心了，虽然最初选择计算机专业纯粹是觉得写代码是一件很帅的事情，但后来真正领我走上这条职业道路的正是体会到了这些乐趣。
苦恼
- 追求完美
- 对外部的依赖
- 创造性的编程伴随着枯燥重复的 bug 查找与修复
- 周期过长导致产品的落后
最初加入到工作中时，每天写需求改 bug 也乐此不疲，没体会到这个职业的苦恼，现在工作两年了，慢慢地自己也感受到了，被琐碎的业务细节和各种历史包袱垃圾代码消磨了热情。
我自认为自己的代码写的还是比较优雅的，但是同事的有些代码确实让人比较难以言说。刚开始我看到有些历史代码写的稀烂我还会贴心的重构（如果是同事近期写的还是先不动了， 人情世故，不太好），后来的态度就是能不动就不动吧，能跑就行。
人月神话
哈哈，读到这才知道，“人月”是工作量的代词，就像光年表示光在一年走的距离，人月表示一个人需要花一个月时间的工作量。现在普遍的开发节奏都非常快，更常用的单位是人天。
如果一个需求的工作量是一人月，那在安排工作的时候想要缩短工期，自然就会想到加人，三个人就需要 10 天了，但作者认为这种想法是错误的
用人月衡量一项工作规模的大小是一个危险和带有欺骗性的神话（想法）。它暗示着人员数量和时间是可以互相替换的
外科手术团队
一个好的编程人员的效率可能是差的编程人员效率的十倍，用薪资来比较就是一个 20k/月的程序员可能顶 10 个 12k/月的程序员。
因此在软件工程中，一个团队的组织应当像医学外科手术团队一样：
- 外科医生，首席程序员；需要具有丰富的经验和深厚的知识，对系统设计和开发流程有绝对的话语权
- 副手，首席程序员的备份；同样需要深厚的知识，但不一定需要丰富的经验，主要在于有可供交流的想法
- 管理员，可以为首席程序员负责系统开发以外的琐碎事务
- 程序职员，普遍的存在，负责应用程序的编写
贵族制、民主制和系统设计
这种设计和分工是否有些贵族制的嫌疑？会让普通程序员无法发挥吗？会让天才的想法埋没吗？
并没有，作者解释了，具体的编码实现同样也具有创造性，在给定架构下仍然可以发挥天才的想法和技术上的才华，合适的规则对行业是有益的，更印证了那句话：“没有规矩，不成方圆”。
第二系统效应
在开发第一个作品的时候，往往是更谨慎的，但是在开始第二个作品时，往往由于第一个作品带来的自信，会控制不住的装饰和润色，造成过度设计。这就是第二系统效应。
要想克制这种惯性，只有自律，避免继续到“第三系统”、“第四系统”
从我自己不多的经验来举例，我在折腾这篇博客之前，三年多时间内，起码折腾过五六个博客，wordpress、hugo、自己原生实现等等， 每当我新开始时，包括现在这个，我都想加一些花里胡哨的东西进来，但实际并没啥用，仅仅是因为看到别人有以及曾经想做。加了很多没用的炫酷的 css，有意识到最重要的东西是内容，然后又灰头土脸的删掉。
看到这里，醍醐灌顶，原来第二系统效应一直在我身上实践，我要开始自律，约束自己。
- 最后更新于