对于开发者来说，架构设计是软件开发过程中最重要的环节。据说没有蓝图就无法建造房屋。在应用无处不在的互联网时代，架构设计有一些成熟的模式，开发者和架构师往往可以借鉴。但是，随着应用的不断发展，最初的架构往往会面临各种问题，比如不能满足客户的需求，不能实现应用的扩展，不能实现新的特性等等。在这种情况下，如何规避一些陷阱，尽可能成功地实现架构的重构，是很多开发者和架构师迫切需要解决的问题。在此，与大家分享Uber工程总监RaffiKrikorian的12条法则，并附上一些解读，希望对大家有所启发。确定重构的目的和必要性似乎是多余的，但不要忽视它。每一次建筑改造都是一次“手术”，就像手术一样，即使成功了，也会伤及元气。因此，决策者首先要分析结构改造和其他备选方案的原因，明确改造的重要性。结构的目的是为了满足业务需求，是在考虑其他问题之前不得不做的最好的解决方案。有时候经过分析，会发现可能还有其他的解决办法，比如增加计算资源，或者重构的目的不是为了业务需要，所以没有必要去做。Checklist：架构重构的原因是什么？是为了满足业务需求还是只是觉得架构不好看？除了架构重构还有其他选择吗？您是否分析过这些解决方案的优缺点？Define”BoundaryofRefactoringCompleted如果确定要重构，那么就必须明确目标，即重构的边界条件，如何“完成”重构，目标必须通过数据量化，或者有方法是可以测试的，这也是一个需求分析的过程，如果需求不明确，规范就写不清楚，负责重构的团队没有明确的目标，重构时间或主观判断就不能作为ending的基础。前几天和一个朋友聊天，他最近负责系统性能优化，也要做一些重构。一开始团队的目标不明确，和大家都不知道优化到什么程度，不敢下手。如果目标是提升10%，那么可以从细节入手；如果是提升50%，那么可能需要采取大动作来实现它。后来，在果阿之后l澄清后，团队找到了合适的方法。Checklist：重构的目标可以量化，还是可以测试？完成重构的标准是什么？是否经过业务部门或领导批准？渐进重构现在最流行的软件开发就是快速迭代和持续交付，尽快反馈。这也可以用于架构的重构。重构过程的难度不亚于构建新产品。因此，在设计和重构时，需要引入持续交付流程，每个重构步骤或模块都必须快速部署。并得到反馈，以便评估重构的效果，及时做出战略调整。有读者会说，我们的架构重构是翻天覆地的变化，不能渐进，只能一蹴而就。如果是这种情况，可以考虑在另一个副本系统中重构，仔细测试后再将数据和业务迁移过来。Checklist：能否将重构过程分成小的迭代，每一次改进都能尽快得到反馈？能否定期向业务部门或领导展示重构过程的效果？确定体系结构的当前状态。在开始重构之前，团队需要对架构的当前状态有一个清晰的认识，即设定一个基线来评估重构的效果。根据我的经验，负责重构的架构师或开发人员通常在弄清楚现有的架构设计之前就开始重构。结果经常会出现这样的情况：重构到一定阶段，发现不行。然后一拍脑袋说，哦，原来这块的结构是这样的，要满足一定的业务需求，这块不能动，得想别的办法。类似的例子在研发团队中时有发生，这也提醒我们要谨慎。记得有位哲学家说过，了解别人容易，了解自己却很难。Checklist：你了解现在的架构设计吗？你知道它的设计初衷和之前的选型方案吗？您可以为架构设置基线状态吗？不要忽视数据的重要性。不言而喻，业务是数据流的载体，所以架构重构的本质是数据流的重构。数据对重构的重要性主要体现在两个方面：重构设计时需要考虑业务数据的需求，重构后的系统是否会影响数据的存储、处理、分析等功能；在重构过程中，考虑依靠数据甚至是实际数据来验证重构的效果，提供评估支持。Checklist：业务数据需求是否体现在重构设计中？能否在重构过程中用实际数据来验证效果？管理技术债技术债也是平时软件开发过程中比较突出的问题。重点提醒开发者：架构重构往往是为了偿还技术债，所以请不要在偿还技术债的过程中产生技术债。技术债务就像一张信用卡，利率高，留给团队大量的帐单费用。组织应培养确保设计质量的文化。应该鼓励重构，以及持续设计和其他代码质量实践。一部分开发时间应该用于解决技术债务。如果没有适当的注意，现实世界的代码会变得越来越复杂和难以理解。Checklist：团队是否有技术债务的跟踪和备忘机制？还是开发商可以自由承担债务？技术债是否有定期培训、追溯机制？远离虚荣的东西（例如使用“热门”技术栈）重构架构的过程应该以目标为导向，换句话说，“以务实为中心”。对于技术人来说，一个经常被低估的问题就是喜欢追逐新的热点技术。这其实是一件好事，说明技术人勇于创新，不断接受新技术。但对于架构重构这样一个关键的任务，是不是新技术并不重要，重要的是能否达到重构的目标。对于新技术，虽然热情高涨，但人才储备不够，大家踩过的坑不多，积累的失败教训和成功经验也不够。技术应该客观冷静地评估新技术和成熟技术对建筑改造的影响和效果，用数据和经验说话，而不是赶时髦。Checklist：改造技术选择是否有详细数据和专家评估？所选技术是否有良好的人才积累和足够的经验支持？你是实验豚鼠吗？在选择技术时，你是否至少有两个方案需要评估？有成熟的技术方案吗？准备好面对压力。这种军规更像是对建筑师的一种心理暗示。在软件开发过程中，压力无处不在。对于架构重构，压力来自很多方面：管理层、团队成员、同行部门等等。说白了，架构重构对于个人来说往往是一件吃力不讨好的事情。与做出新产品可以获得的好评相比，重构的成果往往不被领导看重，出了问题还要承担很多责任。从软件开发的角度来看，做新产品是从0到1，而架构重构是从-1到1，通常更复杂、更难。因此，重构的负责人要提前做好心理准备。一个缓解压力的技巧是设定里程碑，将重构的结果量化，并与业务变更关联起来，并定期与所有利益相关者同步状态，以获得大家的理解和支持。Checklist：架构的重构是否得到管理层（尤其是最高管理层）的支持？他们是否直接了解重构的时间和工作量？您的重构计划是否包括一些可量化的结果？这些结果是否定期提交给管理层？了解业务似乎是胡说八道，但我认为RaffiKrikorian一定有理由故意提出这个问题。架构重构的最终目标是改善业务，因此对业务的理解将有助于架构师和技术人员确定重构目标的优先级和关键路径。比如我们需要知道哪些关键的业务架构是不能触及的，哪些业务是相互关联的，哪些业务架构需要先重构……等等。除了了解业务本身，我们还需要了解“人”。表面上看，管理层是重组目标的仲裁者，但实际上是业务部门的人才。技术人员需要了解他们的业务需求并将其转化为重构目标。这样才能具体体现建筑改造的意义。Checklist：是否与业务部门充分讨论并确认了架构重构所能达到的业务目标？确定好关键业务和优先重构业务了吗？准备好面对非技术因素。.....这是另一个不太舒服的建议。不管你信不信，技术并不是架构重构（以及其他关键的企业决策）的最高影响因素，我们还会涉及商业利益、管理偏好、大客户的影响、办公室政治、站队问题和以此类推，对于架构师和技术人员来说，这些因素往往是他们无法控制的。我们能做的是与利益相关者一起设定重构目标，然后根据不同的影响因素调整目标。记住，不要死死抓住这个目标不放，当有人有不同意见时，坦诚地与他们沟通并告诉他们如何采纳意见，然后重构目标就会发生变化，然后让其他利益相关者知道这些变化.非技术因素的影响是客观存在的，从商业角度看也是合理的，所以技术人要学会适应。清单：当非技术因素影响架构重构时，您是否调整了目标并通知了利益相关者？您准备好以开放而非抗拒的态度对待非技术因素了吗？对于代码质量的掌握这类似于上一篇文章中提到的“技术债务的管理”。架构重构对代码质量要求很高。一方面，与新产品开发相比，重构过程对错误的容忍度较低。另一方面也决定了下一步重构的难度。关于代码质量的书籍和文章已经有很多了，在这里我只想提醒大家：codereview是一个非常好的方式。代码审查是软件开发过程中的必要步骤。既可以帮助reviewee提代码质量，也可以让reviewer加深对产品的了解。不管团队有多忙，都必须确保代码在提交前已经过其他成员的审核。从短期来看，会占用团队的时间，但从长远来看，却是事半功倍的好事。清单：团队成员是否足够重视代码质量？有奖励和惩罚吗？团队内部是否有针对代码质量的标准文档和审查流程？准备团队。这是拉菲克里科里安列出的最后一条军事规则。前面所有建议的总结，这里就不解读了，请大家自行感受。最后RaffiKrikorian对架构的重构给出了很好的建议，但是是否有效还需要实践检验。与其相信书本，不如没有书本。实践中的经验是最有价值的，只有技术人员使用才有意义。
