https://coolshell.cn/articles/5201.html/comment-page-2#comment-1932554
过去半年基本上完整经历了这个文章的各个阶段,看完文章结合自己的经历,发现的确有些值得反思,但是哪怕过程太痛苦,但如果是一个自己要长期维护的模块,”至少亲生的bug更好看些吧”,如果一开始的需求就复杂,没有条理,代码第一版设计者没有充分的和需求方整理需求,盲目编码形成第一版难以维护的代码,后面的人几乎不可能根据代码还原出需求的原貌,甚至是需求方自己也很难确定自己最初的想法是什么样的,我们在重构代码的起点往往是一些难缠的bug或者新需求,因为要解决这些bug,或者实现新需求,发现原来的设计把所有路都堵死了,后来的人如果是追求完美的程序员,就会陷入这种境地,而和第一个程序员一样的人,会用更加不优雅的方式把新的代码黏在原来的代码上,直到遇到一个追求完美的程序员,或者给需求方说,这个我们做不到.原因不是技术瓶颈,而是我们做的不好,或者前人做的不好.
所以哪怕直到有这几个阶段,如果不试一下,也许永远被噩梦缠绕,如果做一下,后面最差也就是亲生了一个跛脚的框架.这过程中,对需求的把握,对未来的预期远远比一步不走要好的多.
这里的几个阶段,第五阶段是转折点,这里看你是不是一个彻底的完美主义者,如果是,时间不足的情况下,你可以选择短时间在自己底线内做些忍让,但是哪怕到了最后一个阶段,那个站起来说重构的人,我希望是我自己,我不希望”做一个重构别人代码的人”. 所以重构虽然痛苦,但是有些重构是必须进行的事情.特别是你预期到后面有大量的需求和变更的模块
当然值得反思的是,绝不做不分轻重的屠宰者,要”秉公办事”,轻急缓重要分得清,任何过度的事情都是失衡的状态,过度设计和过度重构,过度敏捷都是适得其反.
个人对重构的优先级:
1. 不稳定的地方,频繁出bug
2. 需求集中,变更频繁的地方
3. 核心模块内过时的代码
4. 核心模块内重复的代码
5. 核心模块内不清楚的代码
6. 一些无关痛痒的风格问题
办法总比问题多
