您如何知道您是否编写了可读且易于维护的代码？

如何知道一个人创建的代码是否易于阅读，理解和维护？当然，从作者的角度来看，该代码具有可读性和可维护性，因为从一开始，作者就对其进行了编写和编辑。但是，必须有一个客观且可量化的标准，我们的行业可以据此衡量代码。

如果在没有原始作者的专业建议的情况下对代码执行以下操作，则可以达到这些目标：

• 可以阅读代码并从根本上理解逻辑流程。

• 可以更深入地了解代码在做什么以包括输入，输出和算法。

• 其他开发人员可以对原始代码进行有意义的更改，例如错误修复或重构。

• 可以编写新代码，例如利用原始代码的类或模块。

我们如何量化或衡量代码质量，使我们知道代码的可读性，可理解性和可维护性？

查看代码后，您的同伴会告诉您。

您无法自己确定这一点，因为作为作者，您所了解的远远超出了代码本身所说的。出于无法分辨绘画是否为艺术品的相同原因，计算机无法告诉您。因此，您需要另一个能够维护该软件的人员来查看您所写的内容并给出他或她的意见。该流程的正式名称是同行评审。

有时，最好的了解方法是回到六个月前编写的代码，然后尝试了解它的编写功能。

如果您快速了解-它是可读的。

它是：

1. 可维护，如果你能保持它。
2. 如果其他人可以在不需要您帮助的情况下进行维护，则易于维护
3. 如果其他人在阅读时正确理解了设计，布局和意图，则可读

1.的真正测试是（如Alex in Paris和quant_dev所说的），您可以在几个月后做其他事情后将其备份。

2.和3.的测试是其他人可以选择它，并弄清楚如何在遵循设计原则的同时扩展或修复代码。如果他们不了解设计，它与问题空间的关系或打算如何使用您的代码，则他们将跨整个领域寻找解决方案。

有经验法则，原则（即，经验丰富的人写下并给出名字的经验法则）以及各种建议，可能会引导您朝正确的方向发展，或者远离常见的陷阱。但是，它们都不能保证您所要求的质量。

如果您的代码遵循SOLID和DRY的原理，并且围绕它具有良好的单元测试集，则它可能是可维护的。

可读吗？阅读。方法和变量名有意义吗？您可以毫无问题地遵循程序逻辑吗？如果答案是肯定的，则代码是可读的。

阅读如何编写无法维护的代码-通过Roedy Green，大笑和学习确保终身工作。

...如何编写难以维护的代码，以至于您之后的人们将花费数年才能做出最简单的更改。此外，如果您虔诚地遵守所有这些规则，您甚至可以保证自己一生的工作时间，因为没有人会在地狱中维持代码的希望……

本文使用大量有趣的示例为您提供了许多有关如何编写不良代码的示例。它继续说明如何利用创造性的拼写错误，名称的重用，这是将全局名称重用为私有的备受赞赏的技术。

本文以幽默的方式教您如何避免所有不可读和不可维护的代码示例。

实际上，我发现很难相信有人会编写与文本示例相似的代码。那是我刚从学校毕业的时候。但是，工作了几年之后，我每天都会从文本中看到代码…

尽管看起来如此，但是您可以考虑一些相当客观的措施。诸如C ++编码标准，重构和清洁代码之类的书都有很长的准则来判断您的代码，这些准则包括有意义的名称，函数大小，原理（例如耦合和内聚），对象设计，单元测试，连续改进等。

该清单太大了，无法接受清单，但您先阅读了这本书，然后挑选出一些需要处理的关键事项，然后在几个月后再次阅读以进一步改进。

证明在布丁里。在将其交给合理胜任的人员后，观察发生的情况。如果他们不需要问很多与代码难度有关的问题，那么您做得很好。

这是我职业生涯的早期课程。一位导师说：“记录所有内容，以便以后可以退出程序。如果在您脑海中浮现新答案时就没想到问题，那么您就必须找出答案。”

我通读了所有答案，但没有发现任何人提到代码复杂性。

代码复杂度和可读性/可维护性之间有着紧密的联系。有许多代码复杂度评分算法，但我只讨论McCabe复杂度评分是如何工作的。

基本上，McCabe评分会读取您的代码，并计算通过它的唯一“路径”的数量。如果使用McCabe作为分子，并使用代码行作为分母，那么您还将获得与“可读性”相当好的近似值。

