架构师之路-系统重构的前置条件

在我们的工作当中,难免会遇到系统架构重构的问题,但是我们不能盲目的进行系统重构,因为重构的成本,代价还是很大的,那么什么时候,或者契机的情况下才能适合重构呢?

系统重构的标准因素

当架构不能再去适应业务发展的需要时。

重构系统,往往是我们已经对现有系统架构无可奈何之时,因为重构的前提往往是我们的系统已经部署到生产环境,虽然当前系统可能有问题,也有可能很烂,但是这很正常,没有一个系统的架构是完美无缺的,至少现在的它能在生产上跑,能满足现有业务需求,所以,能不动,尽量不去动它。但是如果业务发展就是很快,用户体系也日益增多或者现有架构可能满足,但是无法在未来几年之后达到业务发展以及用户的需求,这时候你就不能以技术的阻碍去影响公司业务的发展,此时就需要重构。
前人挖坑无法填,代码紊乱无法直视

我们作为一名优秀的程序员,往往会有一种情结,就是,前面人写的代码太垃圾,无法直视,举些例子比如服务api想怎么写怎么写,本来一个服务对用户负责,结果用户服务层还掺着订单接口,后来人员跟代码都能跟的一脸懵逼,简单总结就是开发一时爽,维护火葬场的代码。这种情况,我们可以去主张重构,但是也得想清楚会带来的风险以及代价。因为往往这种情况下,代码是可以在生产上运行的,业务人员或者用户不会去关心你代码怎么写的,只关心功能是不是正常。

系统重构的风险因素

系统重构对原有功能带来风险

简单来说就是原有功能,可能正常使用,重构后,可能出现无法正常使用的问题,对用户体验感会非常不友好,往往就是,我以前能用啊,怎么现在不能用了!
对于新的需求推迟开发上线

重构的过程,我们先要需要保证原有功能不被影响,所以势必会导致对于新来的需求往后推迟,这也变相导致公司付出成本。
重复测试问题

系统重构后,不光是对未上线功能的测试,也要对原有功能进行再次测试,而且再次测试也可能存在测试不到位的风险。

系统重构的准备工作

足够了解原来的业务

在重构之前,我们不仅仅只是要了解业务,还要真正的完全理解业务,以及现有系统的业务规模
对于技术的选型

对于技术要做预研,可能我们喜欢追求新技术,但是新技术未必全是最好的,所以说没有最好的技术,只有最合适的技术,作为架构师的我们一定要记住一点就是,技术永远为业务服务
要做好基础的建设

在系统重构之前,先要做好基础服务的建设,开发规范以及开发手册的撰写,CI(持续集成)/CD(持续交付)环境的搭建,这是一名架构师要做到的。这里的基础建设可以不用很全,但是一定要有,我们对于系统架构,要遵循着约定优于配置的原则,约定好了,工作效率以及代码质量也会提高。基础建设是系统重构最关键的环节

单体(All in one) 还是微服务(Micro Service)?

现在,分布式微服务的概念深入程序员的心中,因为不管是面试,还是应用,牵扯到这个就会显得高大上,那我们在架构的时候,是不是需要建设分布式微服务的体系呢,答案是不一定的,假设你的用户群体只有几万,日活跃可能几千,你把阿里或者字节的架构搬到你的系统作为基础架构,一定就好用吗? 答案同样是不一定,可能最后还不如你系统原本架构好用,所以,只有适合的才是最好的架构