编码过程中需尽量避免的 7 条捷径

1. 复制代码

“我认为最有价值的规则是避免重复。有且仅有一次是极限编程里的说法。- Martin Fowler

这很容易成为头号规则。如果你想要你的代码坚如磐石,永世长存,那么重复的代码是破坏你目标的最好的方法。那是因为如果你在一个副本中发现一个错误,你必须在所有其他副本中修复它。这里假设你首先能找到他们,或者你甚至知道他们。这使得测试和调试的时间和成本都增加了。

注意事项:

  • 目标是在产品环境中的零重复代码。你可能不会达到100%,但这是一个有价值的目标。
  • 分解,分解和再分解代码。
  • 测试,测试和再测试你的代码。

进阶思考:

  • 重构。Martin Fowler:https://martinfowler.com/books/refactoring.html
  • “在代码复制上实现闭环”. :http://blog.robertelder.org/coming-full-circle-on-code-duplication/
  • 何时代码重复是可接受的。 (Fagner Brack, 2016):https://hackernoon.com/when-code-duplication-is-acceptable-51ce33ecd0f5

2.没有测量或管理 - 代码复杂度

"复杂度杀手。复杂度不断吞噬着开发者的生命,它使得产品很难做计划,很难构建和测试,同时它也引入了安全性威胁,并且让用户和管理者感到沮丧。" -- Ray Ozzie

代码复杂度的一个衡量方式是循环复杂度。它是指代码可以通过的逻辑分支的数量。实际中,它经常近似于 IF, WHILE, FOR, FOREACH 等类似表达式的数量。

想一下就知道一个方法中控制状态越多,它就越复杂,别人也就很难读懂和明白,因此事与愿违的风险也就越高。

注意事项:

  1. 紧盯循环复杂度。就像任何软件度量,他们虽不是那么完美,但至少标识出了潜在危险区域并有可能引发合理的重构。
  2. 一定要记住:一个方法或类从来都不会太小。
  3. 尽可能地,遵从单一任务原则 (single responsibility principle)。

进阶思考:

  • 路径测试:独立路径。Jeff Nyman. :http://testerstories.com/2014/06/path-testing-independent-paths/
  • 复杂度测量。Thomas J. McCabe. IEEE Transactions on Software Engineering, Vol. SE-2, No 4, December 1976. :http://www.literateprogramming.com/mccabe.pdf

3. 忘记代码设计

"构建软件设计有两种方法:一种是使它尽可能简单以至于没有明显的缺陷,另一种是使它尽可能复杂以至于看不出明显的缺陷。第一种方法更难以实现。" -- C.A.R Hoare

故事就像这样发生了: Bob X 编辑包 A , 包 A 依赖于包 B。Jonh Y 编辑包 B,然而包 B 又反过来依赖于包A。

好戏开始了...No, 最好不要这样做.

代码设计是不同的包, 模块, 类和方法被互相连接在一起的方式.

要对此有一些思考: 一个区域的代码如何被连接到其它区域的代码但却可以有效减少陷入叠积木游戏的几率。

注意事项:

没有银弹(silver bullet)。代码评审, 测试和少量代码度量(输入输出耦合, 到主序列距离等)的合理搭配可能会更有帮助。

进阶思考:

  • 单一任务原则. Wikipedia. :https://en.wikipedia.org/wiki/Single_responsibility_principle
  • 面向对象设计指标作为质量指示的验证. Basili et al. 1995. :https://pdfs.semanticscholar.org/77dd/b5c10e69b4e4104deb20e9d6888b31187c55.pdf
  • 软件包装度量. Wikipedia article.:https://en.wikipedia.org/wiki/Software_package_metrics
  • 迪米特法则. Wikipedia article. :https://en.wikipedia.org/wiki/Law_of_Demeter
  • 设计原则和设计模式. Object Mentor. Robert C. Martin (2000). :http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf
  • 面向对象设计质量度量. 相关性分析. Robert C. Martin (1994).:https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf

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

