报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

代码行数是致命因素吗?

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

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

关注

评论

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

区块链赋能供应链金融|应用优势与四类常见模式

CECBC

区块链

关于编码

西贝

Java 编码

mongodb源码实现、调优、最佳实践系列-Mongodb网络模块源码实现及性能调优(一)

杨亚洲(专注MongoDB及高性能中间件)

MySQL mongodb 中间件 架构师 分布式数据库mongodb

epoll服务器解析

菜鸟小sailor 🐕

终于,SM2国密算法被Linux内核社区接受了!

阿里云基础软件团队

架构师训练营第2期-第一周-学习总结

井中人

听说你会缓存?

架构师修行之路

redis 缓存 微服务

一文读懂线程池的工作原理(故事白话文)

捡田螺的小男孩

Java 面试 线程池 线程池工作原理

容器化应用系统上生产的最佳实践

东风微鸣

Kubernetes 最佳实践 生产

商用密码与区块链共推数字经济发展

CECBC

网络安全 数字经济

容器开发运维人员的Linux操作机配置优化建议

东风微鸣

Kubernetes 最佳实践 k8s入门

socket编程

菜鸟小sailor 🐕

websocket

小熊派开发实践丨漫谈LiteOS之传感器移植

华为云开发者联盟

开发 IoT stm32

大明湖畔昇腾绽放,趵突泉里智能奔涌

脑极体

Vidyo产品给用户方带来了什么直接的便利

dwqcmo

音视频 集成架构 解决方案 智能硬件

数据安全无小事:揭秘华为云GaussDB(openGauss)全密态数据库

华为云开发者联盟

安全 数据 加密

一致性 hash

garlic

极客大学架构师训练营

微服务的理想与现实

京东科技开发者

云原生

Java中的String到底占用多大的内存空间?你所了解的可能都是错误的!!

冰河

Java 内存泄露 string 性能调优 内存溢出

谁说AI看不懂视频?

华为云开发者联盟

视频 剪辑

为什么Java容器推荐使用ExitOnOutOfMemoryError而非HeapDumpOnOutOfMemoryError?

东风微鸣

Kubernetes 最佳实践 jvm调优

Java中String占用空间的评估标准

陈德伟

Java jdk 源码剖析

如何基于消息中间件实现分布式事务?我想说的都在这儿了!!

冰河

分布式事务 微服务 分布式数据库 数据一致性 海量数据

设计数据库集群读写分离并非易事

架构师修行之路

分布式 微服务

如果只推荐一本 Python 书,我要 Pick 它!

Python猫

Python 学习 编程 程序员 码农

在K8S Volume中使用 subPath

东风微鸣

Kubernetes 最佳实践

食堂就餐卡系统设计

Griffenliu

架构师训练营第 2 期第一周作业

井中人

二十一、深入Python强大的装饰器

刘润森

Python

Week 4命题作业

balsamspear

极客大学架构师训练营

Week 4学习总结

balsamspear

极客大学架构师训练营

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