guiding-principles-after-20-years-of-programming
[My guiding principles after 20 years of programming | by Alex Ewerlöf | Medium](https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c)
作者从 1999 年开始编程，到今年（2020 年）已经 20 多年。刚开始学习 Basic 但不久转到 Pascal 和 C，然后通过 Delphi 和 C++ 学习面向对象编程。2006 年开始学习 Java，2011 年开始学习 JavaScript。从事领域广泛，从机器人、金融医疗科技到媒体电信。有时，我有不同的头衔（研究者、CTO、TPM（技术产品经理）、老师、系统架构师或者团队领导者），但在这些身份之后我一直在编程。我研发的产品，有些服务于百万人，有些在上线之前就已经失败。我做过顾问，还创过业。我花很多时间在开源项目、闭源项目和公司内部的开源项目（由公司内部的各个社区开发）。一开始在微控制器上工作，后来专注于移动端和桌面 App，再到后来的云服务和后来的无服务。
作者总结了工作 20 多年的一些指导原则：
- 不要被工具困住：库、语言和平台等。尽可能使用原生结构。不要曲解技术，同时也不要曲解问题。**为工作找到合适的工具**，否则你只能寻找适合工具的工作。
- 你并不是为机器写代码，你写代码是为了你的同事和**未来的自己**。
- 任何重要且有价值的软件都是协作的结果。高效沟通，开放协作。开始信任别人，并获得对方的信任。以身作则，让追随者成为领导者。
- 逐个击破。编写独立模块，每个模块都有各自的用途，所有模块松散结合在一起。分开测试各个模块，然后合并在一起测试一遍。保证测试接近现实情况，但也不放过边缘用例。
- **抛弃自我**。不要让自己成为提供优质代码的关键人物。让人们找到自己修复漏洞和添加特性的方式。解放你自己，让你及时进行下一个项目或工作。不要拥有代码，否则你将永远不会成长。
- 安全措施是分层次的：每层都需要能被单独访问，同时每一层次之间都有联系。风险是一种商业决策，与脆弱性和概率都有关系。每一个产品或组织都有不同的风险偏好。经常围绕这三个主题进行激烈讨论：用户体验、安全和性能。
意识到每段代码都有自己的生命周期，最终都会走向死亡。有时产品在婴儿时期便夭折。把这放下让它走。了解四种特性的区别，把你的时间和精力放到哪里。
- Core：核心特性像汽车引擎，必不可少。
- Necessary：必要特征像汽车的备用轮胎，很少用到，一旦使用就有很大帮助。
- Added value：附加特性像汽车上的杯座，有更好，没有也可以。
- Unique Selling Point：独特卖点，顾客买你的产品而不是竞争对手的主要原因。
- 不要将身份和代码绑定。不要将任何人和他们自己的代码绑定在一起。明白每个人和自己的产品是分开的。Don't take code criticism personally but be very careful when criticizing others' code.
- 技术债就像快餐。偶尔是可以接受的，但如果习惯于这些，产品会被快速杀死，以一种痛苦的方式。
- 有很多看似相同的解决办法，如果要决定这些选项，按照以下优先级： 安全 > 可靠性 > 可用性（可访问性 & 用户体验） > 可维护性 > 简单（开发者体验） > 简洁性（代码长度） > 财务 > 性能。 **但不要盲目按照这个优先级**，因为这还要根据具体的产品。和其他职业一样，你有更多经验，就更能在每个给定选项取得平衡。
- 复制粘贴催生 Bugs。Bugs 就是这样产生的。复制的时候仔细阅读代码，引入代码库的时候仔细审计代码。Bugs 存在于复杂代码中，自己的代码自己要熟悉。
- 不要只写顺利场景的代码，出错时的代码提示同样重要。一个好的错误提示可以告诉开发者发生了什么、如何检测、如何解决。验证所有系统输入（包括用户输入）：提前犯错提前找到解决办法。提供给用户足够多的出错解决方案，让他们快速解决问题。
- 不要使用依赖关系，除非导入、维护、处理它们的边缘情况/错误以及在它们不能满足需求时进行重构的成本明显低于你自己的代码。
- 远离炒作驱动的发展。但要尽你所能地学习。总是有一些宠物项目。
- 走出舒适区，每天学习。教授你学习的内容。只要你一直在学习，你就永远不是大师。让自己处于多种语言环境、技术和文化下，保持好奇心。
- 好的代码不需要文档，极好的代码拥有不错的文档，这样任何人对这个东西都可以从不熟悉到熟悉，并应用于自己的事情。如果一个特性没有被文档记录下来，那么这个特性就不应该存在。
- 尽可能避免智能地覆盖、继承和隐式。写纯函数，它们更容易测试和理解。如果函数不够简洁就应该是一个类，代码构造如何是不同的函数，则应该有不同的命名。
- 在充分理解代码之前不要编程。你需要逐步经历代码-测试-改进的循环，探索问题空间，直到你到达终点。
- 不要解决一个不存在的问题。不要做投机性的编程。只有在一个可扩展假设被验证后才开始扩展代码。Chances are by the time it gets extended, the problem definition looks different from when you wrote the code.不要过度设计：专注于解决手头的问题和以有效的方式实现解决方案。
- Software is more fun when it's made together. Build a sustainable community. Listen. Inspire. Learn. Share.