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