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