设计|代码和设计是如何一步步腐化的( 二 )


你有可能说 , 新人不是应该有个导师吗 , 导师得review新人的代码啊 。 首先 , 导师得懂这一块业务;其次 , 导师得愿意花时间指导新人 。 指导新人是否影响导师的KPI呢?带好了是否有奖 , 出问题了是否有惩?如果全凭导师自律 , 这个不确定性就太大了 。
上面提到的是新人 , 其实老手也可能写出“德不配位”的代码 , 比如一个需求 , 可能涉及到多个模块 , 有的模块是这个老手负责的 , 有的则不是 。
理想的情况下 , 各个模块提供好接口供老手调用即可 , 但某个模块的负责人很忙 , 没有时间 , 这个时候老手就会直接去修改相应模块 。
可是 , 可能由于老手特有的自尊、或者面子 , 老手往往不愿意去请教对应模块的负责人 , 而是按照自己的经验魔改出一段可以工作 , 但既不优雅、也不高效的代码 。
代码如何加速腐烂
所以说 , 由于进度压力、经验、态度等各种各样的原因 , 代码中慢慢就会开始出现腐朽的问题 。
可怕的是 , 垃圾的代码给出了错误的示范 , 这种示范对于新手或者对于这个模块不熟悉的同事来说都很强烈 , 也使得垃圾的代码、倍增的维护成本、潜在的bug被到处复制 , 美其名曰“借鉴” 。
破窗效应 , 让后来人写出垃圾代码的时候毫无心理负担 , “以前就是这个样子的” , 以前这里有个变量叫temp , 我只是加了个变量叫temp1;以前这里就有switch case , 我只不过加了一个case;以前的代码就很难读懂了 , 于是我copy的一份实现自己的逻辑 。
况且 , 到项目后期 , 可能不再那么挣钱了 , 可能最初写代码、制定规范的人已经不再了 , 谁还会来关心这代码质量呢?
悲观的认为 , 代码的腐化是必要 , 只是时间快慢问题 。


推荐阅读