Clean Code: 10 Principles That Make You a Better Developer — cod-ai.com

我仍然记得我继承一个50,000行代码库的那一天，这让我质疑自己的职业选择。那是2015年，我在一家金融科技初创公司担任高级开发人员已经三年，我们的首席工程师刚刚离职，留下的没有任何文档。代码勉强能工作——但阅读它就像是在解读一个主动仇恨未来开发者的人的古老象形文字。这段经历教会了我比任何教科书都要多的关于干净代码的知识。

快进九年，我现在是一家管理每天处理超过200万笔交易的公司的首席工程师。我审查了成千上万的拉取请求，指导了几十名开发者，重构了比我愿意承认的更多的遗留代码。在这一切中，我提炼出了区分好代码与优秀代码的十条基本原则，这些原则不仅改变了我的工作，也改变了我所教导的每位开发者的工作。

干净的代码不是关于苛求或为了规则而遵循规则。它是关于尊重——尊重你未来的自己、你的团队成员，以及下一个在凌晨2点维护您工作的人，当生产系统出现故障时。让我分享我的所学。

肮脏代码的真实成本

在我们深入原则之前，让我们来谈谈这件事的重要性。在我目前的角色中，我们进行了一项内部研究，跟踪我们工程团队的开发者生产力。我们发现，开发者在阅读和理解现有代码上平均花费65%的时间，而仅有35%花费在实际编写新代码上。随着糟糕的编码，这一比例变得更糟——在我们的遗留系统中跳升到80/20。

这里是重点：我们计算出，不清晰的变量名称每个季度单独造成我们团队大约127小时的损失。仅仅识别x、temp或data2所代表的意义，就花费了超过三整周的工作时间。在40名工程师的团队中，这意味着由于简单的命名约定差错，每年成本高达六位数。

我见证过项目失败并不是因为技术上的不可能，而是因为代码库变得如此复杂，以至于即使是简单的更改需要数周而不是数小时。一位我咨询过的电子商务客户由于其结账系统脆弱，新增支付方式需要长达三个月的开发周期，导致每天损失约50,000美元的潜在收入。在经过六周的重构冲刺后，应用了干净代码原则，这一更改只花了四天。

商业案例显而易见：干净的代码直接影响你的盈利能力、团队士气以及创新能力。现在让我们探讨如何实现它。

原则1：有意义的名称是你第一条文档

我曾经与一位开发者合作，他坚持认为短变量名使代码输入更快。他会写一些像let u = getUserData()或const p = calculatePrice()的东西。当我三个月后要求他解释他的代码时，他无言以对。他已经忘记了自己的缩略语系统。

你的变量、函数和类名称应该讲述一个故事。它们应该在不需要注释的情况下显示意图。比较这两个例子：

差： const d = 86400;

好： const SECONDS_PER_DAY = 86400;

在你半夜调试时，试图理解一个计算出错的原因时，差异看似微不足道。第二个版本立即告诉你那个神秘数字代表什么。

以下是我与每位我指导的初级开发者分享的命名清单：

• 使用可发音的名称——如果你在代码审查中无法说出来，那它就太隐晦了
• 使用可搜索的名称——单字母变量几乎无法用Ctrl+F找到
• 避免心理映射——不要让读者翻译你的缩略语
• 每个概念选择一个词——不要将fetch、retrieve和get混合在一起用于同一个操作
• 使用解决方案域名称——其他程序员会阅读你的代码，因此AccountVisitor或JobQueue是有意义的

在实践中，我发现花费额外的30秒来思考一个名称，可以节省平均15分钟的混淆。这是30倍的投资回报。当你把这个计算到项目中的数百个变量时，时间的节省会变得非常可观。

我使用的一种技术是：如果我不能用一句简单的句子清晰地解释一个变量的作用，那么这个名称就不够好。你自己试试——如果你在命名时遇到困难，通常意味着那个事物本身做得太多，需要被拆分开来。

原则2：函数应该做一件事情，并且做到最好

单一职责原则不仅仅是学术理论，而是生存策略。我在调试一个名为processOrder的400行函数时，深刻地认识到了这一点。这个函数验证输入、计算税费、更新库存、发送电子邮件、记录分析并处理支付。要找到税费计算中的错误，意味着要穿越与之无关的电子邮件模板代码。