如果您有10行代码，并且该代码有300条路径，那是一些非常难以维护的代码（很难安全，轻松地进行更改），并且可能不太可读。相反，如果您有300行代码，但只有1条路径通过（没有条件），则它既可读又易于维护。

然而，在后者的例子中，麦凯布倒下了。如果我有300行无条件的代码，那么我很有可能完成了“复制/粘贴重用”，这显然也不是一件好事。因此，除了McCabe之外，您还可以应用系统范围内的指标-例如重复或接近重复的代码检测。

我要分享的一点是，代码是否内置在“模块”中，当我说我的意思是，您可以更改模块中的一件事并轻松地使其与整体配合使用。它消除了无关事物之间的影响。也：

• 代码易于重用
• 您的代码是灵活的（这与内置模块有关）
• 干-不要重复自己

我强烈建议您阅读《实用程序员》。

一些测试/指标：

• 关闭IDE。您还能阅读自己的代码吗？当存在错误时，手动查找它很容易并找出需要断点的类，以找出问题所在。还是当您使用IDE时，您甚至不打扰，只是从头开始？

• 进行调试是否经常成为一团糟的游戏，修复一个错误会产生2个以上的错误。

• 从触发器拉到实际发生的有用事情，需要多少次方法调用？有多少个方法将完全相同或大部分相同的参数传递给另一个方法调用？

• 您只需打开一个简单的新方法就可以打开几个文件？

• 考虑一下您采用的模式和做法。您之所以这样做，是因为它们很合理，还是因为有人说服您“这是唯一的方法”？或是因为您想要履历表上的原因，或是因为某位摇滚明星开发者这么说。

怎么知道他创建的代码是否易于维护和可读？

通过查找以下属性，可以发现易于维护和易读的代码：

1. 对象，方法和/或函数总是做一件事。
2. 方法和/或功能简明扼要（如“简短但全面”）。
3. 对象，方法和/或函数实际上是根据名称来执行您认为应该执行的操作。
4. 注定要重用的代码实际上是可重用的。
5. 最后但并非最不重要的一点是，如果您可以立即对代码进行单元测试，则可能至少已编写了单一职责的模块化代码。

我们怎么知道我们是否编写了凌乱且不可维护的代码？是否有任何结构或准则可以知道我们是否开发了凌乱的软件？

1. 如果您正在阅读一种方法，但意图并不明显，那么这充其量是微不足道的，而最坏的情况是难以维持的。
2. 如果它看起来不简单，则可能不是那么简单，这表明代码无法维护，或者代码很快将变得不可维护。
3. 如果整个代码库缺乏对称性（一致性），那么您可能正在寻找无法维护的代码。

一言以蔽之，体验。

首先，您需要进行基础工作，所以我不建议程序员花更多时间阅读诸如Refactoring之类的书，因为Refactoring将为程序员提供一些更重要的工具，这些工具将改善您的代码维护能力，以及由我们领域内一些最知名的专家编写的“ 干净代码”，它描述了您几乎所有需要了解的内容，以确保您的代码清晰易读。

但是，没有什么书可代替辛苦的经验。为了充分理解对代码质量的影响，您确实需要使用代码一段时间。通过体验使用整洁，因子分解的代码的乐趣以及使用代码细面条的痛苦，您将学会更好地理解这些书的作者真正想教给您的内容，但是您需要在更广泛的背景下进行操作实际的实时生产代码，真正重要的是质量，这会影响您每天轻松使用代码的能力。

拥有一个良好的导师或有经验的同事来确认您正在努力编写高标准的代码也有帮助。这只是代码审查如此有用的原因之一。使用代码检查和格式设置工具也可以非常有用，可以确保您保持环境整洁。但是，这与通过多年编写软件所获得的经验没有什么可比的，因此，您会自动发现自己编写的代码干净，可读性强，结构简单，只是为了易于维护，而这一切都是因为您习惯了为此应用最佳实践长。

无需清教徒：更喜欢功能样式。如今，大多数语言（.NET，Ruby，Python，Javascript等）都支持和推广它（例如LINQ，underscorejs）。

它非常容易阅读。

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

它迫使每个节点具有单一的，有针对性的意图贷款以明确目的。而且由于每个离散任务都是孤立弹出的，因此插入节点并将节点（操作）重新安排到不同的末端是微不足道的。这使得维护容易。

