编写可维护代码(与语言无关)的最重要因素是什么？

解决方案

好评论。

文档。

好的抽象

关注点分离(每种方法都做一件事)将停止Spaghetti代码。

编辑：(回应阿什的评论)
维护性的关键是能够快速弄清楚代码在做什么以及如何进行更改以完成任务。

将代码分开，以便每个任务都可以通过专用的方法来处理，这很容易。

例如，如果我想更改弯头在机器人软件上的弯曲方式，那么使用一种名为BendElbow的方法就可以使更改变得不费吹灰之力。

好的方法名称

持续重构

自动化的单元测试。

如果我们已经通过自动测试覆盖了代码的设计，可以告诉我们何时破坏了现有功能，则可以通过重构来缓慢地更改代码的设计。自动化测试使更改代码的风险降低。

良好的前期设计。没有什么可以保存糟糕的设计。

好的注释甚至可以使最糟糕的意大利面条代码更容易维护10倍。

不要做任何这些事！不过要感谢Roedy Green的笑声。

单元测试不费吹灰之力。如果我们从一开始就对代码进行单元测试，那么我们将拥有一个测试套件，只要我们进行更改，便可以运行该套件以验证代码的有效性。

同样，当我们使用单元测试编写代码时，由于方法更易于测试，因此方法往往更小。同样，它应该鼓励我们将方法再次用于单个任务，因为这样比较容易测试。

写给其他人阅读。这意味着好名字，好评论和简单的陈述的结合。

曾几何时，记忆力不足，周期时间很慢。鼓励程序员编写能完成很多事情的复杂的单行代码。如今，内存充足，周期时间很快。我们应该编写5行人们可以遵循的简单代码，而不是他们无法理解的一行代码。

好的评论不必太长，但必须有所帮助。

也要保持一致。不要在代码中更改样式。例如，不要将命名样式从一个部分更改为另一部分。

好评论。好的注释通过说明代码的预期用途来帮助抽象，而坏的注释只是重述了代码在做什么。注释实际上可以以精心设计和命名的单元测试的形式出现。

一致性。

我认为没有一个可以关注的因素。如果有，我认为这将是一个很好的判断。如果开发人员在设计阶段使用了错误的判断，那么即使是文档齐全，易于阅读的代码也可能难以维护。无论文档和单元测试多么出色，生产应用程序的不良设计几乎都不可能修复。

我们也可以查看"不可维护代码指南"之类的内容，以了解不应该执行的操作。内容丰富而有趣！

http://mindprod.com/jgloss/unmain.html

我实际上曾在对其中提到的某些事情进行"标准化"的公司工作。我们可能会认为其中大部分只是常识，但我们可能会感到惊讶。

在发布后的一两年内，对我们刚编写的软件处于第一级或者第二级支持。

相信我，我自己去过那里。几年后，我可能不得不维护或者增强自己的代码的"恐惧"始终是提高可维护性的巨大动力。

如我所见，编写可维护代码的基本规则是代码应易于理解。这听起来并不容易，我们必须使用这里提到的所有其他技术来做到这一点。它需要一定程度的同理心，因为我们必须了解其他开发人员如何看待代码，以及代码与我们看到代码的方式有何不同。了解这一点的一种好方法是回头看一下几年前编写的一些代码。

现在，我认为从理论上讲，有可能编写非常容易理解的代码，并准确地执行其预期的任务，但也很难以任何方式修改。不过，我从未见过这样的代码。

有好的文档。这包括自我记录的代码(分隔的，描述性的名称和清晰的代码)，良好的注释，准确的(最新的)最终版本的详细设计文档以及源代码控制中的描述性更改说明。

如果要求两个，第二个肯定是单元测试。两者之间很难选择。

对我来说，编写可测试的代码(结帐Google测试博客)是更好的可维护代码

如上所述，没有"单个最重要的因素"，它是多个因素的组合。

现在，这些规则中的大多数都可以简化为："编写代码以供日后阅读"。
或者说一个有趣但很好的建议："编写代码，好像必须由一个知道自己的住所的杀人狂维护它。"

一致的编码风格。诸如方法和变量命名约定，注释的样式和格式，甚至模块/文件命名之类的东西。

我已经投票赞成Matt的回答" Good Abstraction"，但是我想添加一些内容。

记录一切都是为了解释事情。我都支持Doxygen和其他自动文档工具，但API中的函数简表总比没有好。

