你未来的自己会喜欢的编码实践

编写代码时，一定要假设最终维护你代码的人是一个知道你住在哪里的暴力精神病患者。

• 马丁·戈尔丁

以下是我在过去 10 年中采用的 6 种编码实践，以确保未来的自己可以减少需要原谅的罪过。

1. 标准化代码格式

任何代码库的阅读量都远大于编写量。格式一致的代码对于团队中的每个人来说都易于阅读和理解。标准格式确保你的眼睛和潜意识能够无缝地查找变量、括号、函数等。Golang 通过gofmt在标准库中提供命令，在这方面做得非常出色。这结束了 Golang 社区代码审查中经常出现的所有关于格式的讨论。

2. 不要盲目遵循 DRY 原则 

DRY（不要重复自己）几乎是开发者的口头禅。但如果不加区分地应用，会导致代码抽象，难以阅读和理解。它还会阻碍代码各个部分充分发挥其潜力。切勿盲目遵循 DRY 原则。 

最好在代码库中至少复制粘贴两次相同的函数。只有当第三次看到相同的需求时，才应该重构代码并遵循DRY原则。这样做可以确保你不会过早地假设两个最初看起来相同的问题在一段时间后仍然会保持不变。当你第三次遇到类似的需求时，你就掌握了一些关于代码哪些部分是通用的数据。你还可以利用三个重复代码实例来创建良好的抽象。 

3. 通过日志调试代码 

练习在本地机器上通过日志而不是调试器来调试代码。在本地机器上调试可以确保日志添加到正确的位置。这反过来又能确保你能快速调试生产环境中的问题，因为你之前在本地机器上也经历过类似的过程。记住，不要太过冲动，到处添加不必要的日志。这会使你的生产环境中的日志文件变得杂乱无章。

太多的日志记录 == 没有日志记录。

4. 谨防过早优化

代码优化的主要目标是提升性能。性能问题往往并非如你所想的那样。在开始性能优化之前，务必先对代码进行基准测试。如果没有基准测试，你怎么知道所做的代码更改是否真的对效率产生了影响？过早进行优化，尤其是微优化，并非良策，因为你不知道自己是否正在努力消除性能瓶颈。

由此推论，这并不意味着你可以像在荒野中一样随意编程。不要因为你懒惰，没有想到最有效的解决问题方法，就让计算机去做它不需要做的工作。

5. 不要用不必要的功能使代码库复杂化

不要用用户未曾要求的功能来增加代码库的复杂性。这是产品生命周期早期需要避免的问题。初创团队往往认为，构建更多功能能帮助他们更快地找到产品与市场的契合点。这是一种反模式。添加不必要的功能会使代码更难阅读和调试。当新开发人员加入时，他们会发现很难区分重要的代码路径和那些一时兴起添加的代码路径。最终，这种技术债务会拖慢整个团队的开发速度。

6. 在开发生命周期早期设置 CI/CD 管道

即使只需一个人操作，CI/CD 流水线也能减少记住（并执行）特定代码库的构建和部署的开销。通常的假设是，CI/CD 流水线只对每天将大量代码投入生产的团队才重要。根据我的经验，CI/CD 流水线对于很少接触的代码库更为重要，因为您不会记得代码是如何以及在何处部署的。如果您每年只更新一次代码，这一点尤其重要。此外，拥有 CI/CD 流水线可以确保您拥有一个版本控制的脚本，准确地告诉您 X 个月前的想法。 

你还采取了哪些其他措施来防止未来的自己上吊自杀？😜

我通过我的新闻通讯 in.snippets() 分享我每周都会阅读的软件工程文章的 TL;DR 版本。如果您想每天学习相关知识，请在此注册。