我编程20年的指导原则

My guiding principles after 20 years of programming

I’ve been programming since 1999 and this year I’ve officially coded for 20+ years. I started with Basic but soon jumped into Pascal and C and then learned object oriented programming (OOP) with Delphi and C++. In 2006 I started with Java and in 2011 I started with JavaScript. I’ve worked with a wide range of businesses from robotics, fin tech, med tech to media and telecom. Sometimes I had a different hat as a researcher, CTO, TPM (technical product manager), teacher, system architect or TL (technical leader) but I’ve always been coding. I’ve worked on some products that served millions of people, and some that failed before being released. I worked as a consultant and I even had my own startup. I have spent lots of time on open source projects, closed source projects and internally open source projects (proprietary code that is developed by a community inside the company). I’ve worked with tiny microcontrollers all the way to mobile and desktop apps to cloud servers and lately serverless.

我从1999年开始写程序，到今年已经在工作中写了20多年的代码了。最初我写的是Basic，但是很快就跳到Pascal和C，紧接着我又在Delphi和C++的编码中学习了面向对象（OOP）编程。从2006年开始起我学习Java语言，2011年我开始涉及JavaScript的编程。我工作的业务范围很广，机器人、金融科技（fintech）、基于媒体和电信网络的医疗技术（远程医疗）。我的职称也在不断变化：研究者、CTO、TPM（技术产品经理）、老师、系统架构师、TL（技术负责人），唯一不变的是我一直在写代码。我开发的产品有的有几百万的用户，有的还没有发布就失败了。我甚至有自己的创业公司，我的角色是顾问。我花了很多时间在开源项目、闭源项目以及内部的开源项目上（由公司内部社区开发的专有代码）。我从事过小的微控制器的开发、手机和桌面应用的开发、云服务器的开发以及最近“无服务器”（serverless）开发。

在我编程20周年之际，我尝试列出在这些年中我不断积累的职业生涯指导准则中的那些最重要的准则：

1. Don’t fight the tools: libraries, language, platform, etc. Use as much native constructs as possible. Don’t bend the technology, but don’t bend the problem either. Pick the right tool for the job or you’ll have to find the right job for the tool you got.
   不要和工具作斗争：库、语言、平台，等等。尽可能的使用那些原生的工具。不要尝试着去折服技术，但也不要屈服于你碰到的问题。使用正确的工具来工作，否则你将不得不重新找个工作来让你已有的工具发挥作用。

2. You don’t write the code for the machines, you write it for your colleagues and your future self (unless it’s a throw away project or you’re writing assembly). Write it for the junior ones as a reference.
   你不是为机器写代码，你是为你的同事和未来的你写代码（除非你从事的项目是一个注定会放到垃圾桶的项目或者你写的是汇编语言）。作为参考，你应该写一些初级者都能看懂的代码。

3. Any significant and rewarding piece of software is the result of collaboration. Communicate effectively and collaborate openly. Trust others and earn their trust. Respect people more than code. Lead by example. Convert your followers to leaders.
   任何重要和有价值的软件都是团队合作的结果。高效沟通、开放合作。信任别人同时也赢得别人的信任。像尊重代码一样，更加尊重人。通过以身作则来进行领导。将这样的下属变为领导。

4. Divide and conquer. Write isolated modules with separate concerns which are loosely coupled. Test each part separately and together. Keep the tests close to reality but test the edge cases too.
   分而治之。对于单独的问题，写一些独立的低耦合的模块。对每个部分进行单独测试，同时也将它们进行集成测试。测试应该密切联系实际，同时对于那些不常见的边缘场景也要进行测试。

5. Deprecate yourself. Don’t be the go-to person for the code. Optimize it for people to find their way fixing bugs and adding features to the code. Free yourself to move on to the next project/company. Don’t own the code or you’ll never grow beyond that.
   降低自己的存在感。对于你写的代码，不要让你成为唯一被找的人。你应该优化你的代码使其它人也能够容易上手修理其中的bug或者添加新功能。这样你将会很自由的进入到下一个项目或公司。不要成为你代码的唯一负责人，否则你将很难超越自己。

6. Security comes in layers: each layer needs to be assessed individually but also in relation to the whole. Risk is a business decision and has direct relation to vulnerability and probability. Each product/organization has a different risk appetite (the risk they are willing to take for a bigger win). Often these 3 concerns fight with each other: UX, Security, Performance.
   代码的安全性来自多个层次：每个层次需要独立的评估但也需要进行整体考虑。商业决策是有风险的，这和代码的脆弱性和概率相关。每个产品或组织都有不同的风险偏好（risk appetite）。通常这3个方面的内容会相互斗争：用户体验（UX）、安全、性能。

7. Realize that every code has a life cycle and will die. Sometimes it dies in its infancy before seeing the light of production. Be OK with letting go. Know the difference between 3 categories of features:
   Core: like an engine in a car. The product is meaningless without it.
   Necessary: like a car’s spare will. It’s rarely used but when needed, its function decides the success of the system.
   Added value: like a car’s cup-holder. It’s nice to have but the product is perfectly usable without it.
   你必须接受代码都有生命周期，最终都会走向死亡。有时在写好不久，因为别的原因，你写的代码不能进入到产品中。对于这些应该学会接受。了解3类不同功能的差异：
   **核心功能(Core)：**就像发动机之于汽车。没有它产品毫无意义。
   **必须的功能（Necessary）: **就像汽车的备用系统。它很少被用到，但是一旦用到，它的功能决定了整个系统是否成功。
   锦上添花(Added value)的功能: 就像汽车的杯托。有它很好，没有它产品也能很好的工作。

