在我们的通讯中，我们主要关注系统设计。这次，我们转向一个同样重要的话题：代码本身。你是否遇到过设计看起来很棒但代码却是噩梦的系统？这是我们本期关注的重点。我们将分解什么使代码好与坏。这都是关于将那些伟大的设计转化为同样伟大的代码。让我们深入真正重要的细节。

那么，为什么我们应该关心好代码？把它想象成你软件的基础。好代码不仅仅是让事情工作；它是关于让它们高效和可持续地工作。这是顺畅、高效的开发体验和令人沮丧、耗时体验之间的区别。

好代码保持稳定性和可预测性，即使你的项目复杂性增长。它就像有一个可靠的工具，无论工作多么艰难都能持续执行。当涉及到扩展时，好代码至关重要。它允许扩展而不会出现更短视方法带来的瓶颈和头痛。

当然，精心制作好代码需要更多的思考和努力。但这项投资通过长期节省成本得到回报。坏代码是一个定时炸弹——难以更新，可能导致昂贵的重写。

还有团队合作和连续性方面。高质量的代码（通常有良好文档并遵守标准）使团队更容易协作。它简化了入职流程、加速交付并促进团队扩展。

让我们通过比较假设的旋钮转动机制的两种设计来说明我们的观点。“好代码”使用皮带机制——灵活且易于调整。“坏代码”版本依赖刚性杆——更有限且当需要更改时容易出现并发症。

随着需求变化且旋钮需要重新定位，“好代码”的皮带机制通过简单扩展轻松适应这种变化。“坏代码”的刚性杆需要全新配置，既不及时也不具成本效益。

在另一个不可避免的修订中，我们需要改变旋钮转动的速度。“好代码”可以简单切换到不同尺寸的齿轮。“坏代码”设置变得越来越复杂，因为它需要额外部件并使系统更复杂且易损坏。

我们不是主张从一开始就过度工程化，特别是在资源有限且未来不确定的创业环境中。关键是理解我们编码选择的长期影响。过早构建过于复杂的系统可能与反复选择快速修复一样适得其反。艺术在于取得正确平衡，这是一种来自经验和深思熟虑考虑的品味和技能。

为了开始，我们选择了五个广泛的领域进行讨论。它们绝不详尽，但它们是开启关于什么使代码从坏到好的更广泛对话的良好起点。你准备好深入了吗？

命名规范

编码标准通常从类、函数、变量等的命名约定开始。这看起来很简单，但需要深思熟虑的设计。

考虑以下服务类名：

OrderManagementService
PaymentManagementService
DatabaseManagementService

通过给所有内容添加”ManagementService”后缀，名称变得不必要地长且重复。

接下来看这个函数：

boolean processPayment(PaymentInstruction paymentInstruction) {
    Channel preferredChannel = paymentInstruction.getChannel();
    channelFactory.getChannel(preferredChannel).send(paymentInstruction);
}

尽管遵循命名约定，“processPayment”并没有传达到底发生了什么。“process”这个词太通用了。它没有告诉我们支付的当前状态以及我们要对它做什么。

我们从阅读代码中理解它将支付指令发送到外部渠道进行处理。我们可以将其命名为”sendPaymentToExternalChannel()“，但这暴露了太多细节。“startPayment()“可能是一个好的选择，因为它表示启动支付流程而不暴露内部细节。

像这样的好名字减少了协作时对过多注释的需求！

让我们看另一个例子。

String userId = paymentInstruction.getUserId();

如果”userId”重命名为更领域相关的名称会更好，如”payerId”。

String payerId = paymentInstruction.getPayerId();

所以总之，有效的名称应该：

  • 简洁准确地描述目的
  • 使用业务领域术语
  • 避免暴露实现细节

代码复用

有时紧急业务需求出现，但修改现有代码风险太大，因为它封装得很差且测试很少。在这种情况下，将部分代码复制到新组件中作为捷径，然后开始修改以满足新需求是很诱人的。

我们在构建以合规为中心的 Know Your Client（KYC）服务时面临这种情况。它需要用户管理功能，这些功能已存在于紧密耦合的 UserService 模块中并在其他地方使用。由于没有时间模块化 UserService，我们将相关部分复制到新的 KYC 服务中并自定义它。

所以两个重复版本的用户服务逻辑长期存在。每当我们需要更新用户相关功能时，我们必须记得修改两个地方——原始 UserService 和现在 KYC 服务中的复制代码。开发者经常忘记这一点，导致不一致的行为和中断。保持相同逻辑的重复副本同步被证明是容易出错的。

本文为学习目的的个人翻译，译文仅供参考。

原文链接：Good Code vs. Bad Code。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。