这是一篇翻译文章，已获得作者 Alex Ewerlöf 授权，原文地址：My guiding principles after 20 years of programming
我从 1999 年开始编程，今年我已经正式编码了 20 多年。我从 Basic 语言入门，但很快就转到 Pascal 和 C，然后用 Delphi 和 C++ 学习了面向对象编程（OOP）。2006 年我开始用 Java，2011 年我开始用 JavaScript。 我曾在多个行业工作过，从机器人、金融科技、医疗科技到媒体和电信。有时候我是作为研究员，CTO，TPM（技术产品经理），老师，系统架构师或者 TL（技术领导）的角色，但是我一直坚持编码。我参与一些为数百万人服务的产品，也有一些在发布前就失败了。我曾做过顾问工作，我甚至有自己的初创公司。我在开源项目、闭源项目和内部开源项目（公司内部团体开发的专有代码）上花了很多时间。我参与过微控制器，移动和桌面应用，再到云服务器，再到最近的 Serverless。
在我编程 20 周年的纪念日上，我试图列出多年来积累起来的最重要的原则，作为我职业生涯中的指导原则:
-
不要与工具作斗争：库、语言、平台等等。尽可能多地使用原生的开发方式。不要技术捆绑，但也不要问题捆绑。为工作选择合适的工具，否则你将不得不为你的工具找到合适的工作。
-
你不是为机器编写代码，而是为你的同事和未来的自己编写代码（除非它是一个废弃的项目，或者你正在编写汇编代码）。为了能给后来者作为参考而写代码。
-
任何重要且有价值的软件都是协作的结果。有效沟通和公开合作。信任别人，进而赢得别人的信任。尊重人胜过尊重代码。以身作则。把你的追随者变成领导者。
-
分而治之。编写具有分离关注点的松散耦合的独立模块。分别测试每个部分然后一起（集成）测试。保持测试接近实际，但也要测试边缘用例。
-
轻视自己。不要成为代码的关键人物。对它进行优化，以便人们找到修复 Bug 和向代码添加功能的方法。解放自己，以进入下一个项目/公司。不要拥有代码，否则你将永远无法超越它。
-
安全是分层的：每一层都需要单独评估，但也需要与整体相关。风险是一种商业决策，与脆弱性和概率有直接关系。每个产品/组织都有不同的风险偏好（为了更大的收益，他们愿意承担的风险）。通常这三个关注点会相互冲突：用户体验、安全性、性能。
-
要认识到，每段代码都有一个生命周期，并且会死亡。有些时候，还没看到上线的曙光就在婴儿时期夭折了。接受放手。了解三类功能的区别:
核心：就像汽车的引擎。没有它，产品就没有意义。
必要的：就像汽车的备件。它很少被使用，但是当需要时，它的功能决定了系统的成功。
附加价值：就像汽车的杯座一样。最好有一个，但产品没有它是完全可用的。
-
不要将您的身份附加到代码中。不要把任何人的身份附加到他们的代码上。要意识到，人是独立于他们的工作产出物之外的。不要把代码批评当成是针对你个人的，但是在批评别人的代码时也要非常小心。
-
技术债就像快餐。有时这是可以接受的，但如果你习惯了，它会超乎你想象地更快地杀死产品（而且是以一种痛苦的方式）。
-
当你为解决方案做决定的时候，假设其他条件都是一样的，按照这个优先级:
安全性 > 可用性(可访问性和用户体验) > 可维护性 > 简单性（开发人员体验/DX）> 简短性（代码长度） > 性能
但是不要盲目地遵循它，因为它取决于产品的性质。 就像任何职业一样，你获得的经验越多，你就越能在每个特定的情况下找到合适的平衡点。例如，在设计游戏引擎时，性能是最重要的，但在创建银行应用程序时，安全性是最重要的因素。
-
复制和粘贴孕育了 Bug。这就是它们繁衍的方式。总是搞明白你复制过来的内容，总是审核你导入的内容。Bug 藏身在复杂性当中。“魔法” 在我的依赖库里能接受，但是不能出现在我的代码里。
-
不要只为乐观场景写代码。写出好的错误提示，回答为什么会发生，如何检测到它，以及如何解决它。验证所有系统输入（包括用户输入）：快速失败，但尽可能从错误中恢复。假设用户拿着枪：在你的错误信息上投入足够的努力去说服他们射击别的东西而不是你的头!
-
不要使用依赖库，除非导入、维护、处理它们的边界情况/Bug 和他们不满足需求时重构的成本远远低于你拥有的代码。
-
远离 炒作驱动的开发。但是要尽可能地学习。总是有自己的宠物项目。
-
走出你的舒适区。每天学习。把你学过的东西教给别人。如果你是大师，你就不需要学习。让自己接触其他语言、技术、文化，保持好奇心。
-
好的代码不需要文档，伟大的代码有良好的文档，这样任何没有经历过演进、试错过程和明白导致当前状态的需求的人都可以使用它。未文档化的功能是不存在的功能。不存在的功能不应该有代码。
-
尽量避免覆盖、继承和隐式小聪明。写纯函数。它们更容易测试和推理。任何非纯函数都应该是类。任何具有不同函数的代码构造都应该具有不同的名称。
-
除非你完全理解了问题，否则永远不要开始编码（制定解决方案）。花更多的时间在听和读而不是编码上是很正常的。在开始编写代码之前了解领域知识。一个问题就像一个迷宫。您需要逐步地经历 “编码-测试-改进” 周期，并探索问题空间，直到您完成。
-
不要去解决不存在的问题。不要进行投机性编程。只有确定代码将来会被扩展，才花功夫提高代码的扩展性。当代码要被扩展时，有很大的可能性问题定义已经与代码初次编写时不同了。
-
大家一起开发软件时更有趣。建立一个可持续发展的社区。听。灵感。学习。分享。
我并不是软件开发方面的权威。这些都是我一路走来获得的智慧。我相信另一个 20 年后这个列表会更加完善。