可读且可维护的代码：乍一看，程序员可以理解得很清楚的代码，可以轻松地做到：

• 通过其界面重用它，或者
• 调试它，或者
• 改变其行为。（添加/删除功能），或
• 优化它
• 测试一下

这归结为“澄清”。例如，程序员在确定自己“了解它的功能足够好”以完成手头的当前任务而不会引起意外副作用之前，必须询问几个特定的​​代码段问题。

史蒂夫·麦康奈尔（Steve McConnell）撰写的“代码完整”一书对此进行了详细介绍。

他仔细研究了各种指标，您可以使用这些指标确定代码的质量。

在此处查看示例：http : //books.google.co.uk/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false

最小化副作用（理想情况下没有副作用）

与仅输入某些内容并输出其他内容的函数相比，导致其自身范围之外的3种状态变化的函数要难于推理和维护。您不仅可以知道函数的功能，还必须记住它的功能以及它如何影响所有其他相关功能。

对于OOP来说，将副作用最小化还意味着类具有较少的成员，尤其是可以修改类状态的成员更少，因为成员函数可以修改超出其自身状态的状态并具有副作用（例如，它们可以操纵类的内部）。这也意味着类拥有较少的数据成员，因此这些方法被篡改的状态更少，并且它们可能引起的副作用也更少。

举一个简单的例子，想象一下尝试设计一个幻想的数据结构，该结构可以维持sorted用来确定执行二进制或线性搜索的状态。在这种情况下，将设计分为两类可能会很有用。sorted然后，调用未排序的类可能会返回另一个始终保持其内容排序的类的数据结构。现在，您具有更少的副作用（因此更少的容易出错且更易于理解代码），以及更广泛的适用代码（对于不需要排序的小数组，前一种设计在处理和人的智力效率上都是浪费的）。

避免多余的外部依赖

通过使用13个不同的库来完成一个相对简单的任务，您也许能够实现具有最大代码重用性的最简洁的代码。但是，这样一来，您不得不使读者至少了解13个不同库的一部分，从而将知识开销转移给您的读者。任何试图构建和理解第三方库的人都应该立即意识到这种固有的复杂性，而这需要引入并构建许多其他库才能起作用。

这可能是一个很有争议的观点，但是如果最终结果经过了很好的测试（没有比多次重复的未经测试的错误代码更糟糕的话），我宁愿进行一些适度的代码复制，而不是采取极端的做法。如果选择3行重复代码来计算向量叉积，还是选择史诗般的数学库以减少3行代码，那么我建议使用前者，除非您的整个团队都在使用此数学库，这时您仍然可以考虑只编写3行代码而不是1行代码，因为它足够琐碎以换取去耦的好处。

代码重用是一种平衡行为。重复使用过多，就会以一对多的方式转移知识的复杂性，因为上面保存的那三行简单代码的代价是要求读者和维护人员比三行代码了解更多的信息。这也会使您的代码不稳定，因为如果数学库发生更改，您的代码也可能会更改。重复使用太少，您的知识开销也会倍增，并且代码也无法从集中的改进中受益，因此这是一种平衡行为，但是值得一提的是，这是一种平衡行为，因为尝试消除每一种形式的适度复制会导致结果，与相反的极端情况相比，维护起来甚至要困难得多。

测试废话

这是给定的，但是如果您的代码不能处理所有输入情况并且错过了一些边缘情况，那么您如何期望其他人维护您编写的代码，甚至在转移到他们的眼睛和手上之前，您甚至还没有做好准备？很难更改能正常工作的代码，更不用说一开始就不正确的代码了。

最重要的是，通过全面测试的代码通常会发现更改的原因更少。这与稳定性有关，而与可维护性相比，这甚至是更重要的一点，因为不需要更改的稳定代码不会产生维护成本。

接口文件

如果您不能将相同的时间记录在文档上，那么将“事情做什么”优先于“事情如何做”。一个清晰的接口，其意图是在所有可能的输入情况下将要执行的操作（或至少要执行的操作），这将为其自身的实现提供清晰的上下文，这不仅将指导您理解如何使用代码，以及如何工作。

同时，无论其实现细节的文档化程度如何，缺少这些特质的代码甚至使人们甚至都不知道它应该做什么。对于长达20页的关于如何实现源代码的手册，这些人甚至无法弄清楚一开始应该如何使用它，以及在所有可能的情况下该怎么做。

