架构学习-系统重构(业务)

       A01.定义重构 自问自答:要不要当前系统重新写一遍呢? 要不要系统中某个某块重新写一遍呢? 如果回答内容”是”. 重构就是把旧的系统全部推翻或者部分推翻,开发新的系统来代替旧的系统或某个部分.公司案例:第一版公司中php写的业务转JAVA语言开发,属于整个系统的重构.第二版后续的商标注册类业务进行订单优化,后续的商品模块进行局部重构;

        A05.何时重构 业务主导:对当前业务流程做颠覆性的改变,导致当前的系统的实现不满足业务的要求; 当前业务系统已经无法对业务进行有效支持,延误业务的发展; 当前系统的实现语言需要修改为其他的编程语言去实现. 技术主导:对当前系统的架构进行调整

        A10.关键维度 做重构,需要考虑哪些关键性,或者说决定性因素呢?  哪些关键步骤呢?  x1.业务梳理梳理;   x2.代码逻辑梳理;  x3.业务数据迁;  x4.架构设计

      A15.不要重构 哪些情况下不建议进行系统重构?  1.如果系统对业务的后续支持远远未到临界点,那么不建议做系统重构;  2.如果是小众领域的公司,其实切换编程语言做系统重构没有什么价值,因为业务领域决定体量;  3.如果以抢占市场为目标的创业公司,达到目标体量后再决定是否做重构; 4.对于业务根本没有连贯性的产品,不要重构,因为重构后说不准第二天产品又变化.

      A20.现实约束 x1.人力成本, 2.人员更替, 3.业务梳理, 4.业务迭代, 5.新旧数据, 6.技术约束 总结:在人员,业务,架构,数据四个关键维度上,如果研发人员和产品经理都是新参与,那么系统重构的危险性比较高,并且人力成本会非常高. 因为对之前业务不熟悉不了解导致业务设计的缺憾,导致不得不做后期重构.如果不是财大气粗的公司,那么一定要考虑的内容是人力成本,将人力放在重要业务上;  x2.如果公司人员变动不大,产品经理或研发人员对业务都非常熟悉,这是重构的完美前提.如果要把业务做彻底的变动,那么对研发人员的要求比较高.    x3.最糟糕的情况就是曾经的产品经理或研发人员都离职,后续的任务很挑战新的产品经理和研发人员的能力;  x4.复杂业务,对于昔日设计的产品经理不在,很挑战新来的产品经理对业务的梳理;如果有开发的研发或者测试人员,情况还好;如果整体业务迭代速度比较高,那么重构后的业务可能已经至于后维护的旧业务;需要对业务迭代进行必要的延期,否则重构无法完成;  x5.如果是新研发人员,需要对旧业务进行了解,数据迁移比较痛苦.需要对新旧数据库做根本的了解.这时候对研发人员的能力要求比较高,否则一定又可能技术能力约束导致出现各种各样的数据问题[新旧数据和技术约束]; 理想情况下:  y1.旧业务抛弃,使用新业务模式,但是对新旧数据库有充分的理解,压力在技术;  y2.旧业务做梳理,然后有之前的研发人员或之前的产品经理,然后做重构; y3.最差的就是新的研发人员,新的产品经理去做旧系统重构

      A25.难点剖析 x1.业务梳理难度: 1.系统使用时间,如果几个月还好,如果几年那就比较难梳理; 2.简单系统需要做业务的重构嘛?这是个白痴的问题;3.如果产品不断向前迭代,那么比较好梳理,因为有主线;4.如果经历n手的研发人员,研发人员的帮助不会太多; 5.如果经历n手的测试人员,那基本上只是粗粒度的脉络梳理而已;6.如果经历n手的产品经理,基本上产品连贯性不会太好;  x2.代码逻辑梳理: 1.如果经历n手的研发人员,那么代码逻辑的整理会比较困难; 2.建议从产品经理进行业务梳理,研发人员的文档编写处理能力一般不怎么地;  x3.业务数据迁移: 1.如果是n手的研发人员,数据迁移会是比较头疼的事情; 2.如果有之前的系统开发者那么就谢天谢地. x4.业务迭代速度, 1.如果旧系统业务迭代速度比较快,那么可能重构后的系统根本不复合业务的发展,那么就降低业务迭代速度; 2.跟可怕的是业务迭代根本不连续,可能这次重构后,业务已经迭代到十万八千里.所以需要控制业务.

      A30.如何解决  x1.一切处理的因素都是人,那么招来厉害优秀的人,单兵作战能力强大的产品经理和研发人员来主导.尤其在产品经理和研发人员经过n重天的时候;  x2.再次务必确定是否要做系统重构,因为重构的成本确实可能无法接受; x3.最后能一次做好,那么就一次做好.如果你招来的人很差,做出来的内容不会好,重构的概率自然就非常大,重构的时间和经济成本,业务延迟成本远远多于薪资.