作者：pansz
链接：https://www.zhihu.com/question/2058996805182960802/answer/2060670140585399882
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
一个都没有过时，反而价值更高了，无愧于是圣经。
观点一：人月不可互换，10个人一个月无法完成一个人10个月完成的任务。
现在没过时，就算10个人带着AI，也同样不可能一个月完成一个人带着AI需要10个月完成的任务。
观点二：向进度落后的项目中增加人手，只会使进度更加落后。
现在也没过时，增加人手确实无法改变进度落后的现实。哪怕有了AI，每个工程师的思路依然不相同，10个人各自指导AI依然比不上1个人指导AI更长时间。然而单个人的精力有限，你给它更多的AI并不能让他加速。
观点三：系统设计必须保持概念一致性，由少数精英（"贵族"）负责架构设计，大多数人负责实现。好的设计需要简洁性，一个系统最好由少数几个核心设计师把控，避免"设计委员会"式的折中妥协。
现在也没过时，因为整个系统的概念一致性依然重要，可能比以前更重要，因为当软件规模上涨较慢时，很多工程领域的规则看起来很教条。但一旦软件规模可以被AI快速上涨时，那些工程领域的经验突然就会变成了真理。
观点四：用小型精干团队（1 位主刀医生 + 辅助人员）替代大型团队，以解决沟通效率问题。大型项目应通过多个这样的小型团队并行协作，而非组建一个庞大的扁平团队。
现在更加没过时，因为小型精干团队恰恰就是AI最擅长的领域。
观点五：架构师设计的第一个系统往往过于谨慎、功能不足。第二个系统则容易过度设计、堆砌功能，导致复杂度和成本失控。提醒人们对第二个系统保持警惕。
现在依然没过时，你跟AI多聊几遍就懂了。但这句话没说的是，如果咱们可以获得第三个系统，第四个系统，结果会如何。
观点六：团队规模扩大时，沟通成本（会议、文档、协调）会急剧上升。新人加入后，需要培训才能有效产出，而培训本身会消耗现有成员的产能。
现在更加没过时，为什么宁可裁员或者让程序员加班也不愿意招新人？因为人月神话早就说了新人加入的成本。
观点七：没有银弹（No Silver Bullet）。没有任何单一技术或管理方法能在十年内使软件生产力提升一个数量级（10 倍）。软件开发的根本困难在于概念性设计（思考做什么），而非实现（编码），后者可以通过工具改进，但前者难以被自动化。
现在不但没过时，而且还成为了圣经，因为「实现」环节确实如他所说被工具改进了，但这改变的是偶然复杂度，但软件开发的本质复杂度没有因此而改变。而这部分并不能被工具改进与提速。
有的朋友觉得自己可以几个小时内搞一个原型级别的小应用，但他可能不知道，就算在AI到来以前，这种级别的东西自己到众包去找程序员接单，也是可以又便宜又快的。
观点八：书面规格说明和文档是团队沟通的核心媒介。口头沟通不可靠，必须通过文档固化决策、传递设计意图。
这也同样，不但不过时，还成了圣经。
观点九：软件项目估算往往过于乐观，因为人们倾向于假设一切顺利。实际项目中，调试和测试往往占去比预期多得多的时间。建议采用"1/3 计划、1/6 编码、1/4 组件测试、1/4 系统测试"的时间分配。
这显然没过时，「编码时间仅占六分之一」是人月神话在很多年前就已经提出的观点，然而很多人就是不相信也不想相信，同时，「测试时间是长常规编码时间的三倍」也有很多人不相信，但现实中必须撞这个南墙才能懂。哪怕你把编码时间优化到零，整个项目的其它时间也并没有缩短，何况，实际上编码时间并没有减少太多，写代码的时间转化为写prompt的时间并不会无限制的提升开发效率。
观点十：区分了程序（Program）、编程产品（Programming Product）、编程系统（Programming System）和系统产品（Systems Product）四个层级。真正的商业软件是"系统产品"，其复杂度远非一个独立程序可比。
这就更加没过时。
总结：在AI时代，由于具体软件技术栈的重要性下降，软件工程的重要性变得无与伦比，而软件工程圣经的含金量，得到了无与伦比的提高。
简化诠释：软件工程的根本挑战在于管理的复杂性（尤其是沟通和概念一致性），而非单纯的技术实现；在技术实现上出大力优化，并不是解决软件工程的万能药，反而可能是毒药。
