巧匠因为他的工具而出名。
- 谚语
A good workman is known by his tools.
- PROVERB
干将莫邪
本章一开始就阐述了一种普遍现象，即每个人会有一套自己趁手的工具。
就工具而言，即使是现在，很多软件项目仍然像一家五金店。每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集，这些工具成为个人技能的直观证明。正是如此，每个编程人员也保留着编辑器、排序、内存信息转储、盘实用程序等工具。
这种方法对软件项目来说是 愚蠢 的。首先，项目的 关键问题是沟通 ， 个性化的工具妨碍——而不是促进沟通 。其次，当机器和语言发生变化时，技术也会随之变化， 所有工具的生命周期是很短的 。
毫无疑问，开发和维护公共的用编程工具的效率更高。不过，仅有通用工具是不够的。专业需要和个人偏好同样需要很多专业工具。所以在前面关于软件开发队伍的讨论中，我建议为每个团队配备一名工具管理人员。这个角管理所有通用工具，能指导他的客户－老板使用工具。同时，他还能编制老板需要的专业工具。
摘抄
6小时中连续10次操作的生产率，比间隔3小时的10次操作要高许多，因为持续的精力集中能减少思考时间。
“最佳实践”
随之提出了 目标机器 和 辅助机器 的概念；但如今可能用docker为首的容器可能会更好，我准备去了解podman。
大概总结就以下几点
- 容器
- 良好的文档管理
- 尽早用真机跑跑你的代码
- 尽可能使用高级语言
对于高级语言，传统反对意见有哪些呢？这里有三点：它无法完成我想做的事情；目标代码过于庞大；目标代码运行速度过慢。
以下是就其的反驳：
- 就功能而言，我相信反对不再存在。所有证据都显示了人们可以完成想做的事情，只是需要花费时间和精力找出如何做而已，这可能需要一些讨人嫌的技巧。
- 就空间而言，新的优化编译器已非常令人满意，并且将持续地改进。
- 就速度而言，经优化编译器生成的代码，比绝大多数程序员手写代码的效率要高。而且，在前被全面测试之后，可以将其中的百分之一至五替换成手写的代码，这往往能解决速度方面的问题
- 好的IDE
交互式编程的生产率至少是原来的两倍
工欲善其事，必先利其器。vscode了解一下