开发过程当中项目是否须要重构？又须要注意什么？

重构是须要慎重考虑的，不是拍脑子决定的事情！

1、引言

程序员都有一颗工程师的心，因此当他们到一片新的场地想作的第一件事就是，将旧的一切推倒重来。是的，他们以为旧代码异常混乱，由于读代码更难，宁愿丢掉旧代码从新写，也不肯意修修补补，他们认为旧代码简直一团糟。

我以为这个出发点是好的，但我观察了很是多的案子，那些重构的项目大多数是失败的，至关一部份都成了烂尾。他们从头开始再写一遍并不意味着会写出比之前更好的代码，由于很多人没有参与到上一个版本的建立，因此其实根本不算有经验。一旦推倒重写，可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。

2、咱们的项目是否须要重构？

对处于团队 Leader的我来讲，重构考虑的是人力、时间、项目风险等因素，在商业项目中，推倒重来是很是危险的行为,重写项目的代码也是一个异常艰难的决定。固然，若是只是在作实验，想到新算法、SDK能够随时重写。

通过慎之又慎的考虑，重构也不是不能够的，但不是一会儿推翻项目以前的全部代码，否认一切，你可能不必定会写出比之前更好的代码。结合自已的工做经验（移动端开发经验），重构主要工做从如下几个方面展开：

• 删除没用到的第三方库
• 删除不合理的第三方库，使用系统自带的或者本身造轮子
• 删除定义好可是没有用到的变量
• 删除 import 进来可是没有用到的头文件
• 删除更旧项目留下来的用不到的逻辑
• 代码的结构重构，项目工程、View、Service等层级不合理
• 代码的效率不高的重构，循环、编译速度优化
• 代码写得很丑的重构，命名不合理
• 内存泄露的重构
• 消除项目中的 warning

3、架构的重构

前面提到重构是慎之又慎的决定，这里就提到必要性，是否是自相矛盾呢？其实这并不矛盾，而是承上启下的。随着应用的不断发展，最初的架构每每面临着各类问题，好比没法知足客户的需求、没法实现应用的扩展、没法实现新的特性等等。在这种状况下，咱们如何避免一些坑，尽可能比较成功地实现架构的重构。

3.1 肯定重构的目的和必要性

每一次架构的重构都是“伤筋动骨”，就像作手术同样，即便再成功，也会伤元气，因此决策者们首先要分析架构重构的理由和其余备选方案，明确重构的目的是为了知足业务需求，而且是不得不作的最佳方案，而后再考虑其余问题。 有时候，通过分析就会发现，也许还有其余解决方案，好比增长计算资源，或者重构的目的不是为了业务需求，那就没有必要作了。检查清单：

• 架构重构的缘由是什么，是为了知足业务的须要仍是只是以为架构很差看？
• 除了架构重构以外，还有其余备选方案吗？是否都分析过这些方案的利弊？

3.2 定义“重构完成”的界限

若是肯定要重构，那么要把目标明确下来，也就是重构的边界条件，怎么才算是“完成”了重构，目标要有数据量化，或者有可以测试的办法。这也是一个需求分析的过程，若是需求不明确，那么规格说明书无法写清楚，负责重构的团队也没有明确的目标，不能以重构的时间或者主观的判断为结束的依据。检查清单：

• 重构的目标能够量化，或者说能够测试吗？
• 重构完成的标准是什么？获得业务部门或者领导的承认了吗？

3.3 渐进式重构

如今软件研发最流行的就是快速迭代、持续交付、尽早反馈。这一样能够用在架构的重构上，重构过程的难度不亚于构建一个新产品，因此在设计重构的时候，要引入持续交付的流程，每个重构步骤或者模块都要快速部署并获得反馈，以便评估重构的效果，及时做出策略调整。通过谨慎测试以后，将数据和业务迁移过去。检查清单：

• 可否把重构过程分红小的迭代，每一次改进都能尽快获得反馈？
• 重构过程当中的效果可以按期展现给业务部门或者领导吗？

3.4 肯定当前的架构状态

在启动重构以前，团队要对当前的架构状态有清晰的了解，也就是设定好基准，以便评估重构的效果。据个人观察，负责重构的架构师或者开发者，每每尚未搞清楚现有的架构设计，就开始重构了，结果常常出现这样的状况：重构到某个阶段，发现行不通，而后一拍脑壳说，哦，原来这块的架构是这个样的，是为了达到某某业务需求啊，这块不能动，得想别的办法。相似的例子在研发团队中时有发生，也提醒咱们要慎重当心。检查清单：

• 你了解当前的架构设计吗？它的设计初衷和以前的选型方案知道吗？
• 你能给架构设定一个基准状态吗？

3.5 不要忽略数据

数据的重要性不言而喻，业务都是以数据流为载体的，因此架构重构的本质就是对于数据流的重构。数据对重构的重要性主要体如今两个方面：在重构设计时，须要考虑业务数据的需求，重构以后的系统对于数据的存储、处理、分析等功能是否有影响；在重构过程当中，考虑依靠数据甚至是实际的数据来验证重构的效果，提供评估的支持。检查清单：

• 业务数据的需求在重构设计中有体现吗？
• 重构过程当中可否经过实际数据来验证效果？

3.6 管理好技术债务

