【发布时间】：2010-09-14 20:05:13
【问题描述】：
编写可维护代码（与语言无关）最重要的因素是什么？
【问题讨论】：
标签： maintenance
【发布时间】：2010-09-14 20:05:13
【问题描述】：
写出来给别人看。这意味着好的名称、好的 cmets 和简单的语句的组合。
曾几何时，记忆稀缺，循环时间很慢。鼓励程序员编写复杂的单行代码来做很多事情。今天的内存很丰富，循环时间很快。您应该编写 5 行人们可以遵循的简单代码，而不是他们无法理解的一行。
好的 cmets 不一定要很长，但一定要有帮助。
也要保持一致。不要更改代码中的样式。例如，不要将命名样式从一个部分更改为下一个部分。
【讨论】：
-
这个问题要求一件事。你给了3。：P
-
我一直都是个过分的人。
-
好点，但这不仅仅是为了“其他人阅读”而写作。尝试在一年或更长时间后理解您自己的代码。我猜一年后你就是这些“其他人”中的一员。
-
其实和我的记忆力一样糟糕，一两个月后它看起来就像别人的代码。
-
这个问题要求一件事，没错。因此，在我看来，这个问题的措辞很糟糕。没有一件事。如果我问“我应该做什么才能不让生意失败”，唯一明智的答案是“避免所有各种陷阱，例如......”。
关注点分离（每个方法只做一件事）——这会停止 Spaghetti 代码。
编辑：（回应 Ash 的评论） 可维护性的关键是能够快速弄清楚代码在做什么以及如何进行更改以完成任务。
将代码分开，以便每个任务都由专用于它的方法处理，这很容易。
例如，如果我想在机器人的软件上更改肘部弯曲的方式，使用名为 BendElbow 的方法可以轻松进行更改。
【讨论】：
-
当然，虽然我发现让刚接触您的代码的人快速了解“做什么和在哪里”会更好。当您需要进行更改时，正交性也使更改变得不那么棘手。
-
true - 可维护性就是为了获得特定结果而需要更改的内容。关注点分离使这更容易弄清楚。
-
我喜欢表达关注点分离的一种方式是“拥有许多方法和许多类总是更好，而不是一个类中有一个大方法。”
自动化单元测试。
如果您已经使用自动化测试来告诉您何时会破坏现有功能，那么您可以通过重构慢慢改变代码的设计。自动化测试降低了更改代码的风险。
【讨论】：
-
我非常支持测试，一直以来——早在单元测试时尚流行之前很久，但它与好的设计完全无关——只是因为你的代码是 100%单元测试，并不意味着它可以维护。也就是说，单元测试应该是强制性的。
-
可维护性是指尽可能轻松地进行更改。与系统中所有其他类耦合的类很难测试。通过放松对其他类的依赖关系来简化测试。易于测试的设计是好的设计。它们是相关的。
-
绝对。注释非常重要，但自动化测试更好。测试就像拿着棒球棒的 cmets。
-
Michael Feather 对遗留代码的定义是未经测试的代码。
良好的抽象
【讨论】：
-
那里有很多糟糕的、漏洞百出的抽象。也许应该远离抽象？
-
再一次，糟糕的、有漏洞的抽象和好的抽象是两个不同的东西:)
单元测试毫无疑问。如果您从一开始就对代码进行单元测试，那么您将拥有一个测试套件，您可以在进行更改时运行该套件来验证代码的有效性。
此外，当您使用单元测试编写代码时，方法往往会更小，因为它们更容易测试。同样，它应该鼓励您将您的方法用于单个任务 - 再次因为这样更容易测试。
【讨论】：
良好的前期设计。没有什么能挽救糟糕的设计。
【讨论】：
在发布后的一两年内为您刚刚编写的软件提供一级或二级支持。
相信我，我自己也去过那里。我可能不得不在几年内维护或增强自己的代码的“恐惧”始终是提高可维护性的巨大动力。
【讨论】：
好的方法名
【讨论】：
编写代码时倾向于认为计算机是您的受众。
严格来说，这是真的，因为代码确实必须工作。但是，如果您在编写时考虑到您的人类受众，那么这种心态有助于生成更具可读性的代码。
如果您担心这会产生缓慢的代码，请记住，大多数程序几乎所有时间都在非常小的代码部分中。开始编写可读性，然后使用分析器确定要优化的正确部分。
【讨论】：
不要这样做 any of this stuff! 不过感谢 Roedy Green 的笑声。
【讨论】：
没有“单一最重要的因素”，它是多个因素的组合，如上所述。
现在，这些规则中的大部分可以浓缩为：“编写代码以供以后阅读”。
或者套用一个有趣但很好的建议：“编写你的代码，就好像它必须由一个知道你住在哪里的杀人狂人维护一样。”...
【讨论】：
Read Code Complete - 它涵盖了从变量命名到真正重要的内容的所有内容，它是所有必要的。没有一件事。
我的方法目前归结为使用信息变量名和最小变量范围编写代码来完成需要完成的工作（不是代码可能需要完成的每一项未来工作），并尝试确保我的代码需要尽可能少的补充文件。有时这会使我的变量和方法名称比以前更冗长（我的调试输出在使用时非常全面），但它们更容易理解。
可维护性通常也是其他方面扎实实践的结果 - 如果您以良好的 DRY 方式编写代码，那么问题更容易发现，如果您有一组强大的测试，那么您可以查看是否维护变化会破坏任何东西。
归根结底，这是一个尝试深思熟虑并为未来编写的问题-代码只编写一次，之后就是所有维护......
【讨论】：
持续重构
【讨论】：
我认为没有一个因素是您可以关注的。如果有，我认为它必须是良好的判断力。如果开发人员在设计阶段使用了错误的判断，即使是有据可查、易于阅读的代码也可能难以维护。无论文档和单元测试有多好，生产应用程序的糟糕设计几乎是不可能修复的。
您还可以查看“不可维护代码指南”之类的内容，了解不该做什么。内容丰富有趣！
http://mindprod.com/jgloss/unmain.html
我实际上曾在那些对其中提到的一些事情“标准化”的公司工作过。你会认为大部分内容只是常识，但你可能会感到惊讶。
【讨论】：
我想说最重要的因素是干燥。 glenatron 已经在他的回答中提到了其他因素，但我认为这是最重要的因素。
【讨论】：
编程就是性能；你永远不应该忘记你的听众是谁。 “就像最终维护您的代码的人是一个知道您住在哪里的暴力精神病患者一样编写代码。”
【讨论】：
在做出假设时记录它们 - 两天后，您会认为这些假设是理所当然的，但下一个维护您的代码的人不一定会做出相同的假设，并且会想知道您为什么要这样做做了...
人的代码 - 计算机会做任何你告诉它的事情；代码以便人类可以理解您的代码 - 谁知道它可能是 6 个月后的您！
【讨论】：
好方法。
【讨论】：
一致性。
【讨论】：
在我看来，编写可维护代码的基本规则是您的代码应该非常容易理解。这并不像听起来那么容易，您必须使用这里提到的所有其他技术来做到这一点。它需要一定程度的同理心，因为您必须了解其他开发人员如何看待您的代码，以及它与您看待它的方式有何不同。掌握这一点的一个好方法是回头看看你几年前写的一些代码。
现在，我想从理论上讲，可以编写出非常容易理解并准确执行其预期任务但也很难以任何方式修改的代码。不过，我从未见过这样的代码。
【讨论】：
大量的空白。 - 高密度代码难以理解。如果你有超过 6 行而没有空行，那么该组可能不是一个有凝聚力的思想/想法/操作。
良好的变量名称 - 解释性，但简洁。巨大的变量名和小的变量名一样糟糕。
【讨论】：
毫无疑问，编写旨在供其他人阅读的代码。这包括避免打高尔夫球、神秘语法和有意义的变量名称。如果代码足够干净，您可以完全避免编写任何 cmets，IMO。 \
[选择一种内置 OO 的语言，而不是附加其他语言也有帮助]
【讨论】：
已经很久了，但我有一个答案：不要过度评论。这听起来可能很愚蠢，但是太多解释简单的事情的 cmets 可能会使代码变得混乱，因为所有人都会得到出去。好的 cmets 可以创造奇迹，但毫无意义的则相反。
【讨论】：
对我来说编写可测试代码（查看 Google 测试博客）是更好的可维护代码
【讨论】：
我已经对 Matt 的回答“Good Abstraction”投了赞成票，但我想补充一点。
记录一切都是为了解释事情。我完全赞成 Doxygen 和其他自动文档工具，但 API 中的粗略函数列表总比没有好。
如果您想让您的代码可维护，请将您的解决方案描述为适当的抽象级别，并将该级别细化到代码，以便它的功能一目了然。
【讨论】：
小型、定义明确的函数和类。
很容易习惯其他人的各种编码约定，但如果一切都在一个巨大的类或函数中，我的脑袋就会爆炸。
【讨论】：
当人们随着代码的增长而修剪和塑造代码时，我更喜欢它。很多时候，你会发现一个原始的体面建筑的脊椎，上面挂着一个巨大的杂乱无章的烂摊子。
【讨论】：
寻找一个好的导师。这个人不一定是比你更好的编码人员，但是他们应该能够建议其他正确编写代码的策略。一个好的导师会建议许多以前对该主题给出的答案。它们可以成为第二双眼睛，让您知道自己的缺点在哪里，同时保持鼓励、乐观的语气。他们也会像你一样灵活并不断磨练他们的技能。这样，当下一个大范式出现时，您将能够更好地将谷壳与小麦分开。当面向对象编程和源代码控制被下一件大事取代时，这将是无价的（我很难想象我知道。）
【讨论】：
好的 cmets 可以使最糟糕的意大利面条代码更容易维护 10 倍。
【讨论】：
-
最糟糕的意大利面条代码是不可维护的。
好方法。好的 cmets 通过说明代码的预期目的来帮助抽象，坏的 cmets 只是重申代码在做什么。注释实际上可以以精心设计和命名的单元测试的形式出现。
【讨论】：