大家好，这里是大家的林语冰。今天分享的是 Vue 官方周报推荐的一篇延伸阅读。
免责声明
本文属于是语冰的直男翻译了属于是，仅供粉丝参考，英文原味版请临幸 7 simple habits of the top 1% of engineers。
我曾与现象级的工程师一起工作过，祂们有的在大型公司（比如 FAANG），有的在小型公司（比如 startups）。
其中某些工程师后来创办了自己的公司，引领开发，改变了如你所知的网络（如 Vercel！），或者已经成长为当今大型科技公司领导价值数十亿美元的项目。
在与祂们共事的过程中，我注意到祂们编写的代码都有某些雷同的习惯。
为人撸码，而非计算机
"任何傻瓜都能写出计算机可以理解的代码。优秀的程序员则会编写人类可以理解的代码。"
------ 马丁·福勒
代码为人类服务，而不仅仅是为计算机服务。
代码是为您团队中的工程师编写的，祂们阅读、维护并在您的代码之上进行构建。
代码为用户服务，无论是使用手机的孩子、调用 API 的开发者抑或是您自己。
我认识的最佳工程师都具有产品意识（product-minded）：首先考虑为人类解决问题。
我认识的最佳工程师总是评估祂们的代码对所有受众的价值。
如果祂们没有抓住其中一位受众的注意力，那么该代码就不会投入生产。
与代码本身分离
牛逼的工程师不会依赖代码本身。
即使祂们已经完成了 90% 的进度条，但如果卷土重来意味着最终结果总体上会更好，祂们也不怕删除代码然后卷土重来。
代码不是个人的，因此我们会从容地接受反馈。
代码并不完美。没有人关心完美的代码。祂们关心带来改变的代码。
教会自己脱离代码的最好方法是认识到，20 年后， 您的大部分代码大概率会成为技术负债、被弃用或被重写。
使用一致的标准
撸代码时，请坚持一致的标准和编码风格。一致性使未来的您和您的队友更容易阅读和理解代码。
一致的风格指南可以让团队和代码库更轻松地扩展。这就是 Meta 和谷歌等公司快速交付一大坨代码，而代码库不会随着时间的推移变得不可读和不可维护的方式。
我认识的每位精英人士都内化了团队的代码标准，并尽量循规蹈矩，知晓其好处。
- 谷歌有维护整洁代码的可读性流程
- 谷歌开源了若干风格指南
- Meta 为其某些开源代码定制了 C++ 风格指南
- 粉丝福利：如果您的团队还莫得哪怕一个格式化 linter，这绝对值得花时间进行设置。
编写简单的代码
我认识的每位精英工程师所编写的代码可能生产很复杂，但最终 都易于阅读和理解。对此我能想到的最好评价是祂们的代码优雅得不谈。
祂们的代码整洁、有组织且符合逻辑。祂们代码中的每个决定都有意义，当某事无意义时，祂会被注释在代码中。
编写整洁代码的一个好方法是遵循原则，比如 SOLID 原则。尽管该原则最初是根据 OOP（面向对象编程）设计的，但也可以推广到一般编程：
- 单一职责原则：一个类应该只有一个职责。
- 开闭原则：软件对象（类、模块等）应该对扩展开放，但对修改封闭，允许可预测、可维护的代码。
- 里氏替换原则：子类型必须可以替换其基类型，而不影响程序的正确性。
- 接口隔离原则：代码不应该依赖祂们无需全盘接受的巨大接口。相反，软件包应该包含并允许导入更小的特定接口。
- 依赖倒置原则：高阶模块不应该依赖低阶模块；两者都应该依赖抽象，促进更灵活和解耦的系统设计。
命名就是一个例子。"信达雅"的命名没有歧义，而有显而易见的差异、顾名思义的函数名和不言而喻的变量。
不允许意外发生
代码不应该产生意外。这通过遵循代码原则并编写妥当的测试来做到。
优秀代码是可预测的。
测试规范代码的清晰度和可预测性。测试提供信心。良好的自动化测试允许团队更改代码，而不必担心破坏看不见的东东。
几类测试包括但不限于：
- 单个组件和隔离功能的单元测试。
- 多个组件之间交互的集成测试。
- 从用户视角评估整个系统功能的端到端测试
测试追求简单。当阅读失败的测试时，应该易于对症下药。
了解不该测试的东东也很重要。
举个栗子，如果端到端测试的工作量超过了程序的实际收益，那么该测试将被体贴的文档、监管和向合适的人员（比如代码所有者）发出的警报所取代。
测试也不应该测试代码中的实现细节，比如测试前端代码中的某些 CSS 选择器相对于 data-attributes 的使用，或者仅仅测试屏幕截图。
频繁沟通
独木不成林。伟大的工程师会审查设计，征求反馈，并持续迭代其代码的初始设计。
每个人都有自己的知识盲区，这可以由祂者来弥补。新视角通常可以帮助代码变得更清晰，或者提供一种见所未见的新方法。
最佳工程师既擅长沟通又善于合作 ------ 不怕花时间共事谋求更好的结果。
这并不复杂，比如向 pin 一下队友以速览文档或向重要的 PR（pull request）添加额外的代码审查员。
既快又慢地撸码
我认识的最佳工程师通过缓慢编码来快速完成项目。
这听起来有点奇葩，对吧？
上述所有原则和习惯都为首次整体编码增加了时间成本。但祂们允许工程师循序渐进地推动项目的进展。
长远来看，通过花时间使用标准、正确测试、使用原则和频繁沟通，祂们节省了更多时间。
当我还是一名实习生和初级工程师时，我个人经历过另一种选择，我相信很多人也有过这种经历，那就是猛冲 3 步，碰壁，然后不得不后退 5 步。
不要盲从规则
上述"规则"和"原则"只是指导方针。
并非所有事情都能整齐划一地符合指导方针。
有时，您的代码是一个无法放入圆中的正方形。那也问题不大。
在这种情况下，请确保记录您以某种方式撸码的原因。
如果您不这样做，那么某人（比如未来的你）将来可能会瞄一眼代码然后反思："哇，我当时太笨了。为什么这不符合我们的标准？"。
然后，祂们将花费 20 小时重构以符合标准，只是为了得出与以前相同的结论。这是不是似曾相识？
软件开发的现实是，并非所有代码都是整洁的或完美遵循规则。
虽然但是，祂可以是一致的、整洁的、浅显易懂的、可测试的和有价值的。
我注意到这些工程师的其他模式，我将来会写到：
- 至少在一个领域有深厚的领域知识。我记录的每一位工程师如今都处于各自领域的顶尖地位，因为祂们专注并成为某个领域的专家，无论是前端基建、分布式系统还是简洁 UI。
- 频繁且适当地推销祂们自己。这些工程师根本没有闭门造车。团队中的每个人以及与祂们共事的每个人都知道祂们的价值和专业知识。这是结合适当的自我营销和高影响力项目来实现的。
友情赞助
您现在收看的是直男翻译系列，学废了的小伙伴可以点赞友情赞助本系列，我们每天佛系投稿，欢迎关注和订阅最新动态。谢谢大家的彼芯，掰掰~