认识达内从这里开始

认真做教育专心促就业

程序员如何快速改正遗留系统

发布：太原达内教育官网
来源：互联网
时间：2019-07-24 07:39

要知道，并不是所有的程序员都有机会在一个公司做到退休的，而这就意味着程序员会接手别的程序员遗留下来的系统程序或者代码，而今天我们就一起来了解一下，针对这些遗留程序员的改造应该如何下手。

程序员如何快速改正遗留系统

范围定义

对于遗留系统而言，通常业务运转时间较长(譬如5~8年以上，甚至更长)，因此涉及的功能繁杂，代码中存在大量无效或者过时的需求，缺陷修复成本较高。

另外，系统在演进的过程中，也会持续为用户提供新的功能和价值。因此，划分出清晰的范围非常重要。

实际上，范围定义主要包括两部分：

明确业务改造范围

所谓改造范围，就是确定我们常说的业务试点。通常，作为初次尝试微服务实践的组织，建议选取业务范围影响较小、非关键功能的试点，这样做也是为了确保在不影响核心业务的情况下快速尝试并获得反馈。

明确成员责任范围

明确成员责任范围，确定由谁来改造，确保改造的目标清晰。

实际上，对于产品而言，遗留系统的维护和更新，包括缺陷定位、缺陷修复、数据更新、功能实现、测试、交付给运维团队等，通常已经让团队的工作处于高负荷状态。因此，需要确定成员，全身心的投入，以微服务改造作为短期目标。

功能剥离

有了明确的业务范围，成员也有了清晰的责任，接下来就需要将部分功能点进行剥离。

所谓剥离，就是将选中的功能从原有的系统中拆分出来，并构建成独立的服务。在这个阶段，主要包括两点：

将功能从原有系统拆分出来，并构建新服务

一提到拆分，很多朋友会纠结，“系统复杂，如何拆分微服务才好?怎么样的拆分才合理?”。其实，从我个人的观点来看，这时候还不是纠结服务到底怎么划分合理的时候。为什么?

好的架构是动态演变和迭代出来的，业务在不断改变，技术和工具也在不会的升级换代，没有完美的架构，只有无限逼近完美的动态平衡，所以先小范围、低成本动起来，在运转中找平衡点。

微服务的复杂度在于分布式系统本身，以及其生态系统(开发、测试、部署、运维、监控、告警)的搭建。

团队文化的形成是一个相对漫长的过程，如果花很大力气关注服务怎么拆，而没有聚焦在生态系统的搭建以及团队文化的形成上，实际上是舍本逐末。即便拆分出了不同的服务，在落地的时候也会遇到诸多问题。所以，找一个功能点先拆，然后搭建持续交付流水线，快速试错，建立好有效的反馈闭环机制，再不断寻找动态平衡，拆分出更细的服务或者将不合理的服务合并。

在原有的系统前端，使用代理机制，并使用遗留系统和新服务组合为用户提供价值

这一步，目的是使用组合的系统(遗留系统+新的服务)为用户提供价值。

对于Web系统，通常可以在前端使用直接请求新的服务。也可以在后端使用转发请求，获取新服务提供的数据。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。

< 上一篇：太原达内微服务架构的诞生背景

下一篇：会计师做审计报表应该注意哪些问题 >