分享我的 20 年编程指导原则
原文链接：My guiding principles after 20 years of programming，作者：Alex Ewerlöf，发布于 Jan 23, 2020
我从 1999 年开始编程，今年我已经编程 20 多年了。我从 Basic 开始，但很快就跳到 Pascal 和 C，然后用 Delphi 和 C++ 学习了面向对象编程（OOP）。2006 年我开始使用 Java，2011 年我开始使用 JavaScript。我有一个宽领域的职业生涯，曾在使用机器人技术、金融技术、医疗技术到媒体和电信的企业工作过。我有很多角色，包括研究员、CTO、TPM（技术产品经理）、培训师、系统架构师或 TL（技术领导），虽然我有不同的帽子，但我一直在编码。我开发了一些为数百万人服务 的产品，也有一些在发布之前就失败了。我曾担任顾问，甚至拥有自己的创业公司。我在开源项目、闭源项目和内部开源项目（由公司内部社区开发的专有代码）上花费了大量时间。我不仅在 MCU（微控制器）上编程，还涉及移动和桌面应用程序，以及云服务器和最近非常流行的无服务器（serverless）。
在我的 20 年编程周年纪念日，我试图列出多年来积累的顶级原则 —— 它们是我职业生涯的指导原则。
- 不要与工具作斗争：库、语言、平台等。尽量使用本地开发，不要钻技术的牛角尖，也不要钻问题的牛角尖。学会为工作选择正确的工具，否则你就要为使用你熟悉的工具而找工作。
- 你不是为机器编写代码，而是为你的同事和未来的自己编写代码（除非它是一个废弃的项目或者你正在编写汇编代码）。或者只是写出来供初学者参考。
- 任何重要且有价值的软件都是协作的结果。学会有效沟通并公开协作，信任他人并赢得他们的信任，尊重人胜过代码。以身作则，将你的追随者转变为领导者。
- 学会分而治之。针对特定功能编写低耦合的独立软件模块，做好单元测试和整体测试，确保代码功能正确，避免放大问题。
- 把代码和自己分离。不要让自己成为代码的首选人（唯一的负责人），你要优化代码，让其他人找到方法来修复错误和添加功能。这样你才能解放自己，继续去做下一个项目。记住不要拥有代码，否则你将永远无法脱身。
- 安全性是分层的：每一层都需要单独评估，但也与整体相关。风险是一项业务决策，与脆弱性和概率直接相关。每个产品/组织都有不同的风险偏好（他们愿意为更大的胜利承担的风险）。通常这三个问题相互冲突：用户体验、安全性、性能。
- 你要意识到每块代码都有它的生命周期并且会死掉。有时它在看到进入生产环节之前就夭折了，放手就好。你需要了解 4 类功能之间的区别，以及将时间和精力放在哪里：
- **核心：**就像汽车中的发动机。没有它，产品毫无意义。
- **必要：**就像汽车的备胎。你很少关注它，但在需要时，它的功能决定了系统的成功与否。
- **附加价值：**就像汽车的杯架。 拥有它很好，但没有它，该产品完全可用。
- **独特的卖点：**人们应该购买你的产品而不是你的竞争对手的主要原因。例如，你的汽车是最好的越野车。
- 不要将你的身份附加到你的代码中。不要将任何人的身份附加到他们的代码中，应该意识到人与他们生产的人工制品是分开的。就事论事，不要带偏见地批评别人的代码。
- 技术债务就像快餐。有时它是可以接受的，但如果你习惯了它，它会比你想象的更快地杀死产品（并且以一种痛苦的方式）。
- 在对解决方案做出决定时，一切都是平等的，请优先考虑：安全性 > 可靠性 > 可用性（可访问性和用户体验） > 可维护性 > 简单性（开发人员体验/DX） > 简洁性（代码长度） > 成本 > 绩效。但不要盲目遵循，因为它取决于产品的性质。像任何职业一样，你的经验越丰富，你就越能在各种特定情况下找到适当的平衡。例如，在设计游戏引擎时，性能具有最高优先级，但在创建银行应用程序时，安全性是最重要的因素。
- 复制和粘贴是 Bug 的繁衍方式。没错，很多 Bug 就是这样繁殖的。你应该始终阅读你复制的内容，始终审核你导入的内容。Bug 很容易在复杂性中隐藏，为什么代码在这里运行良好，在那里就不行了。
- 不要只为正确的场景编写代码。写下 Errors 并说明它为什么会发生、它是如何被检测到的以及可以做些什么来解决它。验证所有系统输入（包括用户输入）：尽早出错，但尽可能从错误中恢复。
- 不要使用依赖，除非导入、维护、解决 Bugs 以及在它们不满足需求时进行重构的成本明显低于你拥有的代码。
- 远离炒作驱动的开发。但尽你所能去学习，总是有 pet projects（作为个人喜好而追求的项目、活动或目标，而不是因为它被普遍认为是必要的或重要的）。
- 走出你的舒适区。每天学习，把你学到的东西教给别。让自己接触其他语言、技术、文化并保持好奇心。
- 好的代码不需要文档，好的代码本身就是 well documented，因此任何没有参与进化、试错过程和导致当前状态的需求的人都可以使用它来提高工作效率。未记录的功能是不存在的功能，不存在的功能不应该有代码。
- 尽可能避免覆盖（overriding）、继承（inheritance）和隐式智能（implicit smartness）。编写纯函数，它们更容易测试和推理。任何不纯的函数都应该是一个类，任何具有不同功能的代码结构都应该有不同的名称。
- 除非你完全理解问题/需求，否则永远不要开始编码（制定解决方案）。在听和读上花的时间比敲键盘还多是很正常的。因此在开始编码之前，你要了解该领域。问题/需求就像一座迷宫，你需要逐步完成代码-测试-改进（code-test-improve）周期，才能探索这座迷宫，直到你到达终点。
- 不要解决不存在的问题。不要做投机编 程（speculative programming）。只有当它是一个经过验证的假设，它是真需求时才增加代码。因为很可能当它被扩展时，问题定义看起来和你编写代码时不同。也不要过度设计，专注于解决手头的问题并以有效的方式实施有效的解决方案。
- 一起制作的软件更有趣。建立一个可持续的社区，倾听、激发、学习、分享（Listen. Inspire. Learn. Share）。
我并不声称自己是软件开发的权威，上面这些只是我一路上获得的智慧。我敢肯定，再过 20 年，这份清单会更加成熟。