计科专业从事软件开发多年，项目中的代码重构也是经常性发生的事情，一旦项目要进行重构就意味着很多代码框架上做出调整优化了，所以业务代码很难保证一点不动，对于国内很多项目来讲重构不是很多，毕竟大家都在忙着应用级的开发，很多企业应用级的开发由于开始阶段在追求的进度对于质量要求不是很高，结果还在此基础上不断的堆积功能，最后性能很差被迫项目重构了，发生这种案例很多小型的互联网公司经常发生的，一旦重构任何的代码都不可能一成不变了。
从技术的角度来讲，优秀的产品都是千锤百炼出来的，这其中就包括有对模块的重构或者整体框架的重构的过程，对于一个软件研发人员来讲重构自己代码属于一种职业习惯，很少有人能够把代码直接一次性到位的，不自觉地重构代码也是优秀程序员必备的素质，经常在开源社区耍的人可以了解到开源社区代码变更非常迅速，代码的更新很大一部分其实不是新功能的增加主要是对于代码点点滴滴的优化，传统的软件行业基本上习惯于普通的员工的代码交给主管去审核，审核通过了就可以提交到代码仓库里面去了，国外很多优秀的软件公司习惯于同事之间互相审核代码，如果你的代码能够成功说服你的同事就可以提交到代码仓库中。
优秀的程序员认为代码质量就是自己的脸面，所以会不断的提升自己代码的质量，所以不停的重构代码结构，一直修改到自己满意为主，所以开源开源的社区更新的速度让人发指，而且一旦修改不成功会立即换成别的方案，对于模块的重构都是这个样子更何况整体的框架的调整，程序员 的对于代码都有折腾的心思，就想尽一切的办法让自己写的东西做到最优化。题目中涉及到的业务代码其实就是功能需求表，这种属于具体的业务代码部分，这块在项目中就是具备代码实现部分，框架调整一般是支撑各种模块的框架，但是在调整过程中业务代码一般尽量不去修改，但是调整过多难免会涉及到业务方面的代码。
对于初级的程序员来讲可能对于代码的修改都包含着一种畏惧的心情，编程的代码都是项目中的工具而已，初学者可能就是对于工具如何使用需要一定时间的磨练。其实在项目重构的过程中是否要动到业务代码关键还是框架设计者如何进行设计了，一般来讲重构的点最好不要涉及到具体的业务模块但是如果业务代码实在是差劲，难免涉及到需要重新写了，这在软件开发过程中也是非常常见的事情了。
编程由于涉及到的代码细节非常多，所以容易造成模块或者框架存在一定小问题，从项目开始就在不停的修修补补中，而且在修补中发现问题解决问题，在问题中强化自己的代码健壮性，解决问题多了也会形成有效的编程经验，慢慢积累出来的经验都会增加程序员的自信，经历的越多程序员的经验越是丰富，希望能帮到你。