架构师学习12条军规读后感

确认重构的目的

副标题应该叫： 重构的必要性。
确认说重构的目的，是不是只是为了满足当初前框架不可满足的需求矛盾。如果是框架限制导致当前业务不得不进行重构的时候，重构才是合理的。
初次之外，还应该考虑重构的其他可能性，是否可以通过扩展硬件和计算资源能够得到满足。

确认重构的边界

只有确认了边界，要达到的指标，才能了解做手术的程度。才能与管理者，规划者才成一致的共识。

重构要保持渐进性

快速迭代、持续交付、尽早反馈。要不断地有里程碑式的完成，这样才能给架构带来进展，给别人带来信心

了解的当前的架构

只有知道了当前的实现， 才能知道为什么是当前这样，是为了满足什么需求。 否则，很容易导致新的架构发现无法实现某个需求。

不要忽略数据

要确认重构后的架构是否导致数据的存储，处理分析发生了变化。 如果是数据流发生了变化，是变坏了还是变好了。
例如，你不能因为重构了系统，导致当前系统的性能严重降低，者肯定是不能够容忍的。

管理好技术债务

写好代码，否则代码的Bug, 会引入越来越多的改动。

管理好技术栈

热门的技术不一定是最好的。 要关注目标导向。 新技术意味着未知的坑，未知的风险。不一定有成熟的技术方案。

关注业务

架构重构的最终目的是改进业务，所以对于业务的了解将有助于架构师和技术人确定重构目标的优先级和关键路径

做好面对非技术问题的准备

技术架构在重构中并非是最重要的。 有时候商业利益才是最重要的。
涉及到商业利益、管理层偏好、大客户影响、办公室 zhengzhi、站队问题等等，对于架构师和技术人来说，这些因素往往不是他们所能掌控的。我们能做的就是，与利益相关者设定重构目标，然后，根据不同的影响因素，调整目标。请记住，不要死扛这个目标，当有人提出不同的意见时，要坦诚地和他们交流，并告知他们如何采纳意见，那么重构目标会有变化，然后让其他利益相关者也知道这些变化。非技术因素的影响是客观存在的，而且从商业层面来说也是合理的，所以对于技术人来说要学会适应。

对代码质量把控

让团队做好准备

重构设计到很多人，设计到方方面面， 所以是典型的木桶效应。 可能会因为某一个短板导致整个重构目标难以实现或者推迟实现。