一段不为人知的历史
以前写完代码老是会被组长骂“代码丑、写得什么乱七八糟的?”
我也纳闷了,代码不都是键盘一个个敲出来的,咋还能看出丑不丑?功能实现了没有Bug不就行了?
然后组长指着我的代码会问,这个类是干啥的?那个函数是干啥的?导入的包又是干啥的。
我都会不(xin)厌(ru)其(si)烦(hui)地解释一通,然后在代码上写上注释。
「直到有一天......」
我:“这垃圾代码谁写的?注释的什么乱七八糟的!!我**”。
我继续:“这代码缩成一团是哪位人才写出来?这个套了5个if语句的函数是判断啥的?看注释也看不明白啊!”
此时有同事在角落暗笑,我以为他知道是哪位“大神”写的,便问他是否知道这些“shit code”是谁写的?
他说知道是谁,我便让他把他的名片发项目群里,我需要找他探讨下业务逻辑。
于是我的名片被发到了群里,还附上了git push上去的记录。。。
论祖传代码的形成
因为一些项目需要迭代式开发,所以初始(第一版)状态的代码的整洁度和结构是非常重要的。
就像一条大马路干干净净的,你手上握个垃圾都不好意思乱丢。
如果这条大路上路灯、绿化都整整齐齐的,我相信你作为开发也肯定会很守规矩的往上面再增加一些代码。
如果一条马路上臭气哄哄,各种规划也乱七八糟,你想往这马路上想增加个垃圾桶都发现根本没地方放(例如在五个if语句中,再增加一个判断)。
啥?你想推翻重新写?你先把那5个嵌套的if的逻辑理清楚什么关系再说吧。
如果你真的把这5个if的关系理清楚并且重构了,你就需要跟测试说需要扩大测试范围,因为你把代码重构了。
测试:***。
「一般祖传项目代码就这样慢慢成型了。」
如何避免祖传代码的形成?
❝
这个问题我跟一些资深大佬探讨过,他们几乎都表示只要项目迭代次数多,祖传代码是避免不掉的,可能只是时间问题。
❞
「虽说很难避免,但是可以“预防”。」
以下推荐几个方法,可以有效“预防”祖传代码:
- 遵循项目手册上的推荐编码规则(如果没有推荐编码规则,可以选择每个语言对应的规范手册,例如Python的PEP8规则);
- 注意代码复杂度(通过分析代码行数、循环和其他参数来检验函数的复杂度);
❝
当你在一个函数中写出第三个if的时候,就可以考虑把if语句打散,或者是使用其他的选择语句重构它。
❞