NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

代码行数是致命因素吗?

  • 2007-12-26
  • 本文字数:1874 字

    阅读完需:约 6 分钟

Steve Yegge最近的一个帖子触动了开发社区的神经。Steve 主张将代码数量保持在一个绝对的最小值,是软件开发中最重要的事情。依他的看法,即便仅仅出于缩减代码行数的理由,你或许也该牺牲一些设计模式和避免一些重构。如果问题域太大,做不到这一点——那么你可以换到另一种编程语言。

……我相信,相当坚定地相信,对于一个代码库来说,最坏的事情就是它的大小。

Steve 认为,代码大小有毁灭性的影响:

多数人可能不认同我的观点:山一样的代码是一个人、一个团队、一家公司所能遭遇的最严重的灾害。我认为代码的重量会压垮项目和公司,它迫使人们在达到一定大小后就不得不重写,明智的团队会尽其所能阻止代码库变成一座大山。

Steve 说他本来也可以用代码肿胀的说法,但问题是开发者鉴别不出肿胀,而且他要说的也不是一般偶然遇到的复杂性。

我说的“大小”只是用来代替一个相对更加合适的概念,因为我暂时找不到更好的词汇来表达。我会来回说明这个词所代表的含义,直到你理解我的意思,或者帮我找到一个更合适的词。“肿胀”这个词可能更准确,因为每个人都知道肿胀是不好的,但不幸很多所谓有经验的程序员都不知道该怎么检测肿胀,他们会指着一个剧烈肿胀的代码库,说它瘦得像电线杆一样。

这个帖子的背景是 Steve 曾经用 Java 写了一个在线游戏,现在已经达到了 500,000 行代码,他无法再自己一个人维护这么大的代码库。因此不久前他把游戏撤了下来,现正用 JavaScript 重写。

我是经历过很多才得出这样的观点。人们很少关心代码库的大小,它并不被广泛认为是一个问题,实际上它被广泛认为不是一个问题。

那工具又如何呢?工具能让代码管理变轻松吗?

这一行的人们对于名义上有助于对付巨大的代码库的各种思路非常热衷,比如能把代码当成“代数结构(algebraic structure)”来操弄的 IDE,搜索索引之类。这些人看待代码库的眼光和建筑工人看待一堆土差不多:他们想要能把这堆土随意搬来搬去的大机器。

如果只是说到这个份上,很多开发者都还同意 Steve 的观点。凡是曾经接手大型代码库的人都清楚,代码行数本身就令人头痛。

如果你有 1 百万行代码,按每“页”50 行算,那就是 20,000 页的代码。你读完一本 20,000 页的说明书需要多长时间?仅仅是浏览代码库,尝试辨认出总体的结构可能就要花费数周甚至数月,取决于信息的密度。重大的架构变更可能需要数月甚至数年。

Steve 比大多数开发者更激进,他主张出于最小化代码库的目的,避免设计模式和重构可能是好的选择。

重构在 Java 这类语言身上表现出来的问题,很接近我的命题的中心:重构会使代码库变大。我估计现有 IDE 所支持的各种标准重构当中,能使代码库变小的不超过 5%。

至于设计模式,他写道:

设计模式——至少 GoF 书中的大部分模式——使代码库变得更大。可悲的是,唯一有助于缩小代码库的 GoF 模式(Interpreter)被那些程序员全然忽略了,而他们甚至把设计模式的名称纹在了身上。

不久之前 InfoQ 总结过对依赖注入的争论,Steve 把 DI 也归入了代码肿胀的类别:

像依赖注入这类流行的新 Java 设计模式,Ruby、Python、Perl 和 JavaScript 程序员可能从未听过。即便听过,他们也很可能(正确地)断定自己不需要它。依赖注入是一种极其精妙的基础架构,它在某些方面令 Java 更加动态,而那些方面正是更高级语言的本质所在。而且,用不着猜,DI 会让你的 Java 代码库变得更大。 用 Java 就要忍受它变大。活着就要生长。Java 就像是俄罗斯方块游戏,没有哪一块能完全填满其他块造成的缺口,而不造成新的缺口,因此你只能无休止地叠下去。

在跟贴里人们争论得很热烈。很多人觉得解决的方法是把代码分解成库,这样就不需要去理解全部的代码,至少不需要一下子全部理解。 Udi Dahan 问:

假如你按照这样的方式去组织代码,比如说每次做一件有意义的工作时只需要查阅不超过 1000 行代码,那么总共有 50 万行代码是一个大问题吗?

Jay Levitt 插了进来,他不同意 Udi,还借用了“成层现象(stratification)”这个词来表述他的意思。

