进行任何软件开发的时候，出于时间效率和成本效率，都不可避免地会忽略一些暂时无法考虑到的细节。
随着时间的积累，这些小细节的问题也逐步积累，逐步暴露出大问题，这时候，可能就有人会提出「重构」软件，我这里的说的「重构」，主要指彻底地将原有的版本推翻，重新做一套软件，在外部表现为软件最大版本号的迭代。
任何架构都不可能完美，其底层设计必然会有一些没有考虑周全的地方，重构软件确实能解决问题，但是其付出的成本代价真正是否值得，是需要反复考虑和思量的。
首先，提出重构软件的往往是研发部门，研发部门的KPI往往是迭代交付周期、内部缺陷率、版本质量等等，研发部门做啥都是做，只要保证上述KPI就能交差。但是产品部门的KPI就不同了，产品部门的KPI往往满足客户需求，尤其是满足客户的价值类需求，但是对给用户交付的产品的底层代码逻辑并不是很关心。
由于研发部门的KPI与产品部门的KPI的不同，导致了两个部门的心可能并不往一处使，对于绝大部分产研团队来讲，产品部门要比研发部门强势一点，研发部门让步于产品部门，毕竟满足客户需求才是最重要的，否则哪里获得利润来养整个团队呀。
有些研发部门强势或者研发经理强势的地方，甚至把重构软件当作自己的核心任务，恨不得五年做三次重构，毕竟只有重构软件才能显示出自己或自己部门的架构能力来么，不重构软件哪来的那么多底层架构去设计。我觉得这种思想完全是本末导致，是一种十分自私的行为，完全没有为客户着想。
其次，重构软件并不是只有好处，没有坏处。重构软件的好处在于，从底层架构上考虑了更多的用户使用需求的框架。但是坏处也是十分明显的，比如产品部门几乎需要把之前所有的大的、小的需求全都重新分析一遍，再加上产品迭代的过程，这势必会占用很长一段时间去做「老需求」，尤其是那些对需求管理越来越严格的企业，要求对「老需求」进行「新分析」，产品人员的时间和精力会被大量占据。
所以重构软件往往导致对外的产品版本在很长一段时间内，无法进行有效的或者明显的更新。尤其对B端产品来讲，用户的需求本来就无限，长时间的不更新，就可能导致用户对软件的信心下降、好感降低，甚至放弃使用。
另外，有需求就会有优先级，在对「老需求」进行「新分析」时，不可避免地会去调研和分析某个功能点的使用率，一些不负责的产品人员或者负责但能力有限的产品人员，会在新版本迭代中，将某些老版本中的功能优先级调低，甚至直接去掉。尤其对于B端软件，我仍然还是持有和有赞创始人兼CEO的观点：不建议因为某一功能使用率太小而删除（参考文末引用资料）。
这是说到负责但能力有限，这是略有些「悲哀」的说法，产品经理虽然号称是「经理」，但是只是操着「经理」的心，担着「经理」的责，但并没有「经理」的权，无法去调动相应的资源。
最后，回到今天的主题：若无十分必要，请勿重构软件。既然研发部门提出了重构软件的想法，那一定罗列诸多重构软件的必要性，但是这些必要性真的是十分必要吗？还是只有九分必要，是的，我用的是「九分」必要，即使是九分必要，也应该暂时搁置重构软件的计划，因为重构软件会导致软件的版本迭代陷入停滞。
对于「十分必要」的定义，我觉得有以下几个指标：
如果不重构软件，将影响未来50%以上的价值需求的研发效率
如果重构软件，将使未来所有的研发工作效率提升一倍以上（研发工日降低一半以上）
重构软件导致的人力资源成本可以在重构软件后一年内收回
重构软件导致的版本停滞对产品的商誉损失在20%以下
重构软件要保持原有软件95%以上的功能
只有同时达到了上述的全部指标，我认为才真正达到了「十分必要」的程度，这时候才可以「谨慎地」去开展重构工作。
【延伸阅读】白鸦内部培训：企业服务类产品的底层逻辑，和“有赞产品设计原则”
题图：Photo by Nathan Dumlao on Unsplash
