工程师分享的7个编程习惯

我和很多杰出的软件工程师们一起工作过，他们有的来自FAANG之类的大公司，有的来自正处于创业阶段的小公司。

这些工程师中有人自主创业，也有人在大型科技公司领导了数十亿美元的项目。在我与他们一起工作的时间里，我注意到他们绝大部分人的一些共通的编程和工作习惯。我想，或许正是这些习惯让他们成为了行业金字塔中最顶尖的那1%。

成为一名工程师，而不是码农

工程是为了解决问题而诞生的。

最好的工程师将代码视为达到目的的手段。

虽然写代码是一种乐趣，但没有目的地写代码是没有意义的。代码应该用于为用户设计解决方案。

某种意义上，编程是一种创造性的追求。创造力在约束下茁壮成长。添加要解决的明确问题的“约束”，允许工程师以他们认为合适的方式自由地探索和创建解决方案。

我所知道的最好的工程师都是有产品意识的：首先考虑为人类解决问题。说到这里，就引出了下一点。

为人而不是为机器编写代码

“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。”

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

代码是为团队中的工程师准备的，他们会阅读、维护并在代码的基础上进行构建。

代码是为用户准备的，不管是用手机的孩子，还是调用API的开发者，或者是你自己。

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

如果他们没有打动某个受众，则该代码就不会投入生产。

与代码本身分离

优秀的工程师不依附于代码本身。

即使他们已经完成了90%，如果改变意味着最终的结果会更好，那么他们不害怕删除代码并重新开始。

代码不是个人的，所以反馈是从容的。

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

教会自己不依附于代码的最好方法是认识到，在20年内，你的大部分代码很有可能成为技术债务、被弃用或被重写。

使用一致的标准

编写代码时，请坚持一致的编码标准和风格。一致性使代码更容易被未来的你和你的团队成员阅读和理解。

一致的风格指南可以让团队和代码库更容易扩展。这就是为什么Meta和Google这样的公司能够快速发布如此多的代码，而不会随着时间的推移使代码库变得不可读和不可维护。

我认识的每一个优秀的人都内化了团队的代码标准，并尽可能严格地遵循它，洞悉它的好处。

写简单干净的代码

我认识的每一位精英工程师都编写了一些代码，这些代码编写起来可能很复杂，但最终阅读和理解起来都很简单。我能想到的最好的词就是他们的代码很美观。

他们的代码干净、有条理、合乎逻辑。在他们的代码中做出的每个决定都是有意义的，当有些事情没有意义时，它会在代码中被很好地记录下来。

编写干净代码的一个好方法是遵循原则，比如SOLID原则。虽然它们最初是用面向对象编程(OOP)设计的，但它们可以扩展到通用编程：

单一责任：一个类只能有一个责任。

open-closed：软件对象（类、模块等）应该开放扩展，但关闭修改，允许可预测、可维护的代码。

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

接口隔离：代码不应该依赖于没有使用全部接口的大型接口。相反，包应该包含并允许更小的、特定的接口被导入。

依赖反转：高级模块不应依赖于低级模块;两者都应依赖于抽象，从而促进更灵活和解耦的系统设计。

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

不要让意外发生

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

好的代码是可预测的。

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

一些类型的测试包括:

单个组件和独立功能的单元测试。

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

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

测试应该很简单。在阅读失败的测试时，应该很容易识别出哪里出了问题。

知道什么不应该测试也很重要。

例如，如果端到端测试的工作量超过了程序的实际收益，那么测试将被周全的文档、监视和向正确的人(例如代码所有者)发出警报所取代。

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

经常沟通

伟大的系统不是单独建立起来的。优秀的工程师会进行设计审查，征求反馈，并继续对他们的初始设计进行迭代。

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

最好的工程师既善于沟通又善于合作——为了更好的最终结果，他们不怕花时间一起工作。

这可以很简单，比如让团队成员快速检查文档，或者为重要的拉取请求添加额外的代码检查人员。

慢，即是快

我所知道的最好的工程师通过慢编码来快速完成项目。听起来很奇怪，对吧?

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

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

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

不要盲目循规蹈矩

以上的“规则”和“原则”只是指导方针。并不是所有的东西都能很好地符合指导方针。

有时候，你写的代码是一个正方形，不能放进那个圆圈里。没关系。

在这种情况下，请确保记录代码以某种方式编写的原因。

如果你不这样做，那么有人，比如未来的你，可能会在未来看到当时的代码时觉得“哇，我当时真笨。为什么不符合我们的标准呢?”

然后，他们会花20个小时重新编码，以符合标准，只是为了得到和以前相同的结论。听起来是不是很熟悉?

软件开发的现实是，并不是所有的代码都是干净的或完全遵循规则的。

但是，它可以是一致的、干净的、可理解的、可测试的和有价值的。

写在最后

此外，我还注意到：这些工程师的行为模式还包括：

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

经常适当地推销自己。这些工程师并没有藏匿于幕后。他们团队中的每个人以及与他们一起工作的每个人都知道他们的价值和专长。这是通过适当地营销自己和从事高影响力项目的结合而实现的。

编辑：黄飞