1% 顶尖工程师的 7 个简单习惯

我曾与杰出的工程师一起工作过，他们既有在 FAANG 这样的大公司，也有像初创公司这样的小公司。他们让我看到了神话般的“10x”工程师——他们确实存在于现实生活中！

其中一些工程师后来创办了自己的公司，领导了改变我们所知的网络的开发，或者已经成长为当今大型科技公司领导价值数十亿美元的项目。

在与他们一起工作的整个过程中，我注意到他们在编写的代码中都有一些重叠的习惯。

代码是为人类而不是计算机编写的

“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员会编写人类可以理解的代码。” ——马丁·福勒。

代码是为人类服务的，而不仅仅是为计算机服务的。

代码是为您团队中的工程师编写的，他们阅读、维护并在您的代码之上进行构建。

代码是为用户服务的，无论是使用手机的孩子、调用 API 的开发人员还是您自己。

代码有三种受众：人类读者、机器读者和用户

我认识的最好的工程师都具有产品意识：首先考虑为人类解决问题。

我认识的最好的工程师总是评估他们的代码对所有受众的价值。

如果他们没有抓住其中一位观众的注意力，那么该代码就不会投入生产。

与代码本身分离

出色的工程师不会依赖于代码本身。

他们不怕删除代码并重新开始，即使他们已经完成了 90%，如果这意味着最终结果总体上会更好。

代码不是个人的，因此我们会从容地接受反馈。

代码并不完美。没有人关心完美的代码。他们关心带来改变的代码。

教会自己脱离代码的最好方法是认识到，20 年后，你的大部分代码很可能会成为技术债务、被弃用或被重写。

使用一致的标准

编写代码时，坚持一致的标准和编码风格。一致性使未来的您和您的队友更容易阅读和理解代码。

一致的风格指南可以让团队和代码库更轻松地扩展。这就是 Meta 和 Google 等公司快速交付如此多代码的方式，而代码库不会随着时间的推移变得不可读和不可维护。

我认识的每一位表现出色的人都内化了团队的代码标准，并尽可能严格地遵循它，知道它的好处。

编写简单的代码

我认识的每一位精英工程师所编写的代码可能制作起来很复杂，但最终却很容易阅读和理解。我对此最好的评价是他们的代码.

他们的代码干净、有组织且合乎逻辑。在他们的代码中做出的每个决定都是有意义的，当某些事情不有意义时，它会在代码中得到很好的记录。

编写干净代码的一个好方法是遵循原则，例如 SOLID 原则。尽管它们最初是根据 OOP（面向对象编程）设计的，但它们可以扩展到一般编程：

• 单一职责Single Responsibility：一个类应该只有一个职责。

• 开放-封闭Open-Closed：软件对象（类、模块等）应该对扩展开放，但对修改封闭，从而允许可预测、可维护的代码。

• 里氏替换Liskov Substitution：子类型必须可以替换其基本类型，而不影响程序的正确性。

• 接口隔离Interface Segregation：代码不应该依赖于它们不使用全部接口的巨大接口。相反，包应该包含并允许导入更小的特定接口。

• 依赖倒置Dependency Inversion：高层模块不应该依赖于低层模块；两者都应该依赖于抽象，从而促进更加灵活和解耦的系统设计。

命名就是一个例子。好的命名没有神奇的值、明确的区别、描述性的函数名称和易于理解的变量。

不允许出现意外

代码不应该产生意外。这是通过遵循代码原则并编写适当的测试来完成的。

好的代码是可预测的。

测试强制代码的清晰度和可预测性。他们提供信心。良好的自动化测试允许团队对代码进行更改，而不必担心破坏看不见的东西。

好的代码是可预测的。

某些类型的测试包括：

• 单个组件和隔离功能的单元测试。

• 多个组件之间交互的集成测试。

• 从用户角度评估整个系统功能的端到端测试。

测试应该很简单。当阅读失败的测试时，应该很容易识别出了什么问题。

了解不应该测试什么也很重要。

例如，如果端到端测试的工作量超过了程序的实际收益，则该测试将被周到的文档、监视和向合适的人员（例如代码所有者）发出的警报所取代。

测试也不应该测试代码中的实现细节，例如测试前端代码中的某些 CSS 选择器与使用数据属性或仅进行屏幕截图测试。

经常沟通

没有伟大的系统是单独建立的。伟大的工程师会进行设计审查，征求反馈，并继续迭代其代码的初始设计。

每个人都有自己的知识空白，可以由其他人来填补。新的视角通常可以帮助代码变得更加清晰，或者提供一种以前可能没有想到的新方法。

最好的工程师既善于沟通又善于协作——不怕花时间一起工作以获得更好的最终结果。

这可以很简单，例如向队友发送命令以快速查看文档或向重要的拉取请求添加额外的代码审阅者。

编码快……但慢

我认识的最好的工程师通过缓慢编码来快速完成项目。

听起来很奇怪，对吧？

上述所有这些原则和习惯都为整体，第一次编码增加了更多时间。但它们允许工程师一步一步地推进项目的进展。

通过花时间使用标准、正确测试、使用原则并经常沟通，从长远来看，他们可以节省更多时间。

当我还是一名实习生和初级工程师时，我个人经历过另一种选择，我相信许多其他人也有过这种经历，那就是向前冲 3 步，撞到阻挡者，然后不得不后退 5 步。

快走要慢走。走得慢才能走得远。

不要盲目遵守规则

上述“规则”和“原则”只是指导方针。

并非所有事情都能整齐划一地符合指导方针。

有时，您编写的代码是一个正方形，但无法放入该圆中，没关系。

在这种情况下，请确保记录下为什么以某种方式编写代码。

如果你不这样做，那么有人，比如未来的你，可能会在将来查看代码并想：“哇，我当时很蠢。为什么这不符合我们的标准？”。

然后，他们将花费 20 小时重新编码以符合标准，只是为了得出与以前相同的结论。听起来有点熟？

软件开发的现实是，并非所有代码都能干净或完美遵循规则。然而，它可以是一致的、干净的、可理解的、可测试的和有价值的。

我注意到这些工程师的其他模式，我将在将来写到：

• 至少在一个领域有深厚的领域知识。我记下的每一位工程师如今都处于各自领域的顶尖地位，因为他们专注并成为某个领域的专家，无论是前端基础设施、分布式系统还是干净的 UI。

• 经常且适当地推销自己。这些工程师根本没有隐藏在众目睽睽之下。团队中的每个人以及与他们一起工作的每个人都知道他们的价值和专业知识。这是通过适当的自我营销和高影响力项目的结合实现的。

---

随手关注或者”在看“，诚挚感谢！