重构.水
重构的背景
重构的范围有点宽泛,重构也是可深可浅的。 一般代码优化,精简也是重构的一部分。 深入的重构是要基于框架,对业务有足够认知,把握。
重构不是想当然发生的。 深入的重构一定是现阶段系统已经不能更多的支持业务扩展;或者bug太多,无力追加新的需求。 这时一般架构师会联合产品经理一起来着手系统的重构
重构的目标
重构是基于目前系统的存在问题才会重构的。 一个优秀的系统去重构的带来的价值不大。 重构也不是说全部推翻重来,没有根据而进行重构。 找到目前系统的痛点,重构的目标是为了更好支持业务扩展,另一方面就是为了解决这些痛点。这才是重构的目标。
重构的准备
其实这点说起来有点赘述的感觉: 重构一定要结合业务本身。只有了解了业务的需求,产品的更多细节,重构才能做得更好。
这里说个我的实际例子: 我重构时,有一个架构师提供重构的整个架构,一个多年资深的技术/业务党(boss),还有一个实施经理(当时负责产品需求),我是重构的具体执行者(对于业务有一定的了解)。 重构时,每当出现疑问,不清楚的地方时,都会列举用户场景,给出解决方案,解决不了然后跟他们一起过,在会议中确定解决方案。 照着说这算是ok的。
但是在重构完,新的产品总监来梳理我重构的功能时,却发现有些地方设计过度,有些地方不是产品想要的东西...(注:此次重构解决了业务扩展的问题,跟原先系统的痛点)
所以在这里知道一个重构的准备是多么重要了吧,重构一定与基于业务本身来做,产品要做成什么样子,重构需要支持到那步,这都是需要重构商讨确认的地方,不然后果可能就是设计过度,或者没达到产品的需求
重构的过程
即使对业务了解,但也可能因为重构的关系,到了某些点的时候不清楚该怎样解决,或者不清楚某些点该如何实现。 这些都是问题。至于怎么解决问题,那么最有效的方式就是去列举用户场景,根据用户场景然后才能针对性的解决。
一般刚接触,不知道怎么做,然后就不知所措。其实这里要慢慢学习去列举用户场景,可能列不全,没关系,在跟产品讨论的时候这些会被慢慢补全,有了这些用户场景,然后你需要的就是实现各种用户场景下的情况就行
重构中学到
一个企业级的系统中,需要面临的复杂多变需求,程序是不可能用逻辑去完全兼容所有情况。这时我们需要转变思维:抽象业务,发现业务关键点,提取其中公共部分。提供输入参数,用动态灵活的配置(业务逻辑处理)来支持更多复杂多变的情况。
即使一个erp系统, 也需要去抽出平台层公共的组件,为上层业务提供支持,同能也能在业务层解耦
本篇是未读>写下的水文,不久等我读完这本书再来写点更多感悟
关键字:重构, 业务, 痛点, 场景
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!