"程序测试能被用来发现 bug 的存在, 但从来不能证明不存在 bug 。" -- Edsger Dijkstra

检验测试并测试你的代码。单元测试, 功能测试, 回归测试。时刻关注代码覆盖率。

代码覆盖率的好坏取决于支撑它的测试代码, 但它却是一个形成持续测试文化的好方法. 同时也有其它一些好处: 它提供了对代码一定级别的置信度, 它也在开发周期帮助识别出需要更进一步测试的代码区域.

注意事项:

  • 代码覆盖率的目标大约是 80% 。但是请记住: 代码覆盖率的好坏取决于驱动它的测试代码的质量。
  • 更高的代码覆盖率并不保证更高的代码质量。但是低代码覆盖率应该使你停下来想一下为什么。
  • 开发者应该花大约 10% 的时间在单元测试上,直到达到目标代码覆盖率。

进阶思考:

  • 测试, 有意思? 真的吗!? :https://www.ibm.com/developerworks/library/j-test/ (结论是: 写测试代码可能并不是那么有意思, 但最终会让你的开发过程受益, 让开发变的有意思)
  • 代码覆盖率。Wikipedia. :https://en.wikipedia.org/wiki/Code_coverage
  • 测试和代码覆盖率。Paul Johnson.:http://pjcj.net/testing_and_code_coverage/paper.html

5. 没有编码规范

我们从很明显的地方开始:好的代码是工作良好且容易维护、扩展和调试的代码。为了使代码容易维护、扩展或调试,那么代码必须易于阅读和理解。

如果有编码规范就容易写出像上述那样的代码,这就是为什么像谷歌这样的公司都采用在编码规范上有很大的投入。首先,通过限制选择,它消除了不必要的分心来源。开发人员可以专注于功能,而不是命名约定。它也让开发者们共享代码变得更容易。

最后,编码规范提供了一定程度的可预测性:如果你的所有功能使用驼峰命名,那么任何人阅读你的代码都能知道` SendMessage `是一个函数,而不是参数或变量。

注意事项:

采用编码规范这个建议有时候有些争议,争议的双方都有有效的依据。一方认为编码规范的好处正如前文所述的那样。另一方则强调编码规范就像直夹克,对最终的产品没有影响。这两个论点都有其优点,因此在下一节中,我们将列出两个具有相反观点的文章。

进阶思考:

  • 标准编码的恐怖故事.:http://www.lhotka.net/weblog/CodingStandardsHorrorStory.aspx
  • 为什么我放弃了编码规范. Richard Rodger. :http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/

6. 注释太多,或者完全没有注释

“如果没人想你解说,所有的事情都是复杂的。” - Fredrik Backman

如果编写新代码是有趣的话,代码注释是我们大多数人宁可不做的一件繁琐的事情。在理想情况下,代码是非常明了的,不需要任何注释。但是,有时你需要澄清该代码的目的是什么。它使代码维护更容易,并促进项目上的协作。不管你怎么看,好的代码也意味着好的注释。因此,注释代码所需的时间应计入总开发时间。

注意事项:

  • 太多的注释是适得其反的,这使得代码难以阅读和维护。
  • 不要为每条注释的代码行数设置严格的指导原则,而应遵循一些常识规则,比如关于命名变量和方法的好的代码风格,自解释代码,以及偶尔的用于解释为什么这段代码要这么做的注释。

进阶思考:

  • 注释的艺术 Bernhard Spuida, 2002. :http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf
  • 代码即文档。Martin Fowler. 2005. :https://martinfowler.com/bliki/CodeAsDocumentation.html

7. 没有代码评审或者代码评审时间过长

如果你阅读此条目,你可能知道代码评审有以下几个目的:

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

但是,让我们从 McConnell 的《代码大全》一书中拿出一些坚实的、客观的数据点来说明下:

