原文
我曾与一些杰出的工程师共事过 – 在诸如 FAANG 的大公司，也在初创规模的小公司。他们让我看到，传说中的「10 倍」工程师，真实存在！
如今，这些工程师中，有些人后来创办了自己的公司，他们领导的变革改变了我们对网络的认识（比如 Vercel！）；有些人成长为了大型科技公司数十亿美元项目的领导者。
与他们合作时，我发现他们编写代码有一些共同的习惯。
（一）为人编程，而非为电脑编程
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
（笨蛋也能写让计算机理解的程序；而优秀的程序员写的是人能理解的程序。）
Martin Fowler
编程不只是为电脑，更是为了人。
编程是为了团队的工程师，阅读、维护你的代码，并在此基础上创造的那群人。
编程是为了用户，不论是一个玩手机的小孩、一个调用你 API 的开发者，还是你自己。
我认识的最优秀的工程师都具有产品思维：优先考虑为人解决问题。
他们总是会评估代码对所有用户的价值。哪怕漏掉了一个受众，代码也不会投入生产。
（二）从代码本身解放出来
好的的工程师不拘泥于代码本身。
如果最终结果整体上会更好，他们会毫不犹豫地删除代码并重新开始，即使已经完成了 90%。
代码不是个人的，因此反馈意见也会被认真对待。
代码并不完美。没人在乎完美的代码，而应该在乎能带来改变的代码。
让自己学会不依赖于代码的最好方法就是认识到，20 年后，你的大部分代码很有可能会成为技术债务、被废弃或重写。
（三）采用统一的标准
在编写代码时，要坚持统一的标准和风格。一致性能让你和团队更容易阅读和理解代码、让代码库更容易扩展。这也是 Meta 和谷歌等公司发布大量代码时，代码库不会随着时间推移变得无法阅读和维护的原因。
我认识的每一位优秀的工程师都将团队的代码标准内化于心，并尽可能严格遵守，因为他们深知这样做的好处。
- 谷歌有一个易读的流程，来保持代码的简洁。
- 谷歌已经开源了一些代码风格。
- Meta 为其部分开源代码作了 C++ 风格规定。
花时间为团队规定一个代码风格，绝对值得。
（四）写简洁的代码
我认识的每一位优秀的工程师所编写的代码，编写过程可能很复杂，最终却很容易阅读和理解。
他们的代码非常美观，简洁、有条理、合乎逻辑；其中的每个决定都是合理的，有不合理之处也会很好地记录下来。
编写简洁代码的好方法是遵循一些原则，比如 SOLID 原则。这些原则最初是为 OOP（面向对象编程）设计的，但它们可以扩展到一般的编程中：
- S - 单一职责 Single-responsibility principle (SRP)：
一个类只负责一个功能。 - O - 开放封闭 Open–closed principle (OCP)：
软件对象（类、模块等）应对扩展开放，但对修改封闭，从而实现代码可预测、可维护。 - L - 里氏替换 Liskov substitution principle (LSP)：
子类必须可替换为其基类，而不影响程序的正确性。 - I - 接口隔离 Interface segregation principle (ISP)：
接口不应该强制接入冗余功能。因此，使用很多个客户端特定的接口，优于使用一个多用途接口。 - D - 依赖倒置 Dependency inversion principle (DIP)：
类都应该依赖接口和抽象类，而不是具体的类和函数。
命名就是一个例子。好的命名有助于清晰地区分：有描述性的函数名和易于理解的变量，且不含有奇怪的数值。
（五）不允许意外发生
代码不应产生意外。这可以通过遵循代码原则和编写适当的测试实现。
好的代码是可预测的。
测试能提高代码的清晰度和可预测性，提供信心。良好的自动测试允许团队修改代码，而不必担心潜在的破坏。
一些测试的例子：
- 针对单个组件和独立功能的单元测试
- 针对多个组件之间交互的集成测试
- 从用户角度评估整个系统功能的端到端测试
测试应该简洁，且在报错时易于追溯错因。
知道什么不能测试，也很重要。
例如，如果端到端测试的工作量超过了程序的实际效益，那么测试就应该被周到的文档记录、监控和向合适的人（如代码所有者）发出警报所取代。
测试不应过于拘泥细节。例如前端代码中的 CSS 选择器，或数据属性乃至截图等，显然就不必测试了。
（六）经常交流
任何伟大的系统都不是独自建成的。优秀的工程师都要经历设计评审、征求反馈意见，并不断迭代他们的初始设计代码。
每个人都有自己的知识空白，可以由其他人来填补。新的视角往往可以让代码更加清晰，或提供新的方法思路。
最优秀的工程师既善于沟通，又善于合作。他们不惜花时间合作，只为最终获得更好的结果。
合作可以简单到，呼叫同伴快速审核文档，或为重要的 PR 额外增加代码审核人员。
（七）写得快…也要写得慢
我认识的优秀工程师迅速完成的项目是…慢慢写出来的。
听起来很奇怪？
上述习惯都会增加第一遍编码的耗时，但它们能帮助工程师推进项目。花时间遵循标准和原则、正确测试、经常沟通，长远来看，反倒节省更多时间。
我个人做实习生和初级工程师时就有过这样的经历，相信很多人也有：匆忙前进三步，遇到阻碍，然后不得不后退五步。
最后 – 不要盲目遵循这些规则
以上的「规则」只是抛砖引玉。
并非所有事情都能整齐地纳入某套规则。有时，你在写的代码是个方形，无法融入那个圆形；这没关系。
这种时候，一定要记录以另一种方式编写代码的原因。否则，将来有人（比如未来的你）看到这些代码就会想：「真笨，这为什么不符合标准？」
然后，他们花上 20 小时重新编码，使之符合标准，却得出和以前一样的结论。耳熟吧？
软件开发的现实情况是，并非所有代码都能做到干净整洁或完全遵循规则。但代码可以是一致的、干净的、可理解的、可测试的和有价值的。
💡 更多资讯，请关注 Bytebase 公号：Bytebase
