文章目录
1、人人都会编程的时代，我们如何留存?
我读的是一本《人月神话（纪念典藏版）》，记得书中有一段话：
1000个人看到这段话，肯定有1000个不同的评论和感想。当我深入理解一番后，恍然大悟，觉得是挺有道理的。我的评论：
2、小故事说明项目管理着为什么必看这本书
XXX公司，有一个叫做老王的中年程序员。他梦想着开发一个可以帮助村民买菜卖菜的应用App，现在为该项目负责人。为了更快完成这个项目，公司老板建议他聘请更多的程序员。
兴奋的老王开始与他的团队一起工作。但随着时间的推移，她发现项目进展缓慢，团队成员之间的沟通变得越来越复杂。老板看到项目滞后，建议他再招聘一些程序员。但令人意外的是，这只使情况变得更糟。
老王很困惑，他原以为有了更多的程序员，他可以更快地完成工作。但现实与他的预期相去甚远。
这时，镇上的一位老程序员给了他一本书《人月神话》。老王阅读后恍然大悟。他从中学到了软件项目的复杂性，了解了为什么仅仅增加更多的人手并不能解决问题，甚至可能导致更多的问题。
老王按照书中的建议调整了团队结构，更加注重沟通和计划，最终成功完成了他的项目。
老板和用户们对这个应用都非常满意。而老王则深深地明白了，为什么每一位软件工程师都应该阅读《人月神话》。
3、如何评价《人月神话：纪念典藏版》
《人月神话：纪念典藏版》（The Mythical Man-Month: Anniversary Edition）是《人月神话》原版的后续版本，由弗雷德里克·P·布鲁克斯在1975年版的基础上，新书增加了新的章节和内容。下面是《人月神话：纪念典藏版》的一些主要要点和读后感：
主要要点：
- 人月的神话：强调了向滞后的项目中增加人员只会导致其进一步滞后的观点。
- 没有银弹：认为不存在能够大幅度提高软件开发生产率的单一解决方案。
- 概念完整性：强调了产品设计的一致性和单一愿景的重要性。
- 重做而非修复：建议对第一次尝试的系统设计进行彻底的重做，而不是简单地修复。
- 沟通和文档：随着团队规模的增长，沟通成本也会增加。
- 软件的无形性：软件产品的进度和复杂性很难直观地看到，与物理产品不同。
- 过早优化：首先应关注产品的正确性和清晰性，再考虑优化。
- 技术与人的交互：强调了软件开发中人的因素的重要性。
- 大型项目的挑战：大型项目与小型项目存在根本的差异。
- 新章节：纪念典藏版增加了对原书观点的重新评价和反思。
可能的读后感：
- 时间的考验：即使在几十年后，作者的观点仍然具有相关性，这显示了他的见解的深度和持久性。
- 人的因素：软件开发不仅仅是关于代码或技术，人和团队之间的交互在项目成功中起着关键作用。
- 项目管理的复杂性：本书提供了对于为何软件项目经常延期和超预算的深入了解，这些观点在现代依然适用。
- 反思和学习：布鲁克斯在纪念版中的自我反思和对原有观点的评估展示了一个真正的学者和实践者应具备的自我批判精神。
- 启示和指导：对于软件工程师和项目经理，本书提供了宝贵的洞察和指导，帮助他们避免常见的陷阱，并更有效地进行项目管理。
读完纪念典藏版，许多读者可能会深受启发，并将作者的观点和经验应用到自己的工作中。
4、本书的目录（好不容易扒拉出来的目录，可以瞅瞅）
目 录
第1章 焦油坑 / 001
编程系统产品 / 003
职业的乐趣 / 005
职业的苦恼 / 006
第2章 人月神话 / 009
乐观主义 / 011
人月 / 013
系统测试 / 016
空泛的估算 / 018
重复产生的进度灾难 / 019
第3章 外科手术队伍 / 025
问题 / 027
Mills的建议 / 029
如何运作 / 032
团队的扩建 / 033
第4章 贵族专制、民主政治和系统设计 / 035
概念的完整性 / 037
获得概念的完整性 / 038
贵族专制统治和民主政治 / 039
在等待时，实现人员应该做什么 / 042
第5章 画蛇添足 / 047
结构师的交互准则和机制 / 049
自律—开发第二个系统所带来的后果 / 050
第6章 贯彻执行 / 055
文档化的规格说明—手册 / 057
形式化定义 / 058
直接整合 / 061
会议和大会 / 061
多重实现 / 063
电话日志 / 064
产品测试 / 064
第7章 为什么巴比伦塔会失败 / 067
巴比伦塔的管理教训 / 069
大型编程项目中的交流 / 070
项目工作手册 / 070
大型编程项目的组织架构 / 074
第8章 胸有成竹 / 079
Portman的数据 / 082
Aron的数据 / 083
Harr的数据 / 084
OS/360的数据 / 085
Corbató的数据 / 086
第9章 削足适履 / 087
作为成本的程序空间 / 089
规模控制 / 090
空间技能 / 092
数据的表现形式是编程的根本 / 093
第10章 提纲挈领 / 095
计算机产品的文档 / 097
大学科系的文档 / 099
软件项目的文档 / 099
为什么要有正式的文档 / 100
第11章 未雨绸缪 / 103
试验性工厂和增大规模 / 105
唯一不变的就是变化本身 / 106
为变更设计系统 / 106
为变更计划组织架构 / 107
前进两步，后退一步 / 109
前进一步，后退一步 / 111
第12章 干将莫邪 / 113
目标机器 / 116
辅助机器和数据服务 / 118
高级语言和交互式编程 / 121
第13章 整体部分 / 125
剔除bug的设计 / 127
构件单元调试 / 129
系统集成调试 / 132
第14章 祸起萧墙 / 137
是里程碑还是沉重的负担 / 139
“其他的部分反正会落后” / 141
地毯的下面 / 142
第15章 另外一面 / 147
需要什么文档 / 150
流程图 / 152
自文档化的程序 / 156
第16章 没有银弹—软件工程中的根本和次要问题 / 163
摘要 / 165
介绍 / 165
根本困难 / 166
以往解决次要困难的一些突破 / 171
银弹的希望 / 172
针对概念上根本问题的颇具前途的方法 / 181
第17章 再论“没有银弹” / 189
人狼和其他恐怖传说 / 191
存在着银弹—就在这里 / 191
含糊的表达将会导致误解 / 192
Harel的分析 / 195
Jones的观点—质量带来生产率 / 201
那么，生产率的情形如何 / 201
面向对象编程—这颗铜质子弹可以吗 / 203
重用的情况怎样 / 205
学习大量的词汇—对软件重用的一个可预见但还没有被预言的问题 / 208
子弹的本质—形势没有发生改变 / 209
第18章 《人月神话》的观点：是与非 / 211
第19章 20年后的《人月神话》 / 235
为什么要出版20周年纪念版本 / 237
核心观点—概念完整性和结构师 / 238
开发第二个系统所引起的后果—盲目的功能和频率猜测 / 240
图形界面的成功 / 243
没有构建舍弃原型—瀑布模型是错误的 / 247
增量开发模型更佳—渐进地精化 / 249
关于信息隐藏，Parnas是正确的，我是错误的 / 254
人月到底有多少神话色彩？Boehm的模型和数据 / 256
人就是一切(或者说，几乎是一切) / 258
放弃权力的力量 / 259
最令人惊讶的新事物是什么？数百万的计算机 / 262
全新的软件产业—塑料薄膜包装的成品软件 / 264
买来开发—使用塑料包装的成品软件包作为构件 / 267
软件工程的状态和未来 / 269
结束语 令人向往、激动人心和充满乐趣的50年 / 271
5、感谢关注我的粉丝和正在关注这本书的你，这本书送给你
- 送书规则：
- 没中奖也没关系，可以参加内部的一个活动，直接买，反正也不差这几十块钱：
京东领券地址（无门槛优惠券10元）：