… 单靠软件测试的效率是有限的 - 单元测试的平均缺陷检测率仅为 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万行的 Orbit 项目使用了 11 个级别的审查。它是提前交付的,仅有约百分之一的正常预期的错误。
  • 对 AT&T 中一个有200多人的组织进行的一项研究报告称,该组织在引入评审后,生产力提高了14%,缺陷减少了90%。
  • 喷气推进实验室(Jet Propulsion Laboratories)估计,通过在早期发现和修复缺陷,每次审查可节省大约25,000美元。“

注意事项:

  • 系统地应用代码评审,例如在每次提交时。另外,考虑在你的 Scrum 看板上添加一个评审专栏,并确保每个人都坚持下去,包括团队领导。
  • 不同的人带来不同的观点,因此确保评审代码的人不总是相同的。
  • 把代码评审分解成小的日常会议,并保持短期每周4-5小时是正确的。

进阶思考:

  • 结对评审的七个真相 (Karl E. Wiegers). :http://www.processimpact.com/articles/seven_truths.html
  • 代码大全 Code complete. (Steve McConnell). :https://www.amazon.co.uk/Code-Complete-Practical-Handbook-Construction/dp/0735619670
  • 代码评审:立即做。链接。编码黑洞 Code Reviews: Just Do It. Link. Coding Horror. :https://blog.codinghorror.com/code-reviews-just-do-it

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2017-12-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

程序员小测试:保守派 vs 自由派

最近,我在阅读 Steve Yegg 的文集《程序员的呐喊》。 ? 这是一本非常有趣的书,里面甚至包含了一个小测试(原文),区分一个程序员到底是保守派还是自由派...

2956
来自专栏大数据

FPGA、DSP、ARM比较

ARM ARM(Advanced RISC Machines)是微处理器行业的一家知名企业,设计了大量高性能、廉价、耗能低的RISC处理器、相关技术及软 件。A...

2889
来自专栏Java学习网

重新敲一遍代码,胜过拷贝粘贴

重新敲一遍代码,胜过拷贝粘贴  如今这个时代,Google 和 Stack Overflow 已经成为了很多开发者不可或缺的工具。但是最近,后者貌似名声坏了。一...

2699
来自专栏数据科学与人工智能

【Python环境】Python 开发者节省时间的 10 个方法

Python 是一个美丽的语言,可以激发用户对它的爱。所以如果你试图加入程序员行列,或者你有点厌倦C++,Perl,Java 和其他语言,我推荐你尝试Pytho...

2527
来自专栏AI科技大本营的专栏

经验 | 如何成为一名顶级战斗力的数据分析师?

翻译 | AI科技大本营(rgznai100) 参与 | reason_W 不知道大家以前听没听说过“10x Developer”这个词,如果你连听都还没听说过...

3047
来自专栏钱曙光的专栏

一周极客热文:200 行 C 代码编写你的第一个垃圾收集器

一名程序员在许多事物缠身,心里烦乱的情况下如何排解呢?Google Dart团队的一名工程师通过编写一个“垃圾收集器”来调整自己,而且起到了一个非常好的效果,但...

2119
来自专栏HBStream流媒体与音视频技术

借用PortAudio采集和播放音频,实现双路混音器

4035
来自专栏C语言及其他语言

重新敲一遍代码,胜过拷贝粘贴

来源:腊八粥 网址:http://www.labazhou.net/2015/10/dont-copy-paste-retype/ ---- 原文地址(ori...

3175
来自专栏华章科技

图文大话编程语言史

所谓大话就是恶搞,本文中的关于各种编程语言的描述,你不可全信,也不能全信。作者在描述史实时加入了很多个人情感和社会流行元素,配图基本是靠谱的。这也许就是寓教于乐...

981
来自专栏程序人生

Pipe 之美

Unix 三大宝是 C,file 和 pipe。C的重要性自不必说,如果 Lisp 是编程语言之母,那么 C 就是编程语言他爹。file 是 unix 世界的夸...

4137

扫码关注云+社区

领取腾讯云代金券