我从《程序员修炼之道》中学到的 69 个技巧

《程序员修炼之道》是安德鲁·亨特和戴维·托马斯于1999年合著的一本书。过去几个月我一直在阅读这本书，最终的印象是，我相信任何程序员都能从中有所收获。无论新手还是经验丰富的程序员，这本书都充满了实用建议。为了方便参考，我用辣椒（🌶）标记了一些最有价值的技巧。

如果你喜欢这篇文章，请购买这本书。

那么，要成为一名实用程序员，你需要做什么？

1) 早期采用者/快速适应者

2）好奇心强

3）批判性思考者

4）现实

5）万事通

6）注重工艺

7) 从不开启自动驾驶模式

8) 务实的程序员会超越眼前的难题，总是试图将其置于更大的背景下思考🌶

9）他们对自己所做的一切负责。

10）不怕承认无知或错误🌶

11）你需要具备广泛的知识和经验才能完成这一切。学习是一个持续不断的过程。

12）当你承担了某个结果的责任时，你就应该预料到自己会被追究责任。

13）在向任何人解释某件事为什么做不到、已经过期或出了问题之前，先停下来，听听自己的想法。他们会问“你试过这个吗……”或者“你难道没考虑到这一点吗？”……你会如何回应？🌶

14) 我们需要决定在单元测试层面测试哪些内容。通常，程序员会随意地向代码中添加一些数据，然后就声称测试完成了。如果我们运用契约式设计理念，就能做得更好。这种测试方法要求我们首先测试模块的子组件。子组件验证通过后，才能对模块本身进行测试。

15) 通过设计代码以通过测试并实现其合同，您可以考虑边界条件和其他一些您原本不会想到的问题。

16）不断审视你周围发生的事情，而不仅仅是你个人正在做的事情🌶

17) 许多用户宁愿现在就使用一些尚不完善的软件，也不愿等待一年才能使用多媒体版本。

18）你必须定期投资于你的知识储备。

19）拥有最好的想法、最精妙的代码或最务实的思考，如果不能与他人沟通，最终都将毫无意义🌶

20）当你面临重要会议时，记下你想传达的想法，并计划几种传达这些想法的策略。

21）只有传递信息，才算是沟通。而要做到这一点，你需要了解受众的需求、兴趣和能力🌶

22）确保你所说的话在时间和内容上都切合实际。有时候，只需要问一句简单的问题：“现在是谈论……的好时机吗？”

23）程序员始终处于维护模式

24) 强制重复：开发人员感到别无选择——环境似乎要求重复。

25）无意重复：开发人员没有意识到他们正在重复编写信息。

26）急于求成的重复劳动：开发者会变得懒惰，因为重复劳动看起来更容易。🌶

27) 开发人员间信息重复：团队中的多人重复输入同一条信息。

28）糟糕的代码需要大量的注释。

29）我们都知道，在时间紧迫、工作繁忙的时候，我们往往会推迟文档的更新。

30）指定一名团队成员担任项目图书管理员，其职责是促进知识交流。

31) 如果改变其中一个事物不影响其他任何事物，则称这两个或多个事物是正交的。

32) 我们希望设计的组件是自包含的：独立且具有明确单一用途。当组件彼此隔离时，您可以放心地更改其中一个组件，而无需担心其他组件受到影响。

33) 编写正交系统可获得两大好处：提高生产效率和降低风险🌶

34) 单个组件可以设计、编码、单元测试后就无需再管了。添加新代码时，无需不断修改现有代码。

35) 正交方法有利于重用，并且可能更容易进行测试，因为更容易对其组件进行设计和运行测试。

36）当团队组织结构中存在大量职责重叠时，成员之间容易对职责感到困惑。任何变更都需要召开全体团队成员会议，因为任何成员都可能受到影响。

37）如果我大幅改变某个特定功能的需求，会有多少个模块受到影响？在正交系统中，答案应该是“一个”。

38）避免使用全球数据🌶

39) 保持代码解耦🌶

40）避免类似的功能

41）编写单元测试本身就是对正交性的一次有趣的检验。是否需要引入系统其他部分的很大一部分才能编译测试？如果是这样，说明你发现某个模块与系统其他部分解耦不足。

42）任何时间估算的第一步都是要理解问题所在。在咖啡机旁随意给出的估算，将来一定会让你后悔莫及。🌶

43）在开始之前，要严格确定自己能够接受的条件，并且尽可能少地承诺回报。

44）调试时，不要因为你“知道”某个例程或代码片段有效就忽略它。不要想当然——要证明它有效。🌶

45) 所报告的问题是底层 bug 的直接结果，还是仅仅是症状？这个 bug 真的存在于编译器中吗？还是操作系统中？或者存在于你的代码中？如果你向同事详细解释这个问题，你会怎么说？如果可疑代码通过了单元测试，这些测试是否足够完整？如果使用这些数据运行单元测试会发生什么？导致此 bug 的情况在系统的其他地方是否存在？

46) 你可以说服自己错误不可能发生，然后忽略它。但务实的程序员会告诉自己，如果出现了错误，那就说明发生了非常糟糕的事情。

47）一个完全失效的程序通常比一个功能受损的程序造成的损害要小得多。🌶

48）如果我移除所有异常处理程序，这段代码还能运行吗？如果答案是“否”，那么可能是异常在非异常情况下被使用了。

49) 分配资源的例程或对象应该负责释放资源。

50）按照与分配资源的顺序相反的顺序重新分配资源。

51）保持灵活性的一个好方法是少写代码。🌶

52）你是否依赖于“滴答”声先于“咚咚”声出现？如果你想保持灵活性，那就不要。

53）始终考虑并发性进行设计。

54）将视图与模型分开

55）弗雷德不知道代码为什么会出错，因为他一开始就不知道代码为什么能运行。永远要清楚自己在做什么。弗雷德任由事情慢慢失控，最终自己像温水煮青蛙一样被煮熟了。🌶

56）尝试开发你并不完全了解的应用程序，或者使用你不熟悉的技术，很容易被巧合误导。🌶

57）如果基本面或基础设施不正确，再华丽的装饰也毫无意义。

58）不要成为历史的奴隶。不要让现有的代码决定未来的代码🌶

59）如果代码不再适用，所有代码都可以替换。

60）下次当你发现某件事似乎奏效了，但你不知道为什么时，一定要确认这不仅仅是巧合。

61）与其说是建造，不如说软件更像是园艺🌶

62) 不要尝试同时进行重构和添加功能。

63) 在开始重构之前，务必确保编写了完善的测试。尽可能频繁地运行测试。这样，你就能快速知道你的更改是否破坏了任何功能。

64）测试你的软件，否则你的用户会

65）无论它包含哪些“最佳实践”，任何方法都无法取代思考。🌶

66）好的需求文档应保持抽象性。

67) 团队对外秉持统一的立场——在内部，我们鼓励活跃而激烈的辩论。

68）问问自己，该软件在实际条件下（例如每秒预期用户数、连接数或事务数）是否满足性能要求？它是否具有可扩展性？

69) 关于文档，我们希望看到简单的模块级头部注释、重要数据和类型声明的注释，以及每个类和每个方法的简短头部注释。