编写可维护的代码

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

1> Jim C..：

---

写给其他人阅读.这意味着良好的名称,良好的评论和简单的陈述的组合.

曾几何时,记忆稀缺,周期时间很慢.鼓励程序员编写复杂的单行代码,完成许多工作.今天记忆力充沛,周期时间很快.您应该编写5行简单代码,而不是他们无法理解的一行代码.

好的评论不必很长,但它们必须有用.

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

---

好点,但这不仅仅是为"其他人阅读"写作.尝试一年或更长时间了解您自己的代码.我想你在一年之后就是这些"其他人"之一.

2> Carlton Jenk..：

---

关注点分离(每种方法都做一件事) - 这会停止Spaghetti代码.

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

将代码分离出来以便每个任务都由专用于它的方法处理,这使得这很容易实现.

例如,如果我想改变肘部弯曲机器人软件的方式,那么使用名为BendElbow的方法可以使得需要进行更改变得简单.

3> jop..：

---

自动化单元测试.

如果您已经通过自动化测试覆盖它,您可以通过重构缓慢更改代码的设计,该自动化测试会告诉您何时破坏现有功能.自动化测试使更改代码的风险降低.

4> MattW...：

---

良好的抽象

5> Rontologist..：

---

单位测试放下手.如果您从get get中对代码进行单元测试,那么您将拥有一个测试套件,您可以运行该套件以在进行更改时验证代码的有效性.

此外,当您使用单元测试编写代码时,方法往往更小,因为它们更容易测试.同样,它应该鼓励您将方法用于单个任务 - 再次,因为它更容易测试这种方式.

6> Dave..：

---

良好的前期设计.没有什么可以挽救糟糕的设计.

7> Ash..：

---

在发布后的一年或两年内,为您刚刚编写的软件提供一级或二级支持.

相信我,我自己一直在那里.我可能必须在几年内保持或增强自己的代码的"恐惧"始终是提高可维护性的重要动力.

8> MattW...：

---

方法名称好

9> 小智..：

---

编写代码的倾向是认为计算机是您的受众.

严格来说,这是真的,因为代码必须工作.但是如果你考虑到你的人类观众,那么这种思维方式有助于产生更易读的代码.

如果您担心这会产生慢速代码,请记住,大多数程序几乎都是在非常小的代码中.开始编写可读性,然后使用分析器确定要优化的正确部分.

10> cciotti..：

---

不要做这些东西!感谢Roedy Green的笑声.

11> PhiLho..：

---

如上所述,没有"单一最重要的因素",它是几个因素的组合.

现在,大多数这些规则可以压缩成:"编写代码以便稍后阅读".
或者用一个有趣而又好的建议来解释:"把你的代码写成好像必须由一个杀人的疯子维护,知道你住在哪里."......

12> glenatron..：

---

阅读代码完成 - 它涵盖了从变量命名到真正重要的内容的所有内容,这一切都是必要的.没有一件事.

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

可维护性通常也是其他方面的可靠实践的结果 - 如果您以干燥的方式编写代码,那么问题就更容易找到,如果您有一套强大的测试,那么您可以看到维护更改是否正在进行打破任何事情.

最终这是一个试图深思熟虑并为未来写作的问题 - 代码只写一次,之后就是所有的维护......