智能体刷屏的背后,是 AI 应用拐点的来临?AICon 北京站议程重磅公布,50+ 硬核分享不容错过 了解详情
写点什么

代码行数是致命因素吗?

  • 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:581653
用户头像

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

关注

评论

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

地方政府争夺数字货币试点,互联网巨头参与测试,央行数字货币即将来临

CECBC

行业资讯 央行数字货币

week9作业1

一文带你掌握OBS的两种常见的鉴权方式

华为云开发者联盟

Rest OBS 鉴权 Header携带签名 URL携带签名

埋点全解析,你最关心的可视化埋点在这里!(文末附开源地址)

易观大数据

week09 总结

Z冰红茶

奈学:一起了解几种序列化协议

古月木易

序列化 序列化协议

阿里最“短命”的P10?入职不到3周,钉钉副总裁张志琦因个人原因离职

程序员生活志

阿里巴巴 互联网热点

架构师训练营第8周作业

Hanson

架构师0期Week9作业1

Nan Jiang

加快速度推进区块链融合发展

CECBC

区块链 行业资讯 产业落地

为什么你总觉得自己是对的?

池建强

个人成长

cxuan读者的外包面试之旅

苹果看辽宁体育

Java 面试 程序人生

架构师训练营第九章作业

吴吴

白鹭引擎助力《梦幻西游网页版》刷新h5游戏新高度

DT极客

架构师训练营第8周总结

Hanson

JVM类加载与执行

superman

JVM 类加载

凭实力蝉联第一!Flink 又双叒叕上榜啦

Apache Flink

flink

开源、云、传统IT的三国杀

郭华

云计算 开源 商业 IT

最右JS2Flutter框架——通信机制(三)

刘剑

flutter 大前端 探索与实践

vivo,此去灵台方寸山

脑极体

【得物技术】流量之战—性能优化三十六计

得物技术

Java 流量 得物技术部 商品 电商平台

垃圾回收&秒杀设计

dony.zhang

垃圾回收

不仅性能秒杀Hadoop,现在连分布式集群功能也开源了

爱倒腾的程序员

大数据 涛思数据 tdengine 物联网 时序数据库

设计一个秒杀系统挑战和问题及方案或思路

Young

零/低代码编程风口已到,请快快上车!

代码制造者

编程语言 低代码 零代码 iVX

总结

Kiroro

第九周.命题作业-GC原理

刘璐

数据库实践丨MySQL多表join分析

华为云开发者联盟

MySQL 数据库 华为云 join 多表join

高教授:区块链软硬件相结合能提升系统性能 也能保持一定的灵活性

CECBC

分布式 行业资讯 区块链技术 落地应用

秒杀系统

Z冰红茶

作业一

Kiroro

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