技术债务在日常的软件研发过程当中也是比较突出的问题，架构重构每每是为了偿还技术债务，因此请不要在偿还技术债务的过程当中制造技术债务了。技术债务就像信用卡同样，会有很高的利息率，就如同给团队留下了大量的账务开销。组织应该培养一种保证设计质量的文化。应当鼓励重构、同时也应当鼓励持续设计以及其它有关代码质量的实践。在开发时间中应当专门抽出一部分以解决技术债务。检查清单：

• 团队对技术债务有跟踪和备忘录机制吗？仍是开发人员能够随意的产生债务？
• 针对技术债务有按期的培训、回顾机制吗？

3.7 远离那些虚荣的东西（例如使用“热门”的技术栈）

架构的重构过程应该是以目标为导向，换句话说“注重实效”。对于技术人来讲，一个常常被轻视的问题在于，喜欢追逐新鲜的热门技术，这实际上是个好事情，说明技术人敢于创新，不断接受新技术。可是对于架构的重构这样的关键性任务来讲，是否是新技术并不重要，重要的是能不能实现重构的目标。对于新技术来讲，虽然热度大，但你们踩过的坑还很少，积累的失败教训和成功经验还不够，在这种状况下，建议你们不要头脑一热就上马新技术，应该客观冷静地评估新技术和成熟技术对架构重构的影响和效果，以数据和经验来讲话，而不要追赶时髦。检查清单：

• 重构的技术选型是否有详实的数据和专家评估？
• 选用的技术是否有良好的人才积累和足够的经验支持？你是否是实验小白鼠？
• 在技术选型时，是否至少有两个方案待评估？有没有成熟的技术方案？

3.8 作好准备面对压力

软件开发过程当中，压力无处不在。对于架构重构来讲，压力来源于多个方面：管理层、团队成员、同级部门等等。说白了，架构重构对我的来讲每每是一件出力不讨好的事情。和作一个新产品可以取得很高的赞扬相比，重构的成绩每每并不受领导重视，并且出了问题还要承担很大的责任。从软件开发角度看，作新产品是从 0 到 1，而架构重构是从 -1 到 1，复杂性和难度一般更大。所以，重构的负责人要提早作好心理准备，舒缓压力的一个技巧是，设置好里程碑，将重构的成果量化，而且和业务的变化关联起来，按期向利益相关各方同步状态，获得你们的理解和支持。检查清单：

• 架构的重构是否获得了管理层（特别是最高管理层）的支持？他们是否对重构的时间、任务量有直接的认识？
• 你的重构计划中是否包含了一些能够量化的成果？是否认期向管理层展现这些成果？

3.9 了解业务

架构重构的最终目的是改进业务，因此对于业务的了解将有助于架构师和技术人肯定重构目标的优先级和关键路径。好比，咱们须要知道哪些关键业务的架构是不能碰的，哪些业务之间是互相关联的，哪些业务的架构是须要优先重构的…..等等。除了了解业务自己，咱们还须要了解“人”，表面上管理层是重构目标的裁决者，但实际上业务部门的人才是。技术人须要了解他们的业务需求，并将其转化为重构目标。经过这种方式，架构重构的意义才能获得具体的体现。检查清单：

• 是否与业务部门就架构重构所能实现的业务目标进行过充分的讨论和确认？
• 是否对关键业务和优先重构的业务进行了确认？

3.10 作好面对非技术因素的准备

无论你是否愿意相信，技术在架构重构（以及其余很关键的公司决策中）的影响因素中并非最高的，咱们还会涉及到商业利益、管理层偏好、大客户影响、团队问题等等，对于架构师和技术人来讲，这些因素每每不是他们所能掌控的。咱们能作的就是，与利益相关者设定重构目标，而后，根据不一样的影响因素，调整目标。请记住，不要死扛这个目标，当有人提出不一样的意见时，要坦诚地和他们交流，并告知他们如何采纳意见，那么重构目标会有变化，而后让其余利益相关者也知道这些变化。非技术因素的影响是客观存在的，并且从商业层面来讲也是合理的，因此对于技术人来讲要学会适应。检查清单：

• 当非技术因素影响架构的重构时，你是否对目标作了调整并告知了利益相关各方？
• 你是否准备以开放而不是抵制的心态来对待非技术因素的影响？

3.11 对于代码质量有所掌握

架构的重构对代码质量要求很高，一方面是重构过程对 Bug 的容忍性比新产品的研发更低，另外一方面也决定了下一次重构的难易程度。代码审查是一个很是好的办法。代码审查是软件开发过程当中的必要步骤，既能够帮助被审查者提到代码质量，又可让审查者加深对产品的理解。不论团队多忙，必定要保证代码提交以前，是通过其余成员审核过的，短时间来看会占用团队的时间，长期来看是事半功倍的好事。检查清单：

• 团队成员是否对代码质量有足够的重视？是否有奖惩措施？
• 团队内部是否有代码质量的标准文档和审查流程？

4、结尾

关于架构的重构，一切来源于实践中的经验是最有价值的，为技术人所用才是有意义。

最后

给你们分享一份移动架构大纲，包含了移动架构师须要掌握的全部的技术体系，你们能够对比一下本身不足或者欠缺的地方有方向的去学习提高；

须要高清架构图以及图中视频资料的能够加入个人技术交流群：1018342383私聊群主小姐姐免费获取