7 个不起作用的编码快捷键

原文：https://medium.com/hackernoon/7-coding-shortcuts-that-dont-work-82f03b3fb247

我们最近汇编并分析了一些最广泛使用的软件指标(你可以 这里下载我们的报告 )。作为工作的一部分，我们询问用户他们走了什么捷径，希望他们没有走。

披露: 自动化代码评审平台 Codacy 之前赞助过黑客 Noon。对于《黑客正午》的读者来说，他们正在 提供八五折优惠，使用这个代码:HACKERNOON 。

1.重复代码

"我认为最有价值的规则之一是避免重复. "“一次且仅一次”是极限编程的短语。”

马丁·福勒

这无疑是第一条规则。如果你希望你的代码坚如磐石并且永远存在，那么重复的代码是破坏你的目标的最好方法。这是因为如果你在一个副本中发现了一个错误，你就必须在所有其他副本中修复它。这是假设你能在第一时间找到它们，或者你甚至意识到它们。这增加了测试和调试的时间和成本。

需要考虑的事项

目标是在生产环境中实现零重复代码。你可能不会 100%达到目标，但这是一个值得追求的目标。
因式分解，因式分解，因式分解你的代码。
测试，测试，测试你的代码。

精神食粮

重构。马丁·福勒。链接。
“代码复制的完整循环”。链接。
何时代码复制是可接受的。(法格纳·布拉克，2016) 链接。

2.没有度量或者管理代码的复杂性

复杂害死人。它耗尽了开发人员的精力，使产品难以计划、构建和测试，引入了安全挑战，并使最终用户和管理员感到沮丧。

雷·奥茨

衡量代码复杂度的一个标准是圈复杂度，它是代码可以通过的逻辑分支的数量。实际上，它通常由 IF、WHILE、FOR、FOREACH 等表达式的数量来表示。

这种想法是，一个方法中的控制语句越多，它就越复杂，代码就越难阅读和理解，因此发生事与愿违的风险就越高。

需要考虑的事项

留意圈复杂度。像任何软件度量标准一样，它远非完美，但至少它会标记潜在的热点，甚至可能引发一些健康的反思。
记住:一个方法或一个类永远不会太小。
尽可能遵循单一责任原则。

精神食粮

独立路径。杰夫·尼曼。链接。
复杂性度量。托马斯·j·麦凯布。IEEE 软件工程汇刊，第 SE-2 卷，第 4 期，1976 年 12 月。链接。

3.遗忘代码设计

“构建一个软件设计有两种方式:一种是让它简单到明显没有缺陷，另一种是让它复杂到明显没有缺陷。第一种方法要困难得多。”

C.A.R .霍尔

故事是这样的:Bob X 编辑包 A，包 A 依赖于包 B，John Y 编辑包 B，包 B 又依赖于包 A。

欢声笑语随之而来。不是。

代码设计是不同的包、模块、类和方法相互链接的方式。了解特定的代码区域是如何与代码的其他区域相联系的，可以减少将您的工作变成一场叠积木游戏的几率。

需要考虑的事项

这里没有银弹。代码审查、测试和少量软件度量(无论是传入/传出耦合、与主序列的距离等)的健康组合。)可能会有帮助。

精神食粮

单一责任原则。维基百科。链接。
作为质量指标的面向对象设计度量的验证。Basili 等人，1995 年。链接。
软件包指标维基百科文章。链接。
德米特里法律维基百科文章。链接。
设计原则和设计模式。对象导师。罗伯特·马丁(2000 年)。链接。
OO 设计质量度量。依赖性分析。罗伯特·马丁(1994 年)。链接。

4.没有测试。没有代码覆盖率

程序测试可以用来显示缺陷的存在，但永远不能显示缺陷的不存在。”

-埃德格·迪克斯特拉

测试测试，测试你的代码。单元测试。功能测试。回归测试。并留意代码覆盖率。

代码覆盖率和支撑它的测试一样好，但是这是培养持续测试文化的好方法。它还有其他好处:它提供了对代码的某种程度的信任，并且它有助于在开发生命周期的早期识别需要进一步测试的代码区域。

需要考虑的事项

目标是大约 80%的代码覆盖率。但是请记住，代码覆盖率取决于驱动它的测试的质量。
高代码覆盖率并不能保证质量。但是低代码覆盖率应该让你停下来思考。
开发人员应该把大约 10%的时间花在单元测试上，直到他们达到目标代码覆盖率阈值。

精神食粮

测试，好玩吗？真的吗？链接。
代码覆盖率。维基百科。链接。
测试和代码覆盖率，保罗·约翰逊。链接。

