复杂的业务变更，前端如何维护代码

在业务需求变化比较大的项目中，我们必须考虑代码版本的问题，甚至是不能只听产品或者后端的一些片面之语。没有一成不变的需求。
刚接手项目的时候，开发的是关于金额计算和展示以及优惠券使用的项目，开始的需求甚至包含一些金额随意调大小的功能，在项目经过几个人轮番接手之后，到我手里已经积累了很多不可控因素，很多话暂时放进肚子里，开始谈代码的套路。
很多时候大家都一个感觉就是修改别人的代码不如重构！！！就是这个感觉。
开始的时候项目为什么这样写，你问别人，别人也会说接手过来就是这样的，后面的业务就这样的基础上陆续展开，你中间写着会觉得很累，因为在考虑很多东西之后，这些东西并不能实施，只能将计就计。这里就有一个很深的感悟，别人总说接手的时候代码就是这样的，我就在想这中间阅读代码的过程，以及修改一部分业务之后，代码的布局应该慢慢向自己的风格靠拢，我们不做代码的搬运工，要做一个善于思考的开发者！！！
一个复杂的业务变更过来，需求说之前做的A功能先砍掉，目前不符合客户要求，后端说建议保留代码，后期有可能要。前端左右思考，保留！！
于是代码越积越多，把文件撑满了。
其实，砍掉的功能和不用的代码就像是一段无爱的感情，当断即断，才是最适合的手法。以免后面的难受，拖拖沓沓，影响人生的风景。
在业务变化的过程中，会出现一个很致命的问题，就是逻辑性。产品的逻辑性，业务的逻辑性，貌似都没有了。每次写完一块新的需求，我都会去想这个产品的发展方向，和产品的风格去向，很难思考的全面，虽然思考的深度也不够，但渐渐发现一些砍掉的功能是缺乏逻辑性的，而用户体验很重要的一个方面就是产品要有逻辑性。
其实这个逻辑性就是产品的保障吧。
说到这里，就说前端如何维护代码。拿到需求变更，首先考虑代码的全局，整个业务你的代码是怎么的逻辑，要每次都看几遍，因为业务的逻辑性不强，最终会导致很多无用代码的产生，所以，有时候要改善代码逻辑性方面。
还有就是要及时跟后端进行数据的选择处理，比如说，数据嵌套太深。对于取数据和塞数据的逻辑就会变得复杂而无用。
这一切的进行都需要一定的支撑，没办法的事情，谁也办不到。