编写可维护代码

Question

编写可维护代码（独立于语言）最重要的唯一因素是什么？

Answer 1

好评。

Answer 2

文档。

Answer 3

良好的抽象关注的

Answer 4

分离（每种方法做一件事情） - 这将停止意大利面条代码。

编辑:(回应Ash的评论） 可维护性的关键是能够快速找出代码正在做什么以及如何进行更改以完成任务。

将代码分离出来，以便每个任务都通过专用的方法进行处理，这使得它变得非常简单。例如，如果我想改变肘部弯曲机器人软件的方式，使用一种名为BendElbow的方法使得它可以在需要进行更改的情况下轻松完成。

Answer 5

好方法名

Answer 6

持续重构

Answer 7

自动化单元测试。

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

Answer 8

良好的前期设计。没有什么能够挽救糟糕的设计。

Answer 9

良好的评论可以使甚至最糟糕的面条代码10x更容易维护。

Answer 10

不要做any of this stuff!感谢Roedy Green的笑声。

Answer 11

单元测试手。如果你单元测试你的代码，那么你将拥有一个测试套件，当你做出改变时，你可以运行它来验证代码的有效性。另外，当你使用单元测试编写代码时，由于方法更容易测试，所以方法往往更小。同样，它应该鼓励你将你的方法变成一个单一的任务 - 同样因为测试更容易。

Answer 12

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

曾几何时，记忆稀少，循环时间缓慢。鼓励程序员编写复杂的单行代码，完成许多事情。今天的记忆丰富，循环时间快。你应该写5行简单的代码，人们可以遵循而不是一行他们无法理解的。

良好的评论不需要很长，但他们必须有帮助。

也是一致的。不要更改代码中的样式。例如，不要将命名样式从一个部分更改为下一个部分。

Answer 13

好评。好的评论通过说明代码的预期目的来帮助抽象，不好的评论只是重申代码的作用。评论实际上可以以精心设计和命名的单元测试的形式出现。

Answer 14

一致性。

Answer 15

我不觉得有什么，你可以专注于一个单一的因素。如果有我认为这将是一个很好的判断。如果开发人员在设计阶段使用了错误的判断，即使有据可查，易于阅读的代码也很难维护。无论文档和单元测试有多好，生产应用程序的糟糕设计几乎无法解决。

你也可以看看类似的指导作用难于维护代码的什么不该做的想法。内容丰富而有趣！

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

我在公司有实际工作，在一些中就有所提及的事情“标准化”。你会认为大部分东西只是常识，但你可能会感到惊讶。

Answer 16

正在对1号或者你只是写了，一两年后发行的软件2级支持。

相信我，我一直在那里我自己。我可能需要在几年内维护或增强我自己的代码的“恐惧”始终是提高可维护性的强大动力。

Answer 17

依我之见，以书面形式维护代码的基本规则是，你的代码应该是很容易理解的。这听起来并不像听起来那么容易，你必须使用这里提到的所有其他技术来做到这一点。它需要一定的同理心，因为您必须了解其他开发人员如何看待您的代码，以及它与您看到的方式有何不同。掌握这一点的一个好方法是回顾一下你几年前写的一些代码。

现在，我想，这将是可能的，在理论上，编写代码，这是非常容易理解和执行它到底是用于但也很难以任何方式修改任务。尽管如此，我从来没有见过这样的代码。

Answer 18

有很好的文档。这包括自我记录（分区，描述性命名和清晰）的代码，良好的评论，精确到（最近）最终版本代码的详细设计文档，以及源代码控制中的描述性更改注释。

如果你问了两个，第二个肯定是单元测试。这是两者之间艰难的选择。

Answer 19

对我来说，写测试代码（结帐谷歌测试博客）是更好的维护代码

Answer 20

没有“最重要因素”，这是几个因素的组合，如上文指出。

现在，大部分的这些规则可以浓缩成：“写后面的代码读取它。”
或者套用一个有趣又很好的建议：“你写的代码，就好像它必须由一个杀人狂知道你住的地方保持下去。” ......

Answer 21

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

Answer 22

我已经投了马特的回答“好抽象”但我想补充一下。

文档化这是所有关于解释事情。我都赞成Doxygen和其他自动文档工具，但API中粗略的函数列表总比没有好。

如果你想拥有你的代码maintanable，描述您的解决方案，以抽象的适当水平和细化水平提高到代码，这样很明显它做什么。

Answer 23

我会去一些其他的，抽象。当你了解一些软件模式时，它也会有所帮助，GOF是开始进行这类工作的好地方。

Answer 24

大量的空白。 - 高密度代码很难理解。如果你有超过6行没有空白行，那么这个组可能不是一个有凝聚力的思想/想法/操作。

良好的变量名称 - 解释性，但简洁。巨大的变量名称与小型变量名称一样糟糕。

Answer 25

阅读代码完整 - 它涵盖了从变量命名权到真正大的东西的一切，它是全部必要的。没有一件事。

我的做法目前归结到编写代码这样做需要做的（不适用于未来的每一个工作的代码可能需要可能做）用翔实的变量名和最小的变量范围，并努力确保该作业我代码尽可能少需要补充文档。有时候，这会使我的变量和方法名称比以前更冗长（当我使用它时，我的调试输出非常复杂），但它们更易于理解。

可维护性通常也是其他方面坚实实践的结果 - 如果您以良好的DRY方式编写代码，那么问题更容易找到，如果您有一组强大的测试，那么您可以看到维护变化将破坏任何东西。

最终还是试图要考虑周全，并写了面向未来的代码问题只能写一次，之后，这一切都维护...

Answer 26

小，良好定义的函数和类。

这是很容易习惯于别人的各种编码规范，但如果一切都在一个巨大的类或函数，我的头爆炸。

Answer 27

我会说最重要的因素是DRY。 glenatron在其他因素中已经提到了他的答案，但我认为这是最重要的一个。

Answer 28

毫无疑问，编写代码设计为供其他人阅读。这包括避免高尔夫球，神秘的语法，以及有意思的变量名称。如果代码足够干净，IMO可以完全避免写任何注释。 \

[采摘语言与OO内置的，而不是上涨了也有帮助]

Answer 29

我猜编写维护的代码超越代码。我相信最好理解需求是什么（并且以某种方式将其记录为功能性和非功能性），然后像新员工那样介绍如何将其转化为代码。

如果有人知道为什么代码原来是这样的，那么它变得更容易，使之更好和/或将其展开。对于更多技术性的东西（例如算法），将其抽象地解释（目标，原则），然后评论代码和/或模式实现的关键部分。

我还要做的一件事是在我的应用程序中创建迷你实验室，工具箱和代码模板，以便人们知道做一件事或扩展另一件事所需的“标准”代码是什么（导致一些复制/粘贴但有助于生产更多，更好）。

Answer 30

有一种倾向，认为计算机就是你的受众。

严格地说，这是事实，因为代码必须工作。但是，如果你在脑海中写下你的观众，那么这种思维方式有助于产生更多可读的代码。

如果您担心这会导致代码变慢，请记住，绝大多数程序几乎全部用于非常小的代码部分。从可读性开始编写代码，然后使用分析器确定要优化的正确部分。

Answer 31

我更喜欢当人们修剪和塑造代码的时候。很多时候，你会发现一个体面的建筑的原始脊柱，悬挂着巨大的混乱。

Answer 32

找到一位好导师。这个人不一定要比你更好的编码器，但他们应该能够建议其他适当编写代码的策略。一位好的导师将会提出以前给出的许多答案。他们可以成为第二组眼睛，让你知道你的短暂出现在哪里，同时保持乐观的乐观情绪。他们也会灵活并不断磨练自己的技能，就像你应该做的一样。这样，当下一个大范例出现时，你将能够更好地将麦糠与麦子分开。当面向对象编程和源代码控制被下一件大事所取代时（很难想象我知道），这将是无价的。

Answer 33

编程是性能;你永远不应该忘记你的观众是谁。 “就像最终维护你的代码的人是一个知道你住在哪里的暴力精神病患者一样。”

Answer 34

一贯应用的强大而合理的约定。类似于从何处开始索引的规则，什么是最终状态等。

这使得它更容易理解代码，因为所有代码的行为都会更简单。

这至少是我的一个重要提示。

Answer 35

• 记录假设当你让他们 - 两天后，你将采取这些假设是理所当然的，但谁维护您的代码不一定会做出同样的假设和旁边的人会问，为什么你做了什么你没有...

• 代码为人 - 计算机将做任何你告诉它;代码如此人可以理解你的代码 - 谁知道它可能是你6个月后！

Answer 36

这已经很长时间了，但我有一个答案扔在：不要超过评论。这可能听起来很愚蠢，但解释简单的东西的太多评论可能会使代码变得混乱，因为所有的东西都出去了。好的评论可以创造奇迹，但毫无意义的评论恰恰相反。

Answer 37

纯函数使得更容易推理代码。确保您正确传达副作用。 （即，当你不返回'结果'时通常会产生副作用，即无效函数）。