关于现有项目重构开发的一些总结

在业务发展的过程中,总有一些业务需求在初期人力或者各种资源不充足的情况下,通常都会采用比较省事的方案来实现业务需求,但是当自身业快速增长,依托于别人提供服务的功能开发必然会成为瓶颈。也就是因为这样,往往会自己开发一个新的项目在提供现有业务支撑能力的同事具有更大的业务支撑能力。在现在的开发过程中就遇到这样的业务场景,在项目的开发展过程中由于产品、设计、开发、协作多方面的原因,导致项目delay超过一个月,目前还在紧张的联调中。在这个过程中碰到很多的问题,但是一部分是已经预知,一部分却是被动获取到的,下面我就对这些问题做一下说明,希望能为大家提供帮助,当然也欢迎大家一起交流。

1、产品思路清晰,熟悉上下游业务和数据链路:
在产品规划业务场景的时候,并没有理清现有业务的上下游关系,对数据流向没有一个清晰的认识,导致一个错误的决策,进而引起导致几乎全链路修改的问题。在项目开始时,产品决定两套方案并存并行。但是他并不清楚在应用场景中的其中一环并没有办法识别出要选用老项目、还是新项目为业务提供服务。这一点和特定的环境有关系,在这里改造去区别调用当前的某一个项目服务被认为是不可能行的。正因为如此,在数据链路多个项目同时开展几乎在我支持的项目要收工时,新项目开发,产品才发现了这个问题。临时决定废弃原有的方案,新项目上线将取代原有的项目。这个变动导致我数据兼容的处理是无用功,当然也有其他牵涉的系统做了无用功。所以产品规划和决策时,需要梳理好上下游关系,清楚数据流及系统间的依赖关系,否则这就是个灾难。

2、相同业务的系统 合理借鉴现有的系统;
或许是因为这是一个全新的系统,所以作为项目的设计人员和开发人员并没有认真的对待已有业务系统,没有对齐做了解和分析,草草了解点皮毛,然后朝着自己认为正确的方向去搞。比如一个财务系统,用BigDecimal还是用Long,用元订价,还是用分。完全不考虑现有系统的方案。直接按自己的来,其中也包括全局主键的延续性。当然这也有第一个原因有非常大的关系。咱们暂且不说这个,而后的问题接踵而至,比如因为以分定价,采用Long存储货币,然后对于0.00005这种价格彻底没辙了,但是发现这个问题都已经是系统联调以后的事情了,这一改简直就是连坐,一群不明真相的群众跟着做改动。而后因为要数据迁移,可想而知问题更多了。所以我想说的是存在即合理,特别是要兼容已有系统业务的情况下,参考、了解已有系统的设计思想还是非常有必要的,同时在项目开始前可以考虑做调研,避免一些不必要的问题的发生。

3、打包上线还是分批上:
开篇已经简要的说了一下,新的系统需要兼具已有的系统功能,同时还要提供更强大的功能,相当于威力加强版。既然是威力加强版,那必然是要花费更多的时间和精力了,结果可想而知。但是互联网公司啊,边开车变换轮胎是常有的事情。如果要等一个产品所有功能完善了才能发布的话,那么可能替代他的产品早已经存在了,时间就是金钱,时间就是生命。所以这个时候对功能定优先级,考虑功能点分期分批上线尤为重要。但是很不幸,我碰到的这位力求完美,一定要上一个威力加强版。作为参会的一员,在定方案的时候我就提议功能分批发布、优先支持现有功能的,现有功能支持开发完成即可考虑发布上线,逐步完善加强版。可是结果就是预计发布时间一次又一次的延后,现在已经一个月了,还没有达到可发布的状态。可以假想一下,如果有两个team在做的话,谁先上谁最有可能活下来,但是现在似乎一家独大无所畏惧。

以上就是最近的一些感悟吧。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据