分享我的 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 年编程周年纪念日,我试图列出多年来积累的顶级原则 —— 它们是我职业生涯的指导原则。

  1. 不要与工具作斗争:库、语言、平台等。尽量使用本地开发,不要钻技术的牛角尖,也不要钻问题的牛角尖。学会为工作选择正确的工具,否则你就要为使用你熟悉的工具而找工作。
  2. 你不是为机器编写代码,而是为你的同事和未来的自己编写代码(除非它是一个废弃的项目或者你正在编写汇编代码)。或者只是写出来供初学者参考。
  3. 任何重要且有价值的软件都是协作的结果。学会有效沟通并公开协作,信任他人并赢得他们的信任,尊重人胜过代码。以身作则,将你的追随者转变为领导者。
  4. 学会分而治之。针对特定功能编写低耦合的独立软件模块,做好单元测试和整体测试,确保代码功能正确,避免放大问题。
  5. 把代码和自己分离。不要让自己成为代码的首选人(唯一的负责人),你要优化代码,让其他人找到方法来修复错误和添加功能。这样你才能解放自己,继续去做下一个项目。记住不要拥有代码,否则你将永远无法脱身。
  6. 安全性是分层的:每一层都需要单独评估,但也与整体相关。风险是一项业务决策,与脆弱性和概率直接相关。每个产品/组织都有不同的风险偏好(他们愿意为更大的胜利承担的风险)。通常这三个问题相互冲突:用户体验、安全性、性能。
  7. 你要意识到每块代码都有它的生命周期并且会死掉。有时它在看到进入生产环节之前就夭折了,放手就好。你需要了解 4 类功能之间的区别,以及将时间和精力放在哪里:
    • 核心:就像汽车中的发动机。没有它,产品毫无意义。
    • 必要:就像汽车的备胎。你很少关注它,但在需要时,它的功能决定了系统的成功与否。
    • 附加价值:就像汽车的杯架。 拥有它很好,但没有它,该产品完全可用。
    • 独特的卖点:人们应该购买你的产品而不是你的竞争对手的主要原因。例如,你的汽车是最好的越野车。
  8. 不要将你的身份附加到你的代码中。不要将任何人的身份附加到他们的代码中,应该意识到人与他们生产的人工制品是分开的。就事论事,不要带偏见地批评别人的代码。
  9. 技术债务就像快餐。有时它是可以接受的,但如果你习惯了它,它会比你想象的更快地杀死产品(并且以一种痛苦的方式)。
  10. 在对解决方案做出决定时,一切都是平等的,请优先考虑:安全性 > 可靠性 > 可用性(可访问性和用户体验) > 可维护性 > 简单性(开发人员体验/DX) > 简洁性(代码长度) > 成本 > 绩效。但不要盲目遵循,因为它取决于产品的性质。像任何职业一样,你的经验越丰富,你就越能在各种特定情况下找到适当的平衡。例如,在设计游戏引擎时,性能具有最高优先级,但在创建银行应用程序时,安全性是最重要的因素。
  11. 复制和粘贴是 Bug 的繁衍方式。没错,很多 Bug 就是这样繁殖的。你应该始终阅读你复制的内容,始终审核你导入的内容。Bug 很容易在复杂性中隐藏,为什么代码在这里运行良好,在那里就不行了。
  12. 不要只为正确的场景编写代码。写下 Errors 并说明它为什么会发生、它是如何被检测到的以及可以做些什么来解决它。验证所有系统输入(包括用户输入):尽早出错,但尽可能从错误中恢复。
  13. 不要使用依赖,除非导入、维护、解决 Bugs 以及在它们不满足需求时进行重构的成本明显低于你拥有的代码。
  14. 远离炒作驱动的开发。但尽你所能去学习,总是有 pet projects(作为个人喜好而追求的项目、活动或目标,而不是因为它被普遍认为是必要的或重要的)。
  15. 走出你的舒适区。每天学习,把你学到的东西教给别。让自己接触其他语言、技术、文化并保持好奇心。
  16. 好的代码不需要文档,好的代码本身就是 well documented,因此任何没有参与进化、试错过程和导致当前状态的需求的人都可以使用它来提高工作效率。未记录的功能是不存在的功能,不存在的功能不应该有代码。
  17. 尽可能避免覆盖(overriding)、继承(inheritance)和隐式智能(implicit smartness)。编写纯函数,它们更容易测试和推理。任何不纯的函数都应该是一个类,任何具有不同功能的代码结构都应该有不同的名称。
  18. 除非你完全理解问题/需求,否则永远不要开始编码(制定解决方案)。在听和读上花的时间比敲键盘还多是很正常的。因此在开始编码之前,你要了解该领域。问题/需求就像一座迷宫,你需要逐步完成代码-测试-改进(code-test-improve)周期,才能探索这座迷宫,直到你到达终点。
  19. 不要解决不存在的问题。不要做投机编程(speculative programming)。只有当它是一个经过验证的假设,它是真需求时才增加代码。因为很可能当它被扩展时,问题定义看起来和你编写代码时不同。也不要过度设计,专注于解决手头的问题并以有效的方式实施有效的解决方案。
  20. 一起制作的软件更有趣。建立一个可持续的社区,倾听、激发、学习、分享(Listen. Inspire. Learn. Share)。

我并不声称自己是软件开发的权威,上面这些只是我一路上获得的智慧。我敢肯定,再过 20 年,这份清单会更加成熟。