本文是转载的互联网上的两篇文章。
读后，感觉非常好，罗列如下，以供诸君参考。
原文地址，请查看：
https://zhuanlan.zhihu.com/p/563702295
https://blog.csdn.net/weixin_42238037/article/details/125024705
人月神话简读
《人月神话》是软件工程方面的一本经典著作，书名《人月神话》中的人指的是人力，月指的是工作时间，主要的意思是 一个人一个月能完成的工作量 。
其作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。
Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。
上世纪七十年代开始，他开始撰写文章，讲述在软件开发中如何更有效的进行项目管理，其中有一些名篇“没有银弹”，“外科手术团体“至今被封为经典”，后来他将文章集结整理，初版了这本《人月神话》。
更多详细内容，请微信搜索“前端爱好者“， 戳我 查看 。
焦油坑
第一章作者将软件系统开发比作吞噬了恐龙、剑齿虎等史前巨兽的焦油坑。
一头大象悠然自得地在草原上散步。
夕阳的余晖洒下，大象觉得有些口渴了，它看到旁边有一个水洼，于是它慢悠悠地走到水洼前饮水。当它喝足准备离开时，突然发现自己被陷住了，这竟是一个蓄有一点水的沥青湖！
大象抬起笨重的象腿想要抽身，却发现越是挣扎，越是下陷得厉害。
大象预感到了死亡的来临，它的眼中渐渐浮现出惊恐与绝望。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。
人月神话
第二章作者主要介绍了软件开发项目在进度安排上经常出现的问题。
首先，编程人员都是乐观主义者
总是理想地想象一切都将运作良好，每项任务仅花费它所应该花费的时间。
而实际上，我们在实现过程中总会碰到各种各样的困难，可能是我们构思的缺陷，也可能是程序其他部件带来的错误影响，修复这些错误将占用我们大量的时间。
其次，估算进度时，我们错误地假设人和月可以互换
以人月为单位去衡量开发工作的规模是一个危险和带有欺骗性的神话。
就好比无论有多少个母亲，孕育一个生命都需要十个月。人月仅适用于完全可以分解的任务，这在割小麦和收棉花的工作中是可行的。
当任务由于次序上的限制不能分解时，人手的添加对进度是没有帮助的。
在开发工作中，添加更多的人手，意味着不得不花费时间去培训新人，并且随着开发人员的增多，沟通、交流 的时间成本也越大。
第三，系统测试的时间总是被预估得很低。
理论上，bug 的数量应该为 0，但由于我们的乐观主义，实际的 bug 数量比预料得要多得多，系统测试的进度安排常常是编程中最不合理的部分。
对于软件的进度安排，作者以自己多年的管理经验总结出如下法则：
- 1/3 计划
- 1/6 编码
- 1/4 构件测试和早期系统测试
- 1/4 系统测试，所有的构件已完成
与大多数传统进度安排相比，这份进度安排显得计划时间过长，测试更是占用了一半的时间，编码是最容易估算的部分，仅分配了 1/6 的时间。
但如果不为测试安排足够的时间简直就是一场灾难，因为 bug 会没有任何预兆，很晚才出现在客户和项目经理面前。
第四，项目进度落后时，人们的第一反应是加派人手。
这样的应对方案好比用汽油灭火，只会让火势更大，而更大的火势又需要更多的汽油，从而陷入循环的灾难之中。
外科手术队伍 – 任务拆解
200 个平庸的程序员组成的队伍很可能不如 25 个优秀程序员组成的队伍效率高。
那么，问题来了，什么样的队伍才是合适的呢，小团队固然高效，但是你不能指望一个 20 人的小团队在合理的时间内去开发一套完整的操作系统吧？
作者在这一章里给出了解决方案：将大项目合理地划分成更小的系统，各个外科手术队伍分别开发这些更小的系统。
Harlan Mills 提供了一个解决方案：大型项目的每一个部分由一个团队解决，但是该队伍并不是一拥而上，而是以类似外科手术队伍的方式组建。
如今的外科手术已经相当成熟，通常来说，一个外科手术队伍中有五种角色：
- 一位外科医生
- 一位或多位助手
- 一位麻醉师
- 一位器械护士
- 一位巡回护士
其中，主刀的外科医生负责整台手术的操作部分，他必须经验丰富且能力出色。助手是外科医生的后备，他能完成任何一部分工作，但是相对具有较少的经验。麻醉师、护士为外科医生提供必要的帮助。
在系统开发中也可以采用类似的人员结构：
程序的总架构师 担任外科医生的角色，负责程序的整体架构，并输出产品文档。保障程序的概念完整性，在整个团队中具有权威性。
助手 需要了解程序的所有代码，负责与架构师讨论程序的结构，但不具有架构师的权威，他充当了外科医生的保险机制。
将程序员按照专业化分工 ，承担自己擅长领域的代码部分，他们创造了团队最有价值的财富 —— 工作产品。
测试人员 负责编写测试用例，为外科医生搭建测试平台，保障程序的可靠性。
外科手术队伍与传统队伍的区别就在于：传统的团队将工作进行划分，每人负责一部分工作的设计和实现。在外科手术团队中，实际设计完全由外科医生完成，其他人负责填充实现细节与提供必要的帮助。
外科手术队伍的好处在于：他减少了沟通的成本，在传统的队伍中大家是平等的，出现观点的差异时，不可避免的需要讨论和妥协，在外科手术队伍中，观点的不一致由外科医生单方面来统一，它保证了程序的概念完整性。
贵族专制、民主政治和系统设计
建筑大师要首尾融会贯通其前辈建筑师的成果，同时也要完全掌握他们那个时代的建筑技术，并在运用这些技术时做到恰如其分。
建筑大师的工作仿佛和程序编程人员相似，都需要有一定的专业技能知识储备，所以我们才不会不断在学习新的语言的同时，深挖技能，学习底层技术，理解前人的设计思想。
建筑大师和编程人员还有一点很相似，那就是都喜欢在自己的设计产品里面增加属于自己的特色设计（编码风格）。
那么如何保证在同一个项目中，任务拆分到不同的开发人员手中， 概念完整性（代码设计思路） 一致呢？
获得概念的完整性
目标是 易用性 ，使用一个程序，只有当这些功能说明节省下来的时间，比花费在学习、记忆和搜索手册上的实践要多时，易用性才会提高，这个思考方法同样适用于我们在系统搭建之初，对技术选型的参考。
简洁 和 直白 来自概念的完整性。
概念的完整性：要求设计必须由一个/非常少数，互有默契的人员来实现。
在大型项目中，迫于进度压力，往往需要大量的人员一起来开发系统，那么就需要我们在以下两点下花费更多的关注：
-
仔细对设计方法和具体实现进行分工；
也就是模块划分要合理，尽量做到解耦，降低服务之间的互相依赖。 -
组建类似外科医生的崭新的编程开发团队；
有效快速的沟通。
贵族专制统治和民主政治
架构师 和 开发人员 的比率
这个比喻就好似 。
这里再次明确 架构师 的职责：
是用户的代言人，架构师的工作，是运用专业技术知识来支持用户的真正利益，而不是维护销售人员、制作者所鼓吹的利益（技术+业务的双层结合）。
- 产品的成本性能比 —— 依靠实现人员；
- 易用性 —— 依赖架构师；
架构师关注点：
- 系统的体系架构：完整和详细的用户接口说明。
- 计算机：编程手册；
- 编译器：语言手册；
- 控制程序：语言和函数调用手册；
- 整个系统：它是用户要完成自己全部工作所需参考的手册集合；
在等待时，开发人员（包括测试）应该做什么？
再聊大型项目，参与的人员众多，那么是不是会有大部分人员在项目初期处于等待中呢？其实不然，很多工作工作是可以同时并发进行的。
- 体系结构设计
- 设计实现
- 物理实现
这三个阶段互相独立，是可以同时进行的，那么如何进行呢？
开发人员：
在外部说明的系统功能的雏形期，就可以设计模块的边界，表结构，路径，阶段分解，算法以及所有的工具。
不过这里需要设计实现人员注意，要与体系架构师沟通，毕竟是雏形期，要随便变更，应变不明确或变化的需求，即：原型阶段。
物理实现：
库的调整，系统的管理以及搜索和排序算法。
画蛇添足
这一章主要是告诫系统设计师们，不要 过度设计，尤其是在第二个系统(第一个系统完成后开发的第二个系统)中，不要过度自信，保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主。
结构师的交互准则和机制
- 尽早交流、持续沟通，形成良好的成本意识。
- 与开发人员共同商讨（切忌不能支配）如何降低成本，若无法达成一致，做好准备放弃坚持所作的改进建议。
自律 —— 开发第二个系统所带来的的后果
这里需要注意，第二个系统指的并不是第二个新的系统，而是我们的软件项目上线后，后续添加新的功能，即后续的软件系统的维护升级过程。
为什么会这么说系统的二次升级是最危险的呢？
前面我们也说可，程序员大部分都是乐观的，尤其经历了一次项目成功部署上线。
这个时候，为了追求功能的多样性，会更容易不加取舍的往系统软件中增加很多不必要的功能 【过度设计】 。
而每一次的改动，都使项目的熵不断的增加，也就是复杂度和混乱度增加。
最终系统之间的差异越来越明显，越来越不受控制，最初满足功能的部分也变得越来越不够通用。
勿忘初心 —— 避免升级系统带来的危害
- 运用特别的自我约束准则。
- 避免功能上的过于修饰，根据系统基本理念及目的变更，舍弃一些功能。
- 保持对特殊诱惑的警觉。
- 确保原则上的概念和目标在详细设计中得到完整的体现，如果当时不能解决，想着后续解决，很多时候后续就没有了，破窗户 就一直留在了项目代码中，无人维护。
贯彻执行
这一章着重描述了文档手册记录的重要性。
文档化的规格说明 —— 手册
修改的的阶段化是很重要的（进度表上应有带日期的版本信息，参考jdk发版）。
手册不仅要描述包括所有界面在内的用户可见的一切，还要避免描述用户看不见的事物。
后者是编程实现人员的工作范畴，其设计和创造性不应该被限制。
每次修改文档，包括但不限于：
- 需求PRD，
- 技术方案文档，
- 修改的时候要有变更的说明对比信息。
- 另外涉及到编程实现的需求描述，应该不限定实现方式，这样会限制编程人员的发挥和创造。只描述需求最终呈现的效果即可，而编程实现人员应留有一定的代码扩展实现的空间，避免后续需求扩展时被束缚手脚。
文档形式化定义
如果同时具有两种方式，则必须以:
- 一种为标准，
- 另一种作为辅助，描述，并照此明确地进行划分。
一定要分清主次标准，记叙式文式 还是 形式化定义。而且所有的定义问题都要可以通过测试来验证解决。
当遇到一些尖锐的问题时，实现往往会给出计划外的答案，因为在定义的时候，这些没有被仔细考虑过。
多重实现
如果起初至少哟两种以上的实现，那么定义会更加整洁和规范。
多种实现，好的接口定义会使我们更加高效的接入，对于不同的功能扩展也会更加灵活自由，这就需要我们 良好的运用技能技巧，开闭原则，单一职责等。
巴比伦塔的教训
大洪水过后，全人类仅剩下诺亚一家，他们因躲在方舟中幸存了下来。
诺亚一家人在新土地上重新繁衍生息，成为全人类共同的祖先。
心有不安的子孙后代们为了防止大洪水再次发生，提议共同修建一座通天塔，这样，人们以后便不再需要流离失所。
不料这件事引起了上帝的注意，上帝开始担心：“如果这件事他们都能共同完成，以后便没有什么难得倒他们了。”上帝决定阻挠他们。
他到人间转了一圈之后发现：“现在他们都是同一个种族，都说同一种语言。”于是上帝决定从语言下手，他创造了许多种语言，导致人们互相不能听懂。
果然，没过多久，人们便无法继续合作修建通天塔了，不得不散落到世界各地。 ——《旧约圣经》，《创世纪》篇。
巴比伦塔计划虽然有充足的人力物力，但由于无法沟通，不得不走向失败的结局。
它的教训告诉我们：
沟通是合作的必要条件
大型软件项目中也面临这样的情况，因为左手不知道右手在做什么，所以进度灾难、不合理的功能实现、系统缺陷纷纷出现。
随着工作的不断进行，许多小组开始慢慢地修改自己程序的功能、规模和速度，当他们组合在一起时，新的程序就显得与原定目标渐行渐远。
团队之间有效的沟通
团队之间如何有效的沟通呢？通常有三种途径：
- 电话、交谈等非正式沟通：这些途径非常方便、有效，并且随时发生在日常生活中
- 会议沟通：虽然谈到会议总是有些恼人，但会议是最正式的明确需求的途径。如果小组氛围足够和谐，会议沟通将非常有用
- 工作手册：在项目开始时，就应提纲挈领，准备好项目工作手册。指派专门的人手来维护工作手册，保证它们可以随着项目实时更新。工作手册应保持树状的索引结构，工作人员可以很方便的使用索引来检索他所需要的信息。
巴比伦塔可能是第一个失败的工程，但它不是最后一个。
沟通与交流是成功的关键。
这项技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
胸有成竹
这一章节，作者通过不同的例子论证了一点：生产率似乎是固定的，使用适当的高级语言（如Java、Go、Python），编程的生产率可以提高n倍，但这属于编程里面的次要问题，根本问题后续章节会在讨论，尤其在没有银弹这一章节中。
削足适履
开发软件系统过程中，总是面临各种选择，时间? 空间（效率 ? 空间），如何更好的平衡。
这背后有一个隐藏的成本概念，紧密的软硬件设计集成与软件系统规模，二者冲突。
规模控制
- 预留空间；
权衡 “ 规模 —— 速度 ”方案，每一个方案设计都要详细了解，并在工作推行时间分配的时候预留空间，同时在工作进展的同时，也需要我们总是往前赶一赶进度，为意外留有处理时间。
- 制定总体规模；
避免拆分过重，模块过多。
应明确模块多大，并确切定义模块的功能。规模的控制，需要管理和沟通，这就需要系统架构师时刻敏感，保持持续的警觉，确保连贯的系统完整性。并不断培养开发人员从系统整体出发，面向用户的态度。
空间技能
前提：需要 一些创造性和技能。
问题1：速度（效率）不变，越多的功能，更多的空间
方案：功能交换尺寸。
可配置的功能应用，根据功能选项，剪裁程序。
难点：程序设计人员必须决定用户可选的项目粗细程度。
问题1：内存受限，常驻空间（交换页面或暂存去过多过大），从而降低性能
（我们面试中也会经常被问到内存泄漏的场景：造成内存泄露的本质原因只有一个，就是应当回收的对象没有正常被回收，变成了老生代中的常驻对象。）
方案：空间 —— 时间 折中，平衡。
难点：
- ① 培训，使编程技能提升；
- ② 技术积累，对比不同实现，选择最优方法，不断挑战。
如何突破挑战
进步不仅仅是技巧上的提高，往往是战略上的突破。
战略上突破变现为 —— 数据或表的重新表达 —— 程序的核心。
这也就是诞生诸多算法的原因，战略上的突破往往就是一种新的算法。
提纲掣领
这一章主要描述了计算机文档如何编写，应该包含哪些内容。
作者解释：文档本身可以作为检查列表（checkList），状态控制，也可以作为汇报的数据基础。
计算机产品的文档
目标:
定义需要、目标、资源、约束、优先级。
技术说明:
第一个产生，最后完成。手册和性能规格说明。
进度:
①预算：不仅仅是约束，还是最有用的文档之一，迫使制定技术决策，不会被忽略，促进策略决定。
②组织架构图：工作空间的分配。
③报价、预测、价格：三者互相牵制，决定项目成败。
管理任务焦点
- 时间——进度
- 地点——工作空间的分配
- 人员——组织图
- 项目内容——目标、产品技术说明
- 资金——预算
未雨绸缪
大多数软件项目都是一开始设计好算法，然后将算法应用到待发布的软件中，接着根据进度安排，将第一次开发的产品发布给客户。
然而，对于大多数项目，第一次开发的系统往往并不好用。
- 它可能太大、
- 太慢，
- 难以使用。
许多原型设计上的痛点总是在项目落地之后才显现出来。
要解决所有的问题，开发出一个更灵巧或者更好的系统，除了重新开始之外，没有其他办法。
旧系统的丢弃可以一步完成，也可以一块块地实现。
所有大型系统的经验都显示，这是必须完成的步骤。
为变更设计系统
- 细致的模块化；（架构设计+技术选型+服务划分）
- 可扩展的函数；（这个太熟悉了）
- 精确完整的模块间接口设计；（架构设计合理，接口规定定义，明确服务功能边界）
- 完备的文档；（产品文档+api文档+技术方案文档+需求文档+用户使用说明文档等等）
- 调用队列；（是不是模块之间调用的时序图）
- 表驱动；（现在服务商也有很多）
- 减少变更引起的错误
- ① 使用高级语言，现在这个已经很普遍，作者那个时候高级语言还很少，且没有现在智能；
- ② 自文档技术，这一点现在做得也比较好了，javadoc等
为什么缺陷不能更彻底的修复？
程序维护（设计缺陷的修复，这些软件的变更通常包含了更多的功能新增）中一个基本问题 —— bug修复总会固定在 20% ~ 50% 的几率引入新的bug。所以整个过程是前进两步，后退一步。
麻省理工学院核科学实验室 Betty Campbell 指出，特定版本的软件发布生命周期有一个有趣的循环。
- 起初，上一个版本中被发现和修复的bug，在新的版本中仍会出现。
- 新版本的新功能会产生新的bug。解决了这些问题之后，程序会正常运行几个月。
- 接着，错误率会重新攀升。
Betty 认为，这是因为用户的使用达到了新的熟练水平，他们开始运用新的功能，这种高强度的考验查出了新功能中的很多不易察觉的问题。
那具体是什么导致bug不能被彻底修复呢？
- bug看似是局部的，实际上是系统级别的，范围更大。局部的修复量往往不大，很快就被解决，但是更大范围的修复往往会被忽略。
- 维护人员往往是新手或初级开发人员，不是最初编写的人员。
干将莫邪
这一章一言以蔽之：磨刀不误砍柴工。好的开发工具和开发环境可以极大地提高开发效率。
工具集
- 项目的关键问题是沟通，个性化的工具会妨碍沟通而非促进沟通。
- 所有的工具生命周期都很短。当机器和工作语言发生变化时，技术也会随之变化。
- 开发和维护公共的通用的编程工具，效率会更高。
- 自动化文档，
- 自动化生成代码，
- 快捷键唤醒各种便捷操作，
- 代码补全提示，
- 代码错误检查，
- 代码快速格式化，
- 各种GUI（用户可视化操作界面）操作工具
使编写的代码更加规范，使执行命令更加方便，如今这些都习以为常。
作者的40多年前的想法如今都得到了实现，而且技术发展的都很成熟，忍不住赞叹。
祸起萧墙(进度管理和监控的方法)
如何控制项目一点点的延期意外，导致最终灾难性的偏离。
慢性的进度偏离是士气杀手，这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付，最重要的就是要防微杜渐。
重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。
但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
进度对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。
为了加强我们对进度的监控，里程碑的定义 就至关重要了。
选择里程碑原则
里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
以下是一些反面的例子
例如编码，在代码编写时间达到一半的时候就经90％完成了；调试在大多时候都是99％完成的；计划完毕是任何人只要愿意，就可以声明的事件。
里程碑有明显边界和没有歧义，比它容易被老板核实更为重要。
如果里程碑定义得非常明确，以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。
但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。毕竟，没有人愿意承受坏消息。
这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。
在进度跟踪和管理上，必须要在整个团队中树立这种观念，就是要尽可能早的完成相关的任务，而不是拖到了最后在来做。
类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
当进度出现偏差后，项目经理往往把问题掩盖起来，而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失，但是往往情况并不是这么简单。
因为很多时候 引起进度的偏差往往存在一些问题的根源，而这些根源往往是需要老板提前介入并采取一些行动，因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。
没有银弹 —— 软件工程中的根本和次要问题
在未来的十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。
在古老的西方传说中，月圆之夜，受感染的人狼将会由人变狼。人狼出没，凶恶残暴，唯一能杀死他们的武器便是银制子弹。
在软件开发行业，我们一直渴求一颗消灭软件复杂度的银弹。
软件的复杂体现在它是纯思维的产物，是一个纯抽象的概念。
具体语法层面上的实现只是软件开发中的次要问题。
除非次要问题能占到开发活动的 9/10 以上，否则即使全部次要任务的时间缩减到零，也不会带来生产率数量级上的提高。
软件活动：分为根本任务和次要任务。
根本任务：打造构成抽象软件实体的复杂概念结构。
次要任务：使用编程语言表达这些抽象实体，在空间和时间的限制下将他们映射成机器语言。
根本困难
Brooks认为软件开发最困难的部分是规格说明、设计和测试这些概念上的结构，而不是对概念进行表达和实现逼真程度进行验证。
由于软件开发的（复杂度、一致性、可变性和不可见性）使得开发总是非常困难，为什么会这么说？
复杂度
首先两个软件，没有在语句级别上的相同，如果相同，我们往往会合并成可供调用的子函数。同时，计算机存在多种状态，这使构思、描述、测试都变得困难，而软件系统盘的状态又比计算机状态多若干个数量级。
其次，软件实体的扩展，是以不同元素实体的方式添加，这些元素以非线性递增方式交互，这使得整个软件的复杂度以非线性增长要多的多。
PS：软件复杂度是根本困难，不是次要因素
一致性
复杂性引申出来的延伸，由于不同人开发，使得复杂度随心所欲，毫无规则可言。
因此很多复杂性来自保持与其他接口的一致性，对软件的任何再开发，再设计，都无法简化这些复杂的特性。
这就使得软件的开发目标，很多情况是为了兼容性，必须遵循各种接口，这也就造成了复杂。
可变性
软件实体经常会遭受到持续的变更压力。
软件产品扎根与文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等。后者持续不断地变化着，这些变化无情的强迫这软件也随之变化。
没有做不完的需求，只有永远在变化的需求。
不可见性
软件是不可见的和无法可视化的，他的客观存在不具有空间的形体特征。
次要困难
解决软件构建上的困难。
使用高级语言可以提高开发效率，生产率会被提高。
有了高级语言，我们会更多的把经理放在数据结构，数据类型和操作的复杂度（时间复杂度或空间复杂度），程序开发也就会越来越接近用户复杂度。
总结
作者首先提出人月神话的概念与项目管理的困境，然后说明尽管人月神话无法达到，但仍可以通过一系列的方法无限逼近这一神话，帮助软件开发者进行项目管理。
- 为什么人月神话无法达到？
- 为什么软件工程的项目管理无法一帆风顺？
这一方面是由于计算机技术的飞速发展，人们不得不时刻更新自己的知识与技术.
另一方面，是来着软件开发这项工作本身具有的特性，所以作者给出了”没有银弹“论断，并针对性的提出了改善这种情况的建议：
- 采用新技术、
- 快速开发原型、
- 聘用卓越人才。
正如作者所说的那样，软件工程可能是人类创造出的最错综复杂的一项工作，甚至，这种复杂度还在不断增加，人们能做的，只有不断学习更新的技术，探索更好的管理方法。
扩展资源
百度网盘资源
链接: https://pan.baidu.com/s/1hsD93OZf7YsgY0KFfCDUrA?pwd=7tfn 提取码: 7tfn
参考文档
- https://zhuanlan.zhihu.com/p/563702295
- https://blog.csdn.net/weixin_42238037/article/details/125024705
2233
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