如果要使代码可维护，请描述解决方案以达到适当的抽象级别，并将该级别优化为代码，以便可以清楚地看到其作用。

我会和其他一些人一起走，抽象。当我们了解一些软件模式时，它也会有所帮助，GOF是开始使用此类工具的好地方。

大量空白。高密度代码很难理解。如果空白行多于6行，则该组可能不是一个有凝聚力的思想/想法/操作。

好的变量名可以解释，但简洁。巨大的变量名与微小的变量名一样糟糕。

Read Code Completeit涵盖了有关此内容的所有内容，从变量命名一直到非常重要的东西，这都是必要的。没有一件事。

我的方法目前归结为编写代码以使用信息性的变量名和最小的变量范围来完成需要完成的工作(而不是对将来的代码可能需要做的每一项工作)，并试图确保我的代码只需要很少的时间尽可能的补充文件。有时，这会使我的变量和方法名比以前更冗长(当我使用它时，我的调试输出非常全面)，但是它们更容易理解。

如果我们以一种不错的DRY方式编写代码，那么可维护性通常也是其他方面扎实实践的结果，那么问题就更容易发现，如果我们有一组强大的测试，那么我们可以看到维护变更是否会打破任何东西。

归根结底，这是一个努力思考的问题，为futurecode编写的代码只编写了一次，在此之后所有的维护工作...

小型且定义明确的函数和类。

习惯于其他人的各种编码约定很容易，但是如果一切都在一个巨大的类或者函数中，那么我的头脑会爆炸。

我想说最重要的因素是干。 glenatron在其他因素中已经提到了他的答案，但是我认为那是最重要的。

毫无疑问，编写旨在供其他人阅读的代码。这包括避免打高尔夫球，神秘的语法和周到的变量名。如果代码足够干净，IMO可以完全避免编写任何注释。 \

[使用内置的OO而不是固定的语言来选择语言也有帮助]

我想编写可维护的代码超出了代码范围。我认为最好了解需求是什么(并以某种方式对功能和非功能进行记录)，然后像新员工一样介绍如何将其转化为代码。

如果有人知道为什么代码原来是那样，那么使它变得更好和/或者扩展它会变得更加容易。

对于更多技术性的事情(例如算法)，先对其进行抽象解释(目标，原理)，然后注释代码和/或者模式实现的关键部分。

我还要做的一件事是在应用程序内部创建微型实验室，工具箱和代码模板，以便人们知道做一件事或者扩展另一件事所必需的"标准"代码是什么(导致进行一些复制/粘贴，但有助于生成代码)。更多和更好)。

倾向于以认为计算机是听众来编写代码的趋势。

严格来说，这是正确的，因为代码必须有效。但是，如果我们在编写时考虑到了人类的听众，那么这种思维方式将有助于产生更具可读性的代码。

如果我们担心这样做会产生慢速的代码，请记住，大多数程序几乎全部时间都在很小的一部分代码中。开始编写以提高可读性，然后使用事件探查器确定最合适的部分。

当人们修剪并随着代码的增长调整代码时，我更喜欢它。很多时候，我们会发现原始的脊柱式体面建筑，悬挂着巨大的笨拙烂摊子。

寻找一个好的导师。这个人不一定是比我们更好的编码器，但是他们应该能够提出其他策略来正确编写代码。一个好的指导者将是建议以前对该主题给出的许多答案。他们可以成为第二只眼睛，让我们知道短处在哪里，同时保持令人鼓舞的乐观态度。他们也将很灵活，并且会像我们一样不断磨练自己的技能。这样，当下一个大范式出现时，我们将能够更好地将谷壳与小麦分离。当面向对象的编程和源代码管理被下一件大事取代时(这很难想象，我知道)，这将是无价的。

编程就是性能；我们永远不会忘记听众是谁。 "代码似乎最终将维护代码的人是一个暴力的精神病患者，知道住所。"

一贯适用的强而明智的约定。诸如约定从何处开始索引，将事物留在何处的结束状态之类的事物。

这使我们更容易理解代码，因为所有代码都将以更简单的方式运行。

这至少是我的主要技巧之一。

• 在进行假设时记录假设-两天后，我们将把这些假设视为理所当然，但是维护代码的下一个人不一定会做出相同的假设，并且会想知道我们为什么做我们所做的事情...
• 为人编写代码-计算机将执行我们所说的一切；代码，以便人们可以理解代码-谁知道可能是从现在起6个月内！