课后思考及问题
如果一个架构重构项目最后规划要 2 年才完成，你会怎么处理？
两年时间比较长，期间研发、测试、产品，甚至我自己都可能换环境。太不可控，如果是我，我会这么做：
第一切割任务，粒度细到可控的范围，比如：每个月应该重点解决的问题有哪些
第二给任务排个优先级，先重点搞定重要紧急的
第三人员流动的根本原因一是钱少二是不开心，如果给不了钱要让大家开心点，工作氛围要轻松愉快点，节奏上要有张有驰
第四做好监控，有些任务如果延期，需要及时调整任务安排
第五任务安排到合适的人员，这个很关键，发挥每个人的长处，调动大家的积极性，千万不要明显的厚此薄彼，比如：说页面不重要没价值，后端逻辑才是核心，做页面的没啥价值，把人分成得力的和不得力的，当然，领导都会这么分吧!但可以不说出来，想开除谁等开除时再说，不要告诉其他同事，这样会严重影响士气，让人想写不易维护的代码，自己发现bug也不想解决。

看评论2年周期重构不如重写，重构我的理解是要重写的只是原来的业务要覆盖，自己的代码逻辑变化是对研发来说的，对于业务是解决了他们的问题原来的业务继续支持😁

本文核心观点
1-1：将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题

如果时间预期为两年，这明显已经超出正常重构时间范围了。

我认为首先应该回头审视一下，重构涉及的范围是否过大，是否可以先集中重构最核心最重要的系统。

其次就是再确认一下，重构的方案是否有问题，是否可以舍弃一些细节上的优化以节约大量时间。

如果工作量确实有这么大，而且耦合太厉害无法拆得过细，那只能考虑直接重写了