我不断看到这样一种反模式,不过还没给它找到很好的名字。我叫它“成层现象”。 简单说,你越是编写高级的库来包装低级的库,低级库就用得越少,于是你就更不了解它们。渐渐地,你甚至忘了它们的存在。到了那个时候,你将(不可避免地)在高级库之上编写更高级的库,目的却是重新实现低级库的功能。

大小重要吗?我们都同意偶然的复杂性是不好的,应当消除;但如果代码实际上是清晰的,却仍然很庞大呢——我们是接受现实,还是采取非同一般的手段,像回避重构或者换用其它编程语言,去缩减代码的大小?大小有多重要?

查看英文原文: Does lines of code kill?

2007-12-26 16:581343
用户头像

发布了 225 篇内容, 共 61.0 次阅读, 收获喜欢 50 次。

关注

评论

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

TiDB HTAP 遇上新能源车企:直营模式下实时数据分析的应用实践

TiDB 社区干货传送门

TiDB 6.0 的「元功能」:Placement Rules in SQL 是什么?

TiDB 社区干货传送门

6.x 实践

TiDB 查询优化及调优系列(一)TiDB 优化器简介

TiDB 社区干货传送门

将 AWS S3 数据迁移至 TiDB Cloud 集群

TiDB 社区干货传送门

体验 TiSpark 基于 TiDB v6.0 (DMR) 最小实践

TiDB 社区干货传送门

实践案例 6.x 实践

【故障解读】v5.3.0 BR 备份报错并且耗时比升级前更长

TiDB 社区干货传送门

备份 & 恢复

一个小操作,SQL查询速度翻了1000倍。

TiDB 社区干货传送门

性能调优 实践案例 管理与运维 故障排查/诊断

PD节点恢复之一个也不剩

TiDB 社区干货传送门

集群管理 故障排查/诊断 备份 & 恢复 扩/缩容

TiDB Numa 性能压测

TiDB 社区干货传送门

版本测评 性能测评

Facebook 开源 Golang 实体框架 Ent 现已支持 TiDB

TiDB 社区干货传送门

应用适配 数据库连接

我和TiDB的故事 | 毫无准备地不期而遇,却想说与你相遇好幸运

TiDB 社区干货传送门

社区活动

关于auto_random的几个知识点

TiDB 社区干货传送门

管理与运维

对Indexlookup的理解误区

TiDB 社区干货传送门

管理与运维

【故障解读】v5.1.1-调整变量 tidb_isolation_read_engines 影响 tiflash SQL 执行计划

TiDB 社区干货传送门

HTAP 场景实践

tidb 2.1升级到4.0操作文档

TiDB 社区干货传送门

迁移 版本升级

在华为 Kylin V10 SP1操作系统,HUAWEI,Kunpeng 920 CPU(4Cores)单机上模拟部署生产环境TiDB集群

TiDB 社区干货传送门

集群管理

TiDB Online DDL 在 TiCDC 中的应用

TiDB 社区干货传送门

迁移 TiDB 底层架构

TiDB v5.1.2 - TiCDC 不同步,checkpointTs 不推进的问题排查

TiDB 社区干货传送门

实践案例 故障排查/诊断

新版 TiDB 社区技术月刊,一站式 Get 社区全动态

TiDB 社区干货传送门

社区活动 故障排查/诊断 数据库架构设计 应用适配

TiDB上百T数据拆分实践

TiDB 社区干货传送门

迁移 管理与运维

Flink CDC 2.2 正式发布,新增 TiDB 数据源,新增 TiDB CDC 连接器

TiDB 社区干货传送门

新版本/特性发布 应用适配

TiDB 在携程 | 实时标签处理平台优化实践

TiDB 社区干货传送门

统计信息十问: 你不了解的那些事儿

TiDB 社区干货传送门

实践案例

使用TiUP 修改集群目录实践

TiDB 社区干货传送门

管理与运维

单机 8 个 NUMA node 如何玩转 TiDB - AMD EPYC 服务器上的 TiDB 集群最优部署拓扑探索

TiDB 社区干货传送门

管理与运维 性能测评 数据库架构设计

本地Kind体验TiDB Operator最小实践

TiDB 社区干货传送门

实践案例

TiDB 在连锁快餐企业丨海量交易与实时分析的应用探索

TiDB 社区干货传送门

Oceanbase和TiDB粗浅对比之 - 执行计划

TiDB 社区干货传送门

数据库架构设计 应用适配

文盘Rust -- 起手式,CLI程序

TiDB 社区干货传送门

开发语言

DM 是如何处理 DML 的

TiDB 社区干货传送门

迁移

TiKV缩容不掉如何解决?

TiDB 社区干货传送门

集群管理 故障排查/诊断 扩/缩容

代码行数是致命因素吗?_编程语言_Niclas Nilsson_InfoQ精选文章