@
willerce 我不知道耶 ... 因为没在 PM 主导的团队里做过技术一把手就不好胡说了 ...
其实我仅仅是一只流浪狗 ... 恰好在这边被收留做了管理而已 ...
大概设想了一下 ... 应该是先完成需求 ... 哪怕实现丑哪怕维护不便也要先完成需求 ...
需求的完成过程也可以给你的重构一些灵感 ... 等到有时间再下手重构 ...
毕竟重构这种事情在 PM 主导的公司里只能自己闲下来偷偷做 ...
你没办法说我这一周不接需求我要重构 ... 对方不会了解重构的意义也不需要去了解 ...
他只会觉得你是想偷懒这样 ...
@
GTim Refactoring 这个事情是一把双刃剑 ...
每次重构之前都要想好我这次重构是为了解决什么问题 ... 不能说单纯为了重构而重构 ...
这是给自己找麻烦 ... 一个会经历几十次大重构的项目一定是个混乱的项目 ...
你要重视每一次的重构 ... 毕竟这不是闹着玩的事情 ...
在重构过程中不仅要后顾之前已经存在在的问题 ... 而且需要前瞻未来可能出现的问题 ...
一旦开始就要认真做好新架构的设计 ... 并且认真去看每个参与重构的人的代码 ...
架构设计当然不会一次到位 ... 但一个好的架构一定比一个粗糙的架构撑得更久 ...
并且考虑得越全面 ... 之后的重构就越省心 ...
如果你会有万劫不复的感觉 ... 一定是之前做得就有问题这样 ...