5.没有风格指南

让我们从显而易见的事实开始:好的代码是能很好地完成工作，同时又易于维护、扩展和调试的代码。为了使代码易于维护、扩展或调试，它必须易于阅读和理解。

拥有风格指南对实现这一点大有帮助，这也是像谷歌这样的公司热衷于采用的原因。首先，通过限制选择，它消除了不必要的分心来源。开发人员可以专注于功能，而不是命名约定。这也让他们更容易分享代码。最后但同样重要的是，它提供了一定程度的可预测性:如果你的所有函数都使用 camelCase，那么任何阅读你的代码的人都知道‘sendmessage’是一个函数，而不是参数或变量。

需要考虑的事项

风格指南的建议有些争议，争论的双方都有有效的论据。一方看到了上一段所宣扬的好处。另一方面强调了这样一个事实:风格指南就像直筒夹克，对最终产品没有任何影响。这两种观点各有千秋，所以在下一节中，我们列出了两篇持相反观点的文章。

精神食粮

编码标准恐怖故事。链接。
为什么我放弃了编码标准。理查德·罗杰。链接。

6.评论太多，或者根本没有评论

如果没有人向你解释，一切都是复杂的。

弗雷德里克·巴克曼

如果说编写新代码是一件有趣的事情，那么代码注释就是我们大多数人宁愿不做的乏味的杂务。在理想情况下，代码是不言自明的，不需要任何注释。然而，有时候你需要弄清楚代码的目的是什么。它使代码维护更容易，并促进项目协作。然而，不管你怎么看，好的代码也意味着好的注释。因此，注释代码所需的时间应该计入总开发时间。

需要考虑的事项

过多的注释会适得其反，使代码难以阅读和维护。
不要对每个注释的指令行数设置严格的指导原则，而是要遵循一些常识性的规则，比如命名变量和方法的良好代码风格、自我解释的代码，以及偶尔解释为什么这段代码会做它要做的事情的注释。

精神食粮

评论的艺术。伯恩哈德·斯普伊达，2002 年。链接。
代码作为文档。马丁·福勒。2005.链接。

7.没有代码审查或代码审查太长

如果你读到这里，你可能知道代码评审有几个目的:

它们是确保代码质量的最佳实践。
他们促进团队协作
他们帮助应用代码标准
它们有助于在开发过程的早期识别 bug。
他们帮助开发人员入职和学习。

但是，让我们用一些来自麦康奈尔的《代码全集》的数据点来点缀一下上面的内容:

“ …单独的软件测试效率有限——单元测试的平均缺陷检测率仅为 25 %,功能测试为 35 %,集成测试为 45%。相比之下，设计和代码检查的平均效率是 55%和 60%。案例研究的评审结果令人印象深刻:

在一个软件维护组织中，在引入代码评审之前，55%的单行维护变更是错误的。在引入评论后，只有 2%的变化是错误的。当所有的改变都被考虑时，95%的人在引入评论后第一次是正确的。在引入评论之前，不到 20%的人第一次是正确的。
在由同一批人开发的 11 个程序中，前 5 个是在没有评审的情况下开发的。剩下的 6 个是带评论的。在所有的程序发布到产品中后，前 5 个程序平均每 100 行代码有 4.5 个错误。被检查的 6 个平均每 100 个中只有 0.82 个错误。评论减少了 80%以上的错误。
Aetna 保险公司通过检查发现了程序中 82%的错误，并减少了 20%的开发资源。
IBM 的 50 万线轨道项目使用了 11 级检查。它很早就交付了，只有正常预期的 1%的错误。
对 AT T 的一个超过 200 人的组织的研究报告称，在该组织引入评审后，生产率提高了 14 %,缺陷减少了 90%。
喷气推进实验室估计，通过在早期阶段发现并修复缺陷，每次检查可节省约 25，000 美元。

需要考虑的事项

系统地应用代码评审，例如每次提交。此外，考虑在你的 scrum 板上增加一个评论栏，确保每个人都坚持，包括团队领导。
不同的人会带来不同的观点，所以确保审查代码的不总是同一批人。
将代码评审分成小的每日会议，并保持每周 4-5 个小时的短时间是正确的。

精神食粮

关于同行评议的七个事实(卡尔·e·威格斯)。链接。
代码完成。史蒂夫·麦康奈尔。链接。
代码评审:只管去做。链接。编码恐怖。链接。

感谢阅读！如果你喜欢，点击下面的心形按钮:)

此外，我们还在电子书中编辑了最广泛使用的软件指标的评论，所有人都可以免费下载:

Click to get the ebook