为下一个开发者编码的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的《代码整洁之道》和Max Kanat-Alexander的《代码简洁性》

结语

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