这个深有体会,说来都是泪啊,我想大部分程序员一想到的就是重构,个人认为应该从两个团体去分析看待
新员工团体
新员工属于积极又弱势的群体,刚进公司,往往急于表现自己却又对业务和工程不熟悉,只能依托项目文档和老员工口头相授.而文档对于大部分公司是不存在.面对低内聚高耦合的代码,,你只能祈求它不出bug,否则能分分钟让你心律不齐,开始有了更新简历的念头;这时候可以求助于老员工帮你解决遗留代码的bug,因为大部分就是这些人写出来的代码 - -! .这完全取决于老员工的人品和心情.这时候的内心一般是这样的: 我要重构,我要解耦 → 业务不熟,重构困难 → 艰难重构,bug变多 → 产品,测试抱怨,为什么bug越改越多,能力受到质疑 → %>_<% 吃力不讨好,从重构到放弃.
老员工团体
老员工团体对业务和代码已经非常熟悉,有了一定层度上的惰性,主动寻求重构的毕竟不多,对待低内聚高耦合的代码已经不会产生排斥感,甚至成为了遗留代码的坚定守护者:代码long long ago已经是这样的,我也不知道为什么,修修补补就好了,反正能运行,干嘛要重构,到时候出问题谁负责...
总结
对待低内聚高耦合的代码,无非两种:重构或微调.
重构治本,但需要一段时间收敛bug,这就需要项目带头人评估工时,权衡利弊,带起团队开始重构,并对内对外扛起责任.
微调,如果重构的成本和代价太大,微调也是可以接受的,毕竟产品上线,正常运行优先级级比较大.至于代码不好改什么的,恶心恶心就习惯了,who care...