对于实现方面，请优先记录与其他人不同的工作。例如，英特尔为其光线跟踪内核具有一个边界体积层次结构。由于我从事这一领域的工作，因此我一眼就能认出他们的代码在做什么，而无需仔细阅读文档。但是，它们做了一些独特的事情，即遍历BVH并使用ray包并行执行相交的想法。那是我希望他们优先处理其文档的地方，因为代码的这些部分在大多数历史BVH实现中都是奇异的和不寻常的。

可读性

这部分非常主观。我不太关心那种类似于人类思维过程的可读性。如果作者使用奇异而费解的思维过程来解决问题，那么对于我来说，仍然很难遵循最高程度文档化的最高级别描述事物的代码。同时，如果逻辑很简单，使用2或3个字符名称的简洁代码通常可以使我更容易理解。我想您可以同行评审，看看其他人喜欢什么。

我最感兴趣的是可维护性，更重要的是稳定性。没有理由更改的代码就是维护成本为零的代码。

我想说的一种了解方法是，新团队成员是否可以相对轻松地掌握，理解并修改代码以修复缺陷/满足新要求。

这是我喜欢使用的一种技术：

向您的一位同行程序员展示代码，并让他们向您解释它的作用。注意这些事情。

1）如果他们不能轻易解释代码块的目的，则对其进行重构。
2）如果他们必须跳到另一部分代码以了解当前部分，则对其进行重构。
4）在过程中，只要您想说话，都需要重构该部分代码。（代码本身并不代表）。

最具可维护性的代码是不存在的代码。因此，代替增加LOC数量，“减少” LOC数量的新代码（即使在单独查看时，即使可维护性稍差）也可以通过减小代码库的大小来使整个代码库更具可维护性。因此，可维护代码的主要规则是：

• 最大化DRY。

其次，对于可维护性而言，没有什么比隐藏的依赖项更糟糕了。因此，对于规则2：

• 明确显示所有依赖项。

第三，并不是所有的程序员都同样熟练地使用特定的更高级技术来维护或编写语言功能或习惯用法。精简整个代码库将为您提供庞大的代码库，由于其大小难以维护。在整个代码中允许使用高级技术功能和习惯用法将使所有代码仅由高级开发人员维护，这也是不好的。可维护性的关键是基于技能级别的分层，例如：

跨项目库：高级开发人员，技巧代码/习语/技术的完整介绍项目特定的库和系统后端：中级开发人员，避免使用最高级且难以解释的内容。老年人将通过此代码寻找DRY改进的机会。

前端：初级开发人员，请使用严格的样式指南和避免使用的语言集和习语集。Medior开发人员将使用此代码查找DRY机会和隐藏的业务逻辑。

因此，对于规则3：

• 根据开发人员的技术水平来分层代码，并相应地编写可维护的代码。

一世

尝试编写易读且易于维护的代码从来都不是一件容易的事，但是要编写易于维护的代码也不难。

OOAD是四个字母的单词，但一口气很难理解-遵循面向对象的分析与设计

1. 始终从良好的需求收集和确切的问题陈述开始

   • 从很少的用例开始，即；系统用户对话交互

2. 您必须保持对象松散耦合，并确保您的代码不会重复-遵循DRY [不要重复自己]

   • 每当您看到重复项时，都寻找一个可以封装的地方
3. 您的代码是开放的，可以扩展的，封闭的是修改的-OCP [开放式原则]
4. 当您更改代码时，请切记-不要创建问题来解决问题，IT只是声明不要修改您现有的功能
5. 单元测试您的代码
   • 出问题时总是测试您的代码
6. 在使用该功能时，请始终记住遵循基本的OOP（面向对象的原理）和技术，以确保从一开始就设计良好的应用程序
   • 对象应执行其名称指示的操作
   • 每个对象应代表一个概念
7. 永远记住系统的问题陈述，以及上下文/域软件在其中起作用
8. 也做一些文书工作-是的，对我有用
   • 可以打印一些与UI相关的内容和UML图
   • 您甚至还可以从白板上进行头脑风暴会议的屏幕截图
9. 建筑布局
10. 尽可能应用设计原则
11. 文献资料
    • 始终记录您的代码
    • 在IDE中设置缩进并记录