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

#1 楼

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

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

#2 楼

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

如果您很快理解它-就是可读的。 >

#3 楼

它是：


可以维护，如果可以维护的话。否则，在阅读时，正确理解了设计，布局和意图。

1.的真正测试是（如Alex in Paris和quant_dev所说的），您可以在几个月的工作后将其取回

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

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

#4 楼

如果您的代码遵循SOLID和DRY的原理，并且围绕它进行了很好的单元测试，则它可能是可维护的。

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

#5 楼

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


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


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

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

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

#6 楼

不管看起来如何，您都可以考虑一些相当客观的措施。诸如C ++编码标准，重构和整洁代码之类的书都有很长的标准，可用来判断代码，例如，有意义的名称，函数大小，耦合和内聚性等原则，对象设计，单元测试，逐项改进等。 br />
列表太大，无法接受清单，但是您读了这本书并挑选了一些要处理的关键事项，然后在几个月后再次阅读以进一步改进。

#7 楼

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

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

#8 楼

我通读了所有答案，但没有发现任何人提到代码复杂性。代码复杂度评分算法有很多，但我只讨论McCabe复杂度评分的工作原理。

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

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

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

#9 楼

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

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

#10 楼

一言以蔽之。

首先，您需要进行基础工作，因此我不建议程序员多花些时间阅读诸如Refactoring之类的书。将在程序员库中提供一些更基本的工具，这些工具将提高您的代码维护能力，以及由我们领域中一些最知名的专家编写的“干净代码”，它几乎描述了您需要了解的所有内容为了确保您的代码清晰易读。为了充分理解对代码质量的影响，您确实需要使用代码一段时间。通过体验使用整洁，因子分解的代码的乐趣以及使用代码面条的痛苦，您将学会更好地理解这些书的作者真正想教给您的内容，但是您需要在更广泛的背景下进行操作真正的实时生产代码，您所做的工作的质量真正重要，这会影响您每天轻松使用代码的能力。一个有经验的同行来确认您正在努力编写高标准的代码。这只是代码审查如此有用的原因之一。使用代码检查和格式设置工具也可以非常有用，可以确保您保持环境整洁。但是，没有什么比得上多年编写软件所获得的经验，因此，您会自动发现自己编写的代码干净，可读性强，结构简单，只是为了易于维护，而这一切都是因为您已经习惯了为此应用最佳实践长。

#11 楼

一些测试/指标：


关闭IDE。您还能阅读自己的代码吗？当存在错误时，手动查找它很容易并找出需要断点的类以找出问题所在？还是当您使用IDE时，您甚至都没有打扰甚至只是从头开始？
调试是否经常成为一堆麻烦的游戏，其中修复一个bug会产生2个以上的错误。
从触发器拉到实际发生的有用事情，需要多少次方法调用？有多少个方法将完全相同或大部分相同的参数传递给另一个方法调用？
要给一个类添加一个简单的新方法，您需要打开多少个文件？
思考一下模式和您采用的做法。您之所以这样做，是因为它们很合理，还是因为有人说服您“这是唯一的方法”？或者是因为您想在履历表中使用它，或者是因为某个摇滚明星开发者这么说。

#12 楼

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


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


对象，方法和/或函数总是做一件事。
方法和/或函数很简洁（如“简短而全面”）。 ，方法和/或函数实际上会根据名称执行您认为应该做的事情。
注定要重用的代码实际上是可重用的。可以立即对代码进行单元测试，您至少可能已经编写了单一职责的模块化代码。 />代码？是否有任何结构或准则可以知道我们是否开发了
凌乱的软件？是，这充其量是不好的，最坏的情况是可能无法维护的。 >如果整个代码库缺乏对称性（一致性），那么您可能正在查看无法维护的代码。

#13 楼

可读且可维护的代码：
程序员一眼就能理解的代码，可以很容易地做到：


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

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

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

他会检查各种指标，您可以使用这些指标确定代码的质量。

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

#14 楼

无需清教徒：更喜欢功能样式。如今，大多数语言（.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);

它强制每个节点具有单一的，有重点的意图贷款，以达到目的明确的目的。而且由于每个离散任务都是孤立弹出的，因此插入节点并将节点（操作）重新排列到不同的端部是微不足道的。这样可以简化维护。

#15 楼

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

与仅输入某些内容并输出其他内容的功能相比，一种导致3种状态变化超出其自身范围的状态的功能要难得多。您不能只知道函数的功能，还必须记住它的功能以及对所有其他相关功能的影响。可以修改类状态的成员，因为成员函数可以修改其自身之外的状态并具有副作用（例如，它们可以操纵类的内部）。这也意味着类拥有较少的数据成员，因此这些方法被篡改的状态更少，并且它们可能导致的副作用也更少。该结构可以维持sorted状态，用于确定是执行二进制搜索还是线性搜索。在这种情况下，将设计分为两类可能会很有用。然后在未排序的类上调用sorted可能会返回另一个始终保持其内容排序的类的数据结构。现在，您将具有更少的副作用（因此更少的容易出错且更易于理解代码）以及更广泛的应用代码（对于不需要排序的小数组，前一种设计在处理和人类智能效率上都是浪费的）。

