×

深圳网站建设—APP开发—网站制作—小程序开发_博纳网络公司

0755 -
82538016
82560826
网站制作资讯

大型网站建设:迭代关于系统老旧达到重构的条件浅析

文章编辑:网站建设 文章来源:外贸网站建设 浏览量:

  大型网站建设迭代关于系统老旧达到重构的条件浅析,我们知道每个系统的诞生都源于业务需要,为了能够支撑飞速发展的业务,很多时候我们需要对多个方案进行一些妥协来赢取时间。网站建设公司认为方案的妥协往往会造成架构不良,只能满足中短期需求,对于长期的延伸来说都有致命的伤害。还有一种情况是业务的方向发生了变化或者融合,导致原有设计的结构需要进行重新设计调整。因此基本上业务系统经过一段时间的开发运营,都会面临重构的问题。也许有人要问,系统重构按道理不应该属于开发范畴吗,和产品有什么关系呢?在重构的过程中产品需要做什么呢?在回答这两个问题前我们需要明白重构这个事情究竟重构的是什么。我们可以把系统看作一个人,人身体里面的骨骼、血肉可以看作是系统中的逻辑和技术架构,它们支撑着身体的稳定运行。而产品同样也有架构和逻辑规则,它代表着这个人的性格和精气神,一个人身体再好,精气神如果不顺畅,早晚也会出现生病的问题。
  因此每次重构实际是对系统这个身体的重造,除了要对骨骼、血肉进行大刀阔斧的改造外,我们还需要对它的精气神和性格做重新的审视和定位。以网站建设公司资深工程师以往的经验来看,电商每个系统的生命周期是1年到1年半,离业务越近周期越短。每个系统在开始时都会有一个1.0简化版本的阶段(甚至一些创新项目还会出0.1版本做业务尝试),即满足基本业务流转但不够精细。1.0版本上线后,系统会经历若干的完善版本,在不断完善原有缺失逻辑的同时,也会不断根据业务诉求拓展新的业务流程。一般业务系统运行半年左右,可能会出现一次较大版本的改造,当然这个时间一般是伴随业务的考核周期而变化的,当考核周期调整后,业务和系统对应的关注点也可能发生变化,但一般不会在这个时间点做重构改造,更多的是一次更大范围的升级。当业务运行到1年左右的时候,以目前互联网发展变化的更替速度看,业务上会期望做更多尝试,而原有的业务也会进化到一定的复杂程度,这时候系统的重构就会提上日程。系统的升级改造周期其实和摩尔定律提到的概念是相同的,只不过互联网的发展迅捷程度已经不允许18个月的等待。因此第一次重构的时间一般会发生在系统上线一年以后,这里我们不排除一些上线不久就安排重构的情况。重构属于耗时耗力的工作,原则上还容易对现有线上平台的稳定运行造成影响,因此大家不太愿意重构,但如果在以下这些情况下就需要仔细讨论重构的必要性了。
●逻辑混乱,业务诉求无法满足。
●系统耦合严重。
●功能边界不清晰。前面说到,由于时间的问题,很多系统在初始上线时考虑得并不完善,更多的是针对当前业务流程的实现,这样很容易造成后期增加的新逻辑跟原有流程冲突,按道理说产品需求是模拟业务流程的线上化,如果线下流程可以正常运转,那线上为什么不可以呢?网站建设公司资深工程师看过不少线下实际业务场景操作的情况,在执行某一个流程或者SOP时,若遇到特殊情况或异常情况,会人为选择特殊办法处理解决,这对于快速完成业务操作来说有很好的变通性和灵活性。但如果从系统的角度来看,系统存在的目的就是能够规范流程,确保精确性,如果过于灵活就会造成逻辑漏洞问题,这就是为什么不能按照所有线下特殊情况来设计系统。逻辑冲突会导致系统实现时无法制订业务流程,这样就无法开发新的功能。同样,很多系统为了赶工,会把相关内容都放在一个平台或者一个页面中来实现,随着业务的发展,这同样也会造成逻辑冲突,这就是因为系统耦合严重,功能边界不清晰。我们并没有把每个相对独立的模块变成一个小的系统来实现,而是所有业务逻辑耦合在一起,比如前面章节我们说到的,商品系统可以管理价格和库存,但随着业务发展,对价格和库存有了更多更高的要求,这时候就需要把价格模块和库存模块分离成独立系统,对商品系统进行重构改造,分离后的系统逻辑会更加清晰。同样,每一个功能应该有它自己的归属人员,同一个功能理论上不应该交给两个以上的平级部门或人员使用。好了,网站建设公司本文关于“大型网站建设:迭代关于系统老旧达到重构的条件浅析”的建站知识就分享到这里,谢谢关注,博纳网络编辑整理。

当前文章链接:/construction/foreign/14321.html
如果您觉得案例还不错请帮忙分享:

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【qin@198bona.com 】,我们在确认后,会立即删除,保证您的版权。

相关案例推荐