如何重构一系统
如何重构一系统
我发现了一个很有意思的情况。编写代码,使户籍制度改革,基本满足现有系统实现的需求,从无到有系统,以达到基本。
1 why
不管是从头是实现一个系统。还是维护一个系统,当时实现的技术可能是最先进的、规划的产品逻辑是合理的,随着时间的发展、开发者的变更、系统的代码质量会逐渐腐化,加个Feature太麻烦。改个Bug涉及模块太多-没有单測不敢随便解,业务方抱怨技术团队响应太慢。
是时候重构系统了。
对于技术团队来说,重构能力影响着系统对业务团队的响应速度。非常多职位招聘的时候都要求:
● 对已有系统进行重构和优化。
● 对组件的重用、重构有丰富的经验;
● 可以熟练运用各种重构方法;
● 察觉实现问题。提出改进(重构)方案;
● 对框架本身的体系有较为深厚的理解和应用经验,对框架本身有过开发或重构者可优先考虑
……拥有重构能力的技术人员在个人价值方面也有非常大的竞争力(^o^)/~
2 how
重构系统的时候。技术人员应该考虑对遗留代码、第三方代码、开源码、最新技术的合理利用。全然从零開始,在时间上、业务复杂度上都是不同意的。
依据个人开发经验。我觉得应该将重构分为:代码重构、模块重构、架构重构3个不同的类型。
代码重构:这个也系统业务关系比較少,很多其它的是优秀编码规则的遵循和实现。比如:统一的错误异常抛出和处理方案,易于理解的返回值模型,统一的入參验证规则。基于设计模式6大原则的编码,单測用例的补全和维护。这样的类型的重构更易实现。而且对现有业务员逻辑的没有影响。
模块重构:技术团队既要满足日常的需求开发,同一时候也要做到原有代码的重构。开发资源肯定是不够用的,比較可靠的方案是在选定一个和新需求相关的、而且和其它业务模块耦合度比較低的业务模块进行重构。又一次梳理业务流程和技术实现方案,这部分重构的实现依赖于代码重构,良好的编码规范和代码质量是基石。对相关业务的熟悉度则是骨架。整个流程一直迭代下去完毕整个系统的全部的模块的重构,这个过程中须要技术团队基于代码入手,从代码级思维跳到设计级思维,抽象出当前的设计模型。考虑适应各种场景带来的可扩展性、可维护性的压力了。
架构重构:这个是重量级的重构。假设按部就班的由代码重构->模块重构,前2个做好后,架构重构就非常自然非常easy的实现了:识别各种共用业务模块,抽取作为各种服务的基础。
假设一開始就又一次来做,当前业务需求要暂停,同一时候技术团队的开发压力非常大。须要大量的加班来降低对业务响应的阻碍。
參考:http://www.programmer.com.cn/4555/
版权声明:本文博客原创文章,博客,未经同意,不得转载。