为下一个开发者编写代码的5个步骤

我们大多数人可能不会考虑维护我们代码的开发者。直到最近，我也没有考虑过他。我从未故意写过晦涩的代码，但我也从未留下任何线索。

Kent Beck 关于优秀程序员的观点：

任何傻瓜都能写出计算机能理解的代码。优秀的程序员写的代码是人能理解的。

Douglas Crockford 关于优秀计算机程序的观点：

一切都归结为沟通和你用来促进沟通的结构。人类语言和计算机语言在许多方面的工作方式差异很大，但最终我通过程序与阅读该程序的人进行沟通的能力来判断一个优秀的计算机程序。所以在这个层面上，它们并没有那么不同。

即使在编写最好的代码中，发现目的和意图也很困难。作者留下的任何线索、注释、详细的命名和一致性对下一个开发者都是非常有帮助的。

我首先寻找模式。模式可以在许多地方找到，包括变量名、类布局和项目结构。一旦确定，模式就能洞察前一个开发者的意图，并帮助理解代码。

什么是模式？模式是对重复出现的问题的可重复解决方案。考虑一扇门。当一个空间必须允许人们进出，同时又要保持隔离时，就会实现门的模式。这似乎很明显，但曾经并非如此。有人创建了门的模式，包括门把手、铰链和这些组件的位置。走进任何家庭，你都能识别出任何门及其组件。风格和颜色可能不同，但组件是相同的。软件也是如此。

对于常见的软件问题，存在已知的软件模式。1995年，《设计模式：可复用面向对象软件的基础》出版，描述了常见的软件模式。这本书描述了大多数软件应用中遇到的常见问题，并提供了优雅的解决方案。开发者在解决他们经常遇到的问题时也会创建自己的模式。虽然他们不会出版一本书，但如果你仔细观察，你可以识别它们。

有时很难识别模式。这使得理解代码变得困难。当你发现自己处于这种情况时，检查代码，看看它是如何被使用的。开始重写。问问自己，你将如何完成相同的结果。通常当你经历算法的思考过程时，你会获得对其他开发者实现的洞察。我们中许多人都有重写我们不理解的东西的倾向。抵制这种冲动！现有的实现是经过战斗考验的，而你的不是。

有些代码就是令人恼火，向同事寻求帮助——第二双眼睛总是有帮助的。一起走过代码。你会惊讶于你们两个会发现什么。

以下是为下一个开发者留下线索的5个建议

1. 模式
使用已知的模式，创建你自己的模式。在整个代码中坚持一致的范式。例如，不要有3种数据访问方法。

2. 一致性
这是迄今为止编码中最重要的方面。没有什么比发现不一致的代码更令人沮丧的了。一致性允许做出假设。每次遇到特定的软件模式时，应该假设它的行为与该模式的其他实例类似。

不一致的代码是一场噩梦，想象读一本书，其中每个单词的意思都不同，包括不同地方的同一个单词。你必须查找每个单词并花费大量的精力来发现意图。这很令人沮丧、乏味且痛苦。你会发疯的！不要对下一个开发者这样做。

3. 详细的命名
这是你的语言。这些是你故事的词汇。好好编织它们。

这包括类名、方法名、变量名、项目名和属性名。

不要这样做：

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

应该这样做：

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

第一个例子在if语句中硬编码了3。这段代码在语法上是正确的，但数字3的意图告诉你什么都没有。看着它被评估的属性，你可以推断它实际上是3小时。实际上我们不知道。我们在做一个假设。

在第二个例子中，我们将3设置为一个名为’feedInterval’的变量。意图在变量名中清楚地说明了。如果距离上次进食已经过了3小时，是时候喂猴子了。设置变量的一个副作用是我们现在可以改变喂食间隔而不改变逻辑。

这是一个人为的例子，在大型软件中这种类型的代码是自文档化的，将帮助下一个开发者理解代码。

4. 注释
注释是一把双刃剑。过多的注释会增加维护成本，过少则会让开发者不确定代码如何工作。一般的经验法则是当普通开发者不理解代码时进行注释。这发生在假设不明显或代码不寻常的时候。

5. 代码简洁
在我的专业意见中，编写复杂代码是开发者中最大的愚蠢。

Steve Jobs 关于简洁性的观点：

简洁可能比复杂更难：你必须努力工作来理清思路使其简洁。但最终是值得的，因为一旦你做到了，你就能移山倒海。

复杂性有许多形式，其中一些包括：未来防护、过度复杂的实现、过度抽象、大类和大方法。

有关编写干净简洁代码的更多信息，请参阅Uncle Bob的书《Clean Code》和Max Kanat-Alexander的《Code Simplicity》

总结

阅读代码很困难。通过几个简单的步骤，你可以确保下一个开发者能够理解你的代码。