本章节原标题：干将莫邪（yé）

前言

• 就工具而言，即使是现在（作书时），每位软件的公司的骨干人员都像五金店老板一样，仔细的保管着自己工作生涯中搜集的一套工具，这些工具是个人能力的直观证明。
• 这种方法对软件项目来说是愚蠢的，项目的关键问题是沟通，个性化的工具只会妨碍而非促进沟通。
• 随着技术的变化，所有个性化的工具生命周期都是很短的。开发和维护公共的通用编程工具效率更高。
• 仅仅通用是不够的，建议为每个团队配备一名工具管理人员。
• 项目经理应该制定一套策略，并且为通用工具开发分配资源。与此同时，他还必须意识到专业工具的需求。

目标机器

就目前服务器的发展速度而言，本节内容已经不具备具体的参考价值，但仍然有一些优秀的思想

• 使用机器进行调试的时间是爆发式的，几位程序员可能同时开发好自己的模块，需要使用机器进行调试。
• 需要安排一名系统程序员，保证机器上的软件是最新且可用的。
• 主程序库应该被划分为：（1）一系列独立的私有开发库；（2）正处于系统测试下的系统集成子库；（3）发布版本
• 在开发过程中，节省最大工作量的工具可能是文本编辑系统（强调沟通和文档）。
• 系统文档中存在大量不容易理解的问题，但仍然比未能详细描述系统特性的短小文章更可取。
• 自上而下、彻底的开发一个性能测试工具，尽可能早的开始这件事情，并听取“它的意见”。

高级语言和交互式编程

• 只有懒散和惰性会妨碍高级语言和交互式编程的应用（生产率和调试方面的优势是势不可挡的，要坚持使用新的技术）。
• 高级语言bug更少而且更容易寻找。
• 传统的反对意见——无法实现想要的功能、代码量太大、高级语言代码执行速度慢，随着语言和编译器的进步已不再成为问题。
• 某些应用上，批处理系统并不会被交互式系统所取代（现在依然成立）。
• 调试是系统编程中较漫长和较困难的部分，漫长的调试时间是调试的祸根。
• 有限的数据表明，系统软件开发中，交互式编程的效率起码是传统的两倍。

旧有的编程模式：编辑，保存，编译，运行和调试
交互式编程：直接输入脚本语句，回车执行，立即显示结果，不用经过复杂的保存和编译阶段，很多脚本语言都提供类似的控制台（PHP，Python）

以上就是《人月神话》第12章——干将莫邪的所有内容

本章主要说明了工具对于软件产业的重要性，工具需要做到通用，需要专人进行维护。看一看当下github的受欢迎程度，jetbrain这类工具提供商的地位，以及阿里云等服务器提供商的发展速度，还有当前对于新技术（ReactNative，Vue）新框架（ROR，Laravel）的推崇，完全印证了作者当年的观点。我们有理由相信阻碍高级工具发展的只有人们的懒散和惰性，这样的观点时至今日都是铁律。

个性化的工具是个愚蠢的选择，但也是顺其自然的选择，如果管理者不加以干预就必然会存在的。某种程度上具有合理性使得这种缺陷很难被管理人员重视。

不被重视的另一个重要原因是成本，通用工具的创造和维护是需要调配精英资源的。通用与个性化的实现难度不在同一个层面上，可以理解为通用是个性化的一种特殊形式，开发人员从无数个矩形中需要找到某个正方形。与成本相比，通用工具的收益是隐含的甚至是不可预计的，有可能需要多次迭代之后才能带来收益。

通用工具需要带来效率提升是有前提的，那就是通过该工具有效的降低了沟通成本。这就意味着通用工具应该是体系，而不是部件。通用工具需要迭代，但一定不是积累而来，工具同样需要具备概念完整性，需要团队意识到专业工具的需求。

综上，通用编程工具的出现有下面几个条件：
1、 管理者意识到通用工具的重要性
2、通用工具需要系统规划，而不是渐渐积累
3、公司能够承担开发的成本
4、工具维护人员具备技术实力

上面理解的工具是开发工具，另外还可以理解为开发环境。开发环境的问题随着虚拟技术的发展现在已经是过去式了，即便使用不同的电脑不同的操作系统，也能统一开发环境（VirtualBox）。

本章中提到的主程序库的划分，现在看来就是Git的一种使用策略罢了，不再需要专人维护而且十分好用，可以视为被解决掉的问题。但即便如此，为什么人月依然是个神话？

*转载-非商用-非衍生-保持署名（创意共享3.0许可证）