为什么编程应遵循 “30” 规则

2019 年 11 月 12 日

为什么编程应遵循 “30” 规则

软件质量,不但依赖于架构及项目管理,更与代码质量紧密相关。简洁高效的代码不但易于阅读,更能避免潜在 Bug 与风险,提高代码质量。这是显而易见的道理,但是要做到这个标准可不容易。想想看,据说 Oracle 12.2,有近 2500 万行代码,是不是很恐怖?你能做到在不破坏成千上万个现有测试的情况下更改这样产品中的单单一行代码吗?很难,对吧?要想避免这样的情况,就要从源头做起。“30”规则就是一个很好的办法,让我们看看 Riccardo Giorato 是怎么说的?

正文:

本文最初发布 Medium 博客,经原作者 Riccardo Giorato 授权,InfoQ 中文站翻译并分享。

如果你在编程中,不考虑代码长度的话,那么可维护性、未来更新或对代码库的更改,都将会变得异常困难。

方法或函数的大小应该多大呢?

我们都遇到过这样的问题,当一个函数太长的时候

或者类,或者包,或者任何其他代码块。在某些情况下,任何一段代码都有可能会变得过于庞大,以至于他人无法正确理解。但是,多大才算大呢?

Code Complete (《代码大全》,金戈等人译,电子工业出版社), Steve McConnell 指出,理论上,一个方法或函数的最佳最大限制是在一个屏幕上可以容纳的行数。

这种“适合屏幕”的尺寸相当于 65~200 行之间的函数的最佳点。这种大小的例程开发成本更低,每行代码的错误也更少,而且它们的可维护性也很高。

如果你写的代码超过了 200 行,那么,你就会进入了“危险区”:代码的可读性和正确性即将开始崩溃。

30 行代码规则

找寻找更严格的指导原则时,你可以在 Stephen Roock 和 Martin Lippert 合著的 Refactoring in Large Software Projects (《大型软件项目的重构》,暂无中文版)一书中找到“30”规则:

如果一个元素包含超过 30 个子元素,那么极有可能会存在严重的问题:

a) 方法的平均代码行数不应超过 30 行(不含行空和注释);

b) 一个类应该包含平均少于 30 个方法,最多可以包含 900 行代码;
c) 一个包包含的类不应超过 30 个,因此最多可包含 27000 行代码;
d) 应当避免使用超过 30 个包的子系统。这样一个子系统最多包含 900 个类,810000 行代码;
e) 因此,一个有 30 个子系统的系统,将拥有 27000 个类,2430 万行代码。

你应该遵循这些规则吗?如何做?

使用代码大小作为编码规则还是非常友好的;对于每个开发人员来说,无论年轻还是碾场,都很容易看到、理解。其他度量,如用于度量代码质量的循环复杂度(cyclomatic complexity),通常更难掌握,并且需要外部工具进行检查。

将类或函数长度限制在这些值范围内将是一个更好的起点,而不是对你的团队或开发人员没有真正的参考。你还会发现,当你审查或更新代码时,这“30”规则的真正价值是显而易见的。

试图将这些规则作为法律或强制性规则来执行,反而会让你置于危险之中——这并不是他们的目标。当你在编写方法中写到第 31 行时,你不会希望停下写代码,对吧?

此举将会降低工作速度,并迫使每个人都将代码分解以适应任意的大小限制,这将使他们的代码风格变得更糟,而不是更好。

正如 Jeff Langer 在讨论 Ken Beck 在 Clean Code (《代码整洁之道》,韩磊译,人民邮电出版社)一书中提到的简单设计的四条规则那样:

我们的目标是保持函数和类短小的同时,保持整个系统短小精悍。不过要记住,这在关于简单设计的四条规则里面是有限相机最低的一条。所以,尽管使类和函数的数量尽量少是很重要的,但更重要的确实测试、消除重复和表达力。

有时候,要完成一份连贯的工作需要 30 行或多或少的的代码。

更重要的是,在编写类时要小心,要考虑自己在这里添加了多少东西,其他人会理解这些结构和函数的分组吗?我应该分割这个文件呢,还是讲这个类与另一个类合并呢?

“30”规则将会给你带来帮助,但你必须不能让它支配你!

参考文献和资料

作者介绍:

摄影测量师,网页开发人员。

原文链接:
The rule of 30

2019 年 11 月 12 日 14:15 1831

评论

发布
暂无评论
发现更多内容

组合设计模式编码&手写单例模式

吴建中

极客大学架构师训练营

windows使用docker运行mysql等工具(二)安装运行mysql

Java旅途

MySQL Docker

第三周总结

晨光

架构师是怎样炼成的-3-2-设计模式

闷骚程序员

面向对象设计模式课程小结

行下一首歌

极客大学架构师训练营

[架构师训练营] Week01 -学习总结

谭方敏

第三周手写单例模式(饿汉模式)

吴建中

极客大学架构师训练营

【非原创】微服务设计

Arthur

让你眼前一亮的 10 大 TS 项目

阿宝哥

JavaScript typescript Web 前端开发 开源项目

区块链改变数字营销与广告市场

CECBC区块链专委会

区块链技术 广告业 精准投放 去中介 公开透明

Zookeeper的数据剖析

tunsuy

zookeeper 日志分析 事务 快照 数据恢复

架构师训练营 第三周 学习总结

RZC

rodert单排学习redis进阶【白银一】

JavaPub

Java nosql redis

Zookeeper通信协议详解

tunsuy

zookeeper TCP/IP 通信协议

极客大学架构师训练营 框架开发 模式与重构 JUnit、Spring、Hive核心源码解析 第6课

John(易筋)

spring 极客时间 极客大学 极客大学架构师训练营 JUnit

极客大学架构师训练营 框架开发 第三次作业

John(易筋)

极客时间 设计模式 极客大学 极客大学架构师训练营 框架开发

第三周作业

晨光

良心推荐 | LeetCode(力扣),算法、数据结构的学习良伴

YoungZY

算法

手写单例模式

yupi

架构师训练营第四周

Melo

组合模式应用

yupi

Zookeeper集群模式启动

tunsuy

zookeeper 源码分析 socket 分布式集群

太赞了!一份适合程序员的精选面试题清单。

JackTian

GitHub 编程 程序员 面试题 开源项目

一个汉字占几个字节你真的记住了吗?

Java旅途

第三周-设计模式-学习总结

吴建中

极客大学架构师训练营

Oracle SQL调优系列之看懂执行计划explain

Nicky.Ma

sql

HelloWorld.go

吐核hú

go 学习笔记 TraceLog

极客大学架构师训练营 系统架构 第7课 听课总结

John(易筋)

极客时间 系统架构 高并发 极客大学 极客大学架构师训练营

windows使用docker运行mysql等工具(一)windows安装docker

Java旅途

MySQL Docker

架构师训练营第三周作业和小记

tuuezzy

架构师 极客大学架构师训练营

架构师训练营 第三周 命题作业

RZC

跨越计算鸿沟:如何靠软硬件协同突破算力瓶颈?

跨越计算鸿沟:如何靠软硬件协同突破算力瓶颈?

为什么编程应遵循 “30” 规则-InfoQ