下面就来讲讲，通过这次重构，我自己总结到的一些事情。
主要就在于这三个关键原因：
有些公司在刚成立，或者刚开始启动一条业务线的时候，业务和产品缺乏体系化的规划，为了尽快投入市场，追求快速、简单、高效的落地，经常在收到一个客户需求的时候只是简单判断就开始设计并开发落地。
诚然，快速高效地做好并交付产品，不仅是解决了当前客户需要解决的问题，也是为了顺应业务将利益放大化，较为灵活。
但是这样做也会有非常明显的坏处。一是交付的产品只能解决客户现有的需求；另外则是限制了你身为产品经理业务能力的提高，因为前期产品设计调研过程如果过于快速，你就缺乏对产品深入的思考，甚至不会考虑产品的未来将要如何发展，长此以往就会造成你在行业上的短视。
而如果为了追求速度，没有在前期做好充足的准备，导致产品缺少足够的可扩展性，当用户需求在未来升级的时候，现在的底层设计就没有办法跟上业务的发展，最终导致重构的出现。
就好比最初的时候，客户找你建一个房子，你经过简单分析，认为小平房可以满足客户现在的需求，于是你只打了一个适合小平房的浅地基。后来客户的需求增大，小平房已经不能满足使用了，要往上盖成摩天大楼，可是你的地基承载不了大楼，那你只能推倒小平房重新打地基了。
尽管我们无法确定未来的业务会有什么样的发展，无法通过解决这个问题完全避免重构，但是我们还是可以在这上面减少一些重构的可能性，而这只需要我们在前期判断业务未来发展的时候，合理增加设计的一部分可拓展性。
举个例子，一个完整的营销活动会涉及商品的选择，参加人员的选择、规则的设置、奖品的设置以及投放渠道的设置。
刚开始为了尽快将活动上线，可能会简化很多流程，采用对用户对开发来说都简单便捷的方法，比如将创建活动页直接集成以上的选择和设置，一步到位创建活动。
但在后来活动场景增加了，也许是商品的选择需要增加规格选择项，也许是投放渠道要增加，也许是参加会员要增加分类，也许是活动规则有变动……
而原本的方案并不支持这些拓展，只好推翻重构解决这些问题，这就产生了巨大的迭代成本。
产品功能设计有问题，是重构原因中比较多出现的情况。
就比如我们开发一个购物APP的商品列表页，想让不同会员等级的客户在浏览商品列表页的时候，看到对应当前会员等级能享受到的会员价格。
然而为了实现这个功能，我们可能需要请求多个接口，但多个接口参与进来之后，程序运行的工作量就变大了，这样的后果就是页面加载变慢，很大程度上影响了用户体验，即使做了几次优化也没有明显的改善。
虽然我们满足了用户需求，但是却降低了用户体验，这样的产品功能设计是有问题的。
最终为了彻底解决这个问题，我们只能推翻了先前的设计，彻底重构这个部分。
虽然这只是一个页面，但也算一个小重构了。如果在其他更大体量的产品中，那么重构的成本也就增大了。
当然了，并不是所有的重构都是产品层面的重构，有相当一部分的重构，其实发生在技术层面，也就是说，在技术架构部分出现了问题。
总的来说，几乎每家公司都会遇到上面的这三大类问题，而这种问题也不仅仅会出现在产品上，更多时候，它们会存在于管理上。
对于SAAS产品来说，如果在开发设计前没有做好充分的准备，对业务了解不充足，制定的策略不合理，那重构的可能性就极大，重构的代价更是难以预估。因为要做一次全站重构，是一个大体量、高难度、系统化的活。
之所以有些公司有些业务让人感觉一直在重构，很大的原因是因为每次重构完后没过多久又不能满足新的业务需求了，为了发展只能再重构。
既然重构有这么多坑，那作为重构的掌舵人，如何尽可能的避免这些坑，将全站系统重构规划好呢？
那就要在前期的准备工作中做好充足的市场调研和业务分析了。
在重构之前，你一定要先去深入的了解你所做的行业、市场，以及自己公司的业务，对大方向有一个概念。接着要了解准备做的产品，还有竞品的情况。
对这些有充足的了解之后，可以根据下面几个问题思考：
这个变化决定了产品的架构，也就从根本上决定了重构的策略。
和客户进行实际接触和深入沟通，并观察客户在工作中的情况，深入了解用户的需求，包括客户对所在行业的看法以及他们自身在未来有什么样的发展计划。
并找出以下问题的答案：
尽管我们没有办法完全避免重构的可能性，但我们可以在开发前多思考多做准备多和客户沟通，减少不必要的重构。
而当重构无法避免时，我们也要做好重构前的各项准备，让每一次的重构都是有意义有价值的。
作者：氟西汀，比二会更帅一点的男人，公众号：氟西汀终究还是没了。