避免过多的外部依赖性

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

这可能是一个很有争议的观点，但是我会如果最终结果是经过充分测试的，则更喜欢将一些适度的代码重复用于相反的极端（没有比多次重复的未经测试的错误代码更糟糕）。如果是在三行重复的代码之间进行选择以计算向量叉积，或者在史诗般的数学库中进行剃光以减少三行代码，那么我建议使用前者，除非您的整个团队都在使用此数学库，此时，如果它足够琐碎以换取去耦的好处，那么您可能仍然考虑只写3行代码而不是1行。

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

测试废纸C这是给定的，但是如果您的代码不能处理所有输入情况并且错过了一些边缘情况，那么您如何期望其他人维护您编写的代码，甚至在转移到他们的眼睛和手上之前，您甚至还没有做好准备？很难更改能正常工作的代码，更不用说一开始就永远不正确的代码了。更改。这关系到稳定性，而不是可维护性，这比实现稳定性更是一个圣杯，因为无需更改的稳定代码不会产生维护成本。如果您不能将相同的时间记录在文档中，那么“做什么”而不是“如何做”。一个清晰的界面，其意图是在所有可能的输入情况下将要执行的操作（或至少要执行的操作），这将为其自身的实现提供清晰的上下文，这不仅将指导理解

同时缺少这些特性的代码是SOL，无论其实现细节的文档化程度如何，人们甚至都不知道它应该做什么。长达20页的有关如何实现源代码的手册对于甚至无法弄清楚一开始应该如何使用它以及在所有可能的情况下甚至应该做什么的人来说都是毫无价值的。 br />对于实施方面，请优先记录与其他人不同的工作。例如，英特尔为其光线跟踪内核具有一个边界体积层次结构。由于我从事这一领域的工作，因此我一眼就能认出他们代码的大部分工作，而无需仔细阅读文档。但是，它们做了一些独特的操作，即遍历BVH并使用射线包并行执行相交的想法。那是我希望他们优先考虑其文档的地方，因为代码的这些部分与大多数历史BVH实现是异乎寻常的和不寻常的。我不太关心那种类似于人类思维过程的可读性。如果作者使用奇异而费解的思维过程来解决问题，那么对于我来说，仍然很难遵循最高程度文档化的最高级别描述事物的代码。同时，如果逻辑很简单，使用2或3个字符名称的简洁代码通常可以使我更容易理解。我想您可以同行评审，看看其他人喜欢什么。没有理由更改的代码就是维护成本为零的代码。

#16 楼

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

#17 楼

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

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

1）如果他们不能轻易解释代码块重构的目的。
2）如果他们不得不跳到另一部分代码来理解
4）在过程中任何时候只要您想说话，都需要重构该部分代码。 （代码本身并不代表）。

#18 楼

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



最大化DRY。因此，对于规则2：


使所有依赖项都明确。语言功能或习语。精简整个代码库将为您提供庞大的代码库，由于其大小难以维护。在整个代码中允许使用高级技术功能和惯用语将使所有代码仅可由高级开发人员维护，这也是不好的。可维护性的关键是基于技能级别的分层，例如：

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

前端：初级开发人员，使用严格的样式指南和一套技术来避免语言构造和习惯用法。 Medior开发人员将使用此代码来寻找DRY机会和隐藏的业务逻辑。

因此，对于规则3：


按开发人员的技术水平分层您的代码，相应地编写可维护的代码。

I

#19 楼

显然没有被重视的方面是命名。我现在想集中讨论。
一切都从命名事物以及它们在相关人员的思想中如何映射到现实开始。如果名称没有解释的余地​​，那就麻烦了。我了解到，不良的自然语言技能通常会导致不良的编码。
注意在现有环境中“固定”名称。如果许多人随着时间的流逝而学习并适应了一些愚蠢的术语，并且当他们听到这些声音时都想到同一件事，那么修复它可能会带来更多的麻烦。如果由于确实很糟糕而仍要执行此操作，请确保将其修复到域中的所有位置。不过，这可能是不可能的。
命名组件和类还有很长的路要走。里面有什么？它与其他组件和类有什么关系？所有这些决定都将受到名称解释的影响。
过快地定名只是为了与它相处永远不是一件好事。
本周我非常热衷于命名，因为我一直在努力更新协议实现，这需要我阅读规范文档并向现有代码添加新功能。事实证明，我的前任不喜欢规范文档中使用的任何术语，该文档是源自客户端的PDF。因此，他为以后不得不处理其代码的所有维护人员“修复”了该问题。如您所料，我在将规范映射到代码以及理解逻辑方面遇到了一些麻烦。他的名字比他们好得多。在开始做任何事情之前，我必须首先匹配所有内容并重新同步名称。
在软件开发中，没有“仅是名称”之类的东西。如果名称不完全正确，则需要知识才能获得正确的想法，这是一个障碍。