软件系统的迭代是一个线性的过程。
参与这个过程的有多个相关团队，产品负责指明目标，研发负责设计方案和实施路径，质控负责落地质量。
一个软件系统的复杂性一定会伴随着业务的不断迭代和各种快速试错出现发展不平衡，无论是业务层系统还是底层支持系统的抽象由于业务迭代要求无法按照常规软件设计方案实施。而各个团队在迭代中由于人员流动，文档落地不完整，系统在越是后期迭代中越会战战兢兢，这就是系统重构的一个原因。无论是产品还是研发，对于系统认知不足总会产生恐惧心理；又或者大刀阔斧的迭代中，总会出现各种各样的历史问题导致系统运行稳定性。但业务驱动的迭代仍在继续，这就对团队提出了更高的要求，对具体负责这个系统维护的人提出了更高的要求，对这个系统维护工作的流程提出了更高的要求。
如何应对一个经过3、5年高速迭代系统的持续迭代，如何面对系统越发复杂但维护成本由于各种条件（作为一个业务部门对于盈利性的考虑，在无重大业务流量提升的情况下，不会倾向于提高系统的研发维护成本）无法提升现状。
有以下几点建议可以考虑：
降低复杂度
无论从系统各个模块的生命周期来说还是从系统复杂度解构来讲，系统应该在持续的迭代中进行自我的淘汰。尽最大可能降低系统的复杂性，尽力和产品部门协调好业务迭代中的取舍，从根本上降低维护成本。
通俗来讲：1、业务迭代中已经线下的业务及时和产品部门沟通好，做好下线业务的系统剥离和显现处理；2、业务迭代中，针对已经无效的场景逻辑，及时和产品确认后，进行逻辑剥离与下线；3、业务转型中，针对业务的收尾性维护，及时沟通产品对业务收尾的诉求，双方协商给予收尾工作的单独支持，避免一个复杂业务仅包含部分流量的运行，空耗维护成本和运行成本。
设计
持续设计、前置设计、专业设计
理论性的了解少，不多讲，就从项目经验角度讲讲。
历经多个项目迭代，期间遇到的最多的问题就是在原有系统进行新项目接入时，由于历史问题未考虑周全（事实上也不可能穷尽的考虑周全，成本不允许）,导致新项目上线后，总会对现有系统的功能产生波动；这些波动会在后续的运营流程中不断的暴露，或许、会导致核心业务数据一致性错误，或某些数据落地存在问题，或业务打破原有业务约束等，长此以往就会认知形成该当如此。由于对项目设计的考量不够完整，对历史系统不够熟悉，新业务对历史系统影响评估不足，甚至是产品需求的新老业务自相矛盾导致。
持续设计
完善系统的设计文档留存，以便后人能够理解原有系统设计思路，在进行后续系统升级重构时进行参考，降低问题的重复出现或无效的重构。持续的系统设计流程能够使得系统演进顺滑自然，避免不断的打碎重构，使得系统不断破碎重组。
前置设计
作为一个质量管理的角色，自然能够希望系统的设计工作是清晰、明确的，但往往实际的开发团队有自身实际的特点。无法要求团队内每个项目的启动和迭代都是由优秀的工程师进行系统的设计和实施。此时，前置设计就能够尽量的避免在实际项目落地时由于设计不合理，导致在遇到具体的业务场景时无法支持，需要剑走偏锋或牵强附会的方式以支持业务场景。由于设计不合理导致的项目返工会造成团队的长期消极情绪，非常消耗团队士气，与团队的积极向上氛围不利；同时也会对关联上下游团队造成不好印象，影响项目进度。对后续的系统维护人员也会是一个负担。
专业设计
系统的设计工作应该是一个严肃工作，他对系统的后续演进有极大影响，对于设计应该通过一套流程进行规范。建议审慎对待设计工作，对于不具备系统设计能力的开发人员，应给予指导意见并进行严谨的设计评审工作。
高度自检
无论从开发还是测试的角度，对于历史系统的变动总是需要极大的成本来保证有效性。历史代码的高度自检能够以较低的成本提升变动导致的不利影响。开发单元测试和测试人员的自动化代码自检覆盖，都能提升自检的有效性。
对于业务驱动的系统而言，其变动性毋庸置疑，应用户和市场环境变化，不断组织出符合市场预期的产品，支持业务滚动迭代同时，现有系统会不断沉淀出一套具有基础支撑能力的基层系统。无论是Quartz、Agreement、Account、Member、Payment、Message等，这些基础系统通过不断的迭代，已经适应了业务所在行业的生态，其所沉淀的价值能够极大的支撑系统的快速组织。对于基层系统的质量保证则需要降低其维护成本，提高相关系统的自检程度，为后续系统业务编织提供有力的支持。
量力而行
少做大包揽的承诺
系统复杂到一定程度，就会形成生态，不要期待某个人能够对系统了解的多么清晰透彻。在对一个动态迭代的系统进行分析工作应总结一套方法，依据方法实施分析解构。基于一个初步结论，同相关联团队沟通，逐步迭代项目变动的设计对原有系统的影响。
对于高变动的业务系统，应构建一套快速编织产品的流程，不断的冲锋陷阵终会拖垮团队。
依据业务所能承受的最低质量，做出保守的进度承诺，并高效坚实实施。通过建立质量沉淀，逐步提高保守承诺的底线。
质控-迭代三五年的系统怎么办
网友评论