8. Don’t attach your identity to your code. Don’t attach anyone’s identity to their code. Realize that people are separate from the artifacts they produce. Don’t take code criticism personally but be very careful when criticizing others’ code.
   不要将你的身份信息添加到代码中去。也不要将其它任何人的身份信息添加到代码中。意识到人和他产生的作品应该是独立的。不要从个人的角度批判代码，批判别人的代码时要非常小心。

9. Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way).
   技术债就像快餐食品。偶尔吃一下还好，但是如果你吃习惯了，它将使用一种很痛苦的方式很快的杀死你的产品。

10. When making decisions about the solution all things equal, go for this priority:
    Security > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Performance
    But don’t follow that blindly because it is dependent on the nature of the product. Like any career, the more experience you earn, the more you can find the right balance for each given situation. For example, when designing a game engine, performance has the highest priority, but when creating a banking app, security is the most important factor.
    当为产品做决定时，如果各方面情况相差无几，采用下面的优先级：
    安全性 > 可用性（可访问性和用户体验） > 可维护性 > 简单性（开发人员体验） > 间接性（代码长度） > 性能表现
    但也不要盲目的采用它，因为它和我们产品的性质密切相关。就像任何职业一样，你获取到的经验越丰富，对于某种情形，你就能找到更好的平衡。比如，当设计一个游戏引擎，性能的优先级最高，当做一个银行app时，安全性又是最重要的因素。

11. Bugs’ genitals are called copy & paste. That’s how they reproduce. Always read what you copy, always audit what you import. Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code.
    软件Bugs都是通过复制和粘贴产生的。当你复制代码时，仔细读懂它，检查你引入的这些代码。Bug通常隐藏在复杂（complexity）之中（比如过深的嵌套，复杂的条件）。它的魔术之处在于在其它地方是正常的，但粘贴过来放在我的代码中就不正常了。

12. Don’t only write code for the happy scenario. Write good errors that answer why it happened, how it was detected and what can be done to resolve it. Validate all system input (including user input): fail early but recover from errors whenever possible. Assume the user hold a gun: put enough effort into your errors to convince them to shoot something other than your head!
    不要只为正常场景写代码。对于那些异常场景，也要有好的错误处理代码来回答为什么会出现这样的情况，我们可以做些什么来解决这个问题。检查所有的系统输入（包括用户输入）：当有问题时，尽可能早报错，尽可能早的从错误中恢复。当出现问题时，假想用户拿着一把枪，我们应该努力使客户去找别的地方的问题而不是爆你的头。

13. Don’t use dependencies unless the cost of importing, maintaining, dealing with their edge cases/bugs and refactoring when they don’t satisfy the needs is significantly less than the code that you own.
    不要使用别人的代码，除非引入、维护、解决代码中的边际场景或bug以及在不满足需要时进行重构所花费的代价小于你自己的代码

14. Stay clear from hype-driven development. But learn all you can. Always have pet projects.
    远离通过时髦或流行的技术驱动开发的模式。应该尽量的学习你所学到的东西。多做一些好玩的项目。

15. Get out of your comfort zone. Learn every day. Teach what you learn. If you’re the master, you’re not learning. Expose yourself to other languages, technologies, culture and stay curious.
    远离自己的舒适区。每天不间断的学习。将你所学习的东西教给别人。如果你觉得自己是大师，那么你就不会学习。将自己置身于其它语言、技术、文化中，保持好奇心。

16. Good code doesn’t need documentation, great code is well documented so that anyone who hasn’t been part of the evolution, trial & error process and requirements that led to the current status can be productive with it. An undocumented feature is a non-existing feature. A non-existing feature shouldn’t have code.
    好的代码不需要文档，伟大的代码有非常良好的文档，即使那些没有参与代码的演化、试用、错误处理等的人，当需要在当前的代码中添加新的需求时，也会非常有效率。一个文档中没有列出的功能是一个不存在的功能。一个不存在的功能不应该有相应的代码实现。

17. Avoid overriding, inheritance and implicit smartness as much as possible. Write pure functions. They are easier to test and reason about. Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name.
    尽可能避免重载，继承和隐式类型转换。多写简单的一般的函数。它们可以更容易的被测试和被理解。任何不能用一般函数写出来的功能应该写成一个类。组成类的不同的功能的函数应该有不同的名字。

18. Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.
    在彻底了解你要解决的问题之前，不要匆忙开始编写代码或者提供解决方案。花更多的时间在听或读上而不是敲代码上是正常的。开始编程前理解你的业务。问题就像迷宫，你需要不断的经历编码、测试、改进的循环，这样不断的探索你的问题域，直到找到出口。

19. Don’t solve a problem that doesn’t exist. Don’t do speculative programming. Only make the code extensible if it is a validated assumption that it’ll be extended. Chances are by the time it gets extended, the problem definition looks different from when you wrote the code.
    不要解决不存在的问题。不要过度编程。只在具有合理假设代码将来需要扩展的情况下，才写可扩展的代码。多数情况下是当需要扩展时，需求也和最初写代码时的不一样了。

20. Software is more fun when it’s made together. Build a sustainable community. Listen. Inspire. Learn. Share.
    和大家一块写代码更有趣。创立一个可持续的团体，大家在中间一块倾听、启迪、学习、分享。

I don’t claim to be an authority in software development. These are just the wisdom I earned along the way. I’m sure this list will be more mature after another 20 years.
在这里，我不是说我是软件开发界的权威。上面那些只是我一路走来学习到的一些智慧。相信再过20年，上面的列表会更加成熟。

原文链接：

https://medium.com/@alexewerlof/my-guiding-principles-after-20-years-of-programming-a087dc55596c