实在忍不住了,接手的代码太 shi 了

2019-03-15 15:56:27 +08:00
 zycpp
语言 C++

0、变量命名随意,驼峰、下划线混用。
1、函数、变量没注释,意思全靠猜
2、单个函数极长,四五百行的函数随处可见。
3、c style 和 c++ style 混用
4、源文件编码混乱,有 u8,u8+bom,gbk 都有
5、代码冗余,一样功能的函数重复实现好几次,只是换了个名字…
6、不明意义的数字满天飞,你猜我这里的 128 跟那边的 128 是不是同一个意思?

溜了溜了
8716 次点击
所在节点    程序员
60 条回复
zwy100e72
2019-03-16 01:07:39 +08:00
有耐心留下来重构,没想法换地方也行
我这边有个 4k 行的 if 了解一下
DesertCamel
2019-03-16 01:33:16 +08:00
楼主,我跟你的情况一模一样。刚进公司,java 后端,发现接手的代码太烂,而且有一部分烂的就是上级写的。代码随便拷贝,混乱的耦合。第一想法是溜之大吉,但目前福利给到位了,外面也很冷,还在观望,并一步步整理重构
lvxiang119
2019-03-16 09:13:11 +08:00
以前接受一个项目,入口文件 3000+行,优化到 500 行。最后发现无法运行,于是移除了该模块。求夸。
Moming
2019-03-16 09:27:09 +08:00
我也遇到了,第一次强忍着改了点交差了,第二次还给我这种任务我就直接不干了,看着脑壳疼。。。
uyhyygyug1234
2019-03-16 10:31:45 +08:00
那你是没看过丰田的

软件设计的基本要求是模块尽量简单化,因为这样可以一来更易于阅读二来更易于维护。但丰田的工程师显然没有遵循这原则。Barr 使用一种工具自动根据代码的可能分支数量评估函数的复杂度,结果是丰田的软件中至少有 67 条函数复杂度超过 50,意味着运行这个函数可能出现超过 50 种不同的执行结果,属于“非可测”级别。因为为了测试这 50 个不同的结果,必须准备至少 50 条不同的测试用例以及相应的文档,在生产环境中一般是不现实的。作为比较,Barr 表示他自己的公司严格执行的其中一条规定就是任何代码复杂度不能超过 30,否则不合格。而在这 67 条函数中还有 12 条复杂度超过 100,达到“非可维护”级别,意味着一旦发现缺陷( Bug )也无法修复,因为实在太复杂,修复缺陷的过程中会产生新的缺陷。其中最复杂的一条函数有超过 1300 行代码,146 个可能执行路径——正好用于根据各传感器数值计算节气门开关角度

还有一些别的匪夷所思的发现。比如丰田的软件包含了超过一万一千个全局变量。如果你不知道什么是全局变量,那么只需要知道软件设计的一般原则是要尽量少使用全局变量,因为有可能带来无法预测的结果。这里的“少”的意思是“尽量接近零”,绝对不会是一万一千个。
suzic
2019-03-16 10:52:07 +08:00
0,1,2,5 我接手的项目也存在…
srt180
2019-03-16 11:03:15 +08:00
没有代码审查环节吧……做个代码审查,慢慢改起来……
heber2211
2019-03-16 11:09:10 +08:00
你大概没有见过把入参反复从 map 里取出来放到 list
ymj123
2019-03-16 11:32:58 +08:00
你列的这些还好吧。主要是业务逻辑清不清晰,我以前接手的项目,你说的这些全有,并且还是 shell+Java+Python+groovy 的。业务也复杂。出差去客户那里搞了一个月勉强吃透。
loryyang
2019-03-16 11:39:10 +08:00
最好的处理办法就是:新需求就膏药贴起来,然后代码质量可以成为各种线上问题、开发效率的无赖挡箭牌
然后长远就是:开辟新战场,把垃圾交给后来人
dearxe2v
2019-03-16 13:56:12 +08:00
根本原因,钱到位了,si 也是香的
turi
2019-03-16 14:17:29 +08:00
溜了 才是正道,吃屎是人吃的吗
GeruzoniAnsasu
2019-03-16 14:52:26 +08:00
其实太正常了,会有这样的代码仅仅是因为维护周期太长了而已,并没有什么真的很屎的地方

风格不统一大不了全 refactor->rename 成顺眼的,别改了一半算了够了不改了就行——上一个人可能就这么想的

C/C++混用 也太正常了,项目开始之初一半都会想着“啊 C++运行库太臃肿了我们 pure C 吧”然后几个版本之后“啊 C 写起来太慢了移植到 C++吧反正性能不会掉多少”,然后前面那些 C style 的代码还工作得好好的没必要改就留着了

单函数长有些是没办法,特别是 IO 操作,各种移位拆结构拼指令读写协议字段,或者涉及复杂状态转移而当初又没好好设计状态机模型的,都会变得又长又看不懂,其实个人觉得箭头形 for if for if 都算很好看的了,起码逻辑还是很清晰的,嵌套得再深也说不上复杂,模式是很单一的。那种 reinterpret<uint8_t>(data << 3 | data2>>5&0x3)+(cmd<<16)什么的才比较令人崩溃

编码混用完全不是问题,甚至源码仓库进去出来就能统一的事,觉得这个是问题倒是暴露了整体水平



个人觉得就可读性程度来说最难入手的就是上面说的迷之协议的 IO
bug 可维护程度来说最难的是各种原始无高级封装的多线程代码,那个调起来,最高目标很可能是“两个小时之内不会崩”
SyncWorld
2019-03-16 15:20:12 +08:00
不要说代码 shi 有可能你们的老板和我老板一样 早上定需求 中午出 UI 晚上功能上线呢~~~ 同行理解下
wd
2019-03-16 16:36:39 +08:00
先别急骂人 自己想想为什么会进这样的公司 是不是自己也不行
vevlins
2019-03-16 17:00:37 +08:00
@timetolo 五百行组件 38 个 if,一边抓头发一边写
Fisonglin
2019-03-16 17:10:48 +08:00
随手看了一眼,函数就有 3000 行,二十多年的老项目没办法啊
conwey
2019-03-16 21:12:24 +08:00
@mokain 好巧,前面那哥们也是重构的。
alikesi
2019-03-16 22:12:48 +08:00
@SyncWorld 头皮发麻
TingHaiJamiE
2019-03-18 08:39:26 +08:00
@harde 话糙的有点厉害...

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/545011

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX