Reconstruction needs careful consideration, I decided not to shoot the brain matter!
I. Introduction
Engineers, programmers have a heart, so when they go to a new venue wanted the first thing is, all the old reinvent the wheel. Yes, they think the old code in chaos, because the code harder to read, preferring to throw away old code re-write, do not want to tinker, they think the old code is a mess.
I think this is a good starting point, but a lot of cases I have observed, most of the reconstruction projects that failed, have become a considerable part unfinished. They write again from scratch does not mean that will write better code than before, because a lot of people not involved in the previous version of creation, it actually did not have experience. Once down rewritten, it might repeat it again committed a wrong version, or even create more new problems.
Second, we need to reconstruct the project?
Team Leader for me in terms of reconstruction to consider is manpower, time, project risk and other factors, in commercial projects, to reinvent the wheel is very dangerous behavior, rewrite the program code is a extremely difficult decision. Of course, if you just do the experiment, think of the new algorithm, SDK can be overridden at any time.
After cautious consideration, nor is not reconstruction, but not all of a sudden all of the code before the overthrow of the project, deny everything, you may not necessarily write better than the previous code. Combined with their own work experience (end mobile development experience), major reconstruction work develop in the following areas:
- Delete useless to third-party libraries
- Delete unreasonable third-party libraries, or use the system comes with its own built wheels
- Good but not used to delete the definition of variables
- Delete import came in but did not use header files
- More delete old items left behind with less than logical
- Structural remodeling code, project engineering, View, Service and other unreasonable levels
- High efficiency of the code is not reconstructed, cycle speed optimized compiler
- Code written ugly reconstruction, named unreasonable
- Reconstruction of memory leaks
- Elimination project warning
Third, the architecture reconstruction
The aforementioned reconstruction is cautious decision, here referred to the need, it is not self-contradictory? In fact, this is not contradictory, but nexus. With the application of the continuous development of the original architecture often they face a variety of problems, such as unable to meet customer demand, can not achieve the expansion of applications, new features, and so can not be achieved. In this case, how can we avoid some of the pit, try to reconstruct the architecture of the more successful implementation.
3.1 determine the purpose and necessity of reconstruction
每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元气，所以决策者们首先要分析架构重构的理由和其他备选方案，明确重构的目的是为了满足业务需求，并且是不得不做的最佳方案，然后再考虑其他问题。 有时候，经过分析就会发现，也许还有其他解决方案，比如增加计算资源，或者重构的目的不是为了业务需求，那就没有必要做了。检查清单：
- 架构重构的原因是什么，是为了满足业务的需要还是只是觉得架构不好看？
- 除了架构重构之外，还有其他备选方案吗？是否都分析过这些方案的利弊？
3.2 定义“重构完成”的界限
如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，怎么才算是“完成”了重构，目标要有数据量化，或者有能够测试的办法。这也是一个需求分析的过程，如果需求不明确，那么规格说明书没法写清楚，负责重构的团队也没有明确的目标，不能以重构的时间或者主观的判断为结束的依据。检查清单：
- 重构的目标可以量化，或者说可以测试吗？
- 重构完成的标准是什么？得到业务部门或者领导的认可了吗？
3.3 渐进式重构
现在软件研发最流行的就是快速迭代、持续交付、尽早反馈。这同样可以用在架构的重构上，重构过程的难度不亚于构建一个新产品，所以在设计重构的时候，要引入持续交付的流程，每一个重构步骤或者模块都要快速部署并得到反馈，以便评估重构的效果，及时作出策略调整。经过谨慎测试之后，将数据和业务迁移过去。检查清单：
- 能否把重构过程分成小的迭代，每一次改进都能尽快得到反馈？
- 重构过程中的效果能够定期展示给业务部门或者领导吗？
3.4 确定当前的架构状态
在启动重构之前，团队要对当前的架构状态有清晰的了解，也就是设定好基准，以便评估重构的效果。据我的观察，负责重构的架构师或者开发者，往往还没有搞清楚现有的架构设计，就开始重构了，结果经常出现这样的情况：重构到某个阶段，发现行不通，然后一拍脑袋说，哦，原来这块的架构是这个样的，是为了达到某某业务需求啊，这块不能动，得想别的办法。类似的例子在研发团队中时有发生，也提醒我们要慎重小心。检查清单：
- 你了解当前的架构设计吗？它的设计初衷和之前的选型方案知道吗？
- 你能给架构设定一个基准状态吗？
3.5 不要忽略数据
数据的重要性不言而喻，业务都是以数据流为载体的，所以架构重构的本质就是对于数据流的重构。数据对重构的重要性主要体现在两个方面：在重构设计时，需要考虑业务数据的需求，重构之后的系统对于数据的存储、处理、分析等功能是否有影响；在重构过程中，考虑依靠数据甚至是实际的数据来验证重构的效果，提供评估的支持。检查清单：
- 业务数据的需求在重构设计中有体现吗？
- 重构过程中能否通过实际数据来验证效果？
3.6 管理好技术债务
技术债务在平常的软件研发过程中也是比较突出的问题，架构重构往往是为了偿还技术债务，所以请不要在偿还技术债务的过程中制造技术债务了。技术债务就像信用卡一样，会有很高的利息率，就如同给团队留下了大量的帐务开销。组织应该培养一种保证设计质量的文化。应当鼓励重构、同时也应当鼓励持续设计以及其它有关代码质量的实践。在开发时间中应当专门抽出一部分以解决技术债务。检查清单：
- 团队对技术债务有跟踪和备忘录机制吗？还是开发人员可以随意的产生债务？
- 针对技术债务有定期的培训、回顾机制吗？
3.7 远离那些虚荣的东西（例如使用“热门”的技术栈）
架构的重构过程应该是以目标为导向，换句话说“注重实效”。对于技术人来说，一个经常被轻视的问题在于，喜欢追逐新鲜的热门技术，这其实是个好事情，说明技术人勇于创新，不断接受新技术。但是对于架构的重构这样的关键性任务来说，是不是新技术并不重要，重要的是能不能实现重构的目标。对于新技术来说，虽然热度大，但大家踩过的坑还不多，积累的失败教训和成功经验还不够，在这种情况下，建议大家不要头脑一热就上马新技术，应该客观冷静地评估新技术和成熟技术对架构重构的影响和效果，以数据和经验来说话，而不要追赶时髦。检查清单：
- 重构的技术选型是否有详实的数据和专家评估？
- 选用的技术是否有良好的人才积累和足够的经验支持？你是不是实验小白鼠？
- 在技术选型时，是否至少有两个方案待评估？有没有成熟的技术方案？
3.8 做好准备面对压力
软件开发过程中，压力无处不在。对于架构重构来说，压力来源于多个方面：管理层、团队成员、同级部门等等。说白了，架构重构对个人来说往往是一件出力不讨好的事情。和做一个新产品能够取得很高的赞赏相比，重构的成绩往往并不受领导重视，而且出了问题还要承担很大的责任。从软件开发角度看，做新产品是从 0 到 1，而架构重构是从 -1 到 1，复杂性和难度通常更大。因此，重构的负责人要提前做好心理准备，舒缓压力的一个技巧是，设置好里程碑，将重构的成果量化，并且和业务的变化关联起来，定期向利益相关各方同步状态，得到大家的理解和支持。检查清单：
- 架构的重构是否得到了管理层（特别是最高管理层）的支持？他们是否对重构的时间、任务量有直接的认识？
- 你的重构计划中是否包含了一些可以量化的成果？是否定期向管理层展示这些成果？
3.9 了解业务
架构重构的最终目的是改进业务，所以对于业务的了解将有助于架构师和技术人确定重构目标的优先级和关键路径。比如，我们需要知道哪些关键业务的架构是不能碰的，哪些业务之间是互相关联的，哪些业务的架构是需要优先重构的…..等等。除了了解业务本身，我们还需要了解“人”，表面上管理层是重构目标的裁决者，但实际上业务部门的人才是。技术人需要了解他们的业务需求，并将其转化为重构目标。通过这种方式，架构重构的意义才能得到具体的体现。检查清单：
- 是否与业务部门就架构重构所能实现的业务目标进行过充分的讨论和确认？
- 是否对关键业务和优先重构的业务进行了确认？
3.10 做好面对非技术因素的准备
Whether you want to believe that technology is not the most influential factors in the architecture reconstruction (as well as other critical business decisions), we also involve commercial interests, management preferences, affect large customers, team issues, etc. for architects and technical people, these factors often than not they can possess. We can do is, with stakeholders to set goals reconstruction, then, according to different factors, adjust the target. Remember, do not carry the dead this, when someone put forward different views, to be frank and to communicate with them, and tell them how to adopt the views, then the reconstruction of the target subject to change, and then let other stakeholders know that these changes . The impact of non-technical factors is an objective reality, but also from a commercial level, it is reasonable, so for technical people to learn to adapt. Checklist:
- When the non-technical factors that affect the reconstruction of infrastructure, whether you made adjustments to the target and inform the stakeholders?
- Are you ready to open rather than boycott the mentality to deal with the impact of non-technical factors?
3.11 for code quality has mastered
Reconfigurable architecture of the high quality requirements of the code, on the one hand is the reconstruction process of the Bug tolerance lower than the new product development, on the other hand also determines the degree of difficulty for the next remodeling. Code review is a very good way. Code review is a necessary step in the software development process, not only can help the reviewer mentioned code quality, but also allows reviewers to deepen the understanding of the product. No matter how busy team, we must ensure that before submitting the code, is the result of the other members reviewed the short term the team will take time, in the long run multiplier is a good thing. Checklist:
- Team members whether there is enough attention to code quality? Are there incentives?
- Are there standard internal team documents and code quality review process?
Fourth, the end of the
Reconstruction of the infrastructure, everything from practice is the most valuable experience for the technology used by people is meaningful.