# 谁说明天上线,这货压根不知道开发流程!

作者:小傅哥
博客:https://bugstack.cn (opens new window)
原文:https://mp.weixin.qq.com/s/Xhgjv131wruZsUICmNDKZg (opens new window)

沉淀、分享、成长,让自己和他人都能有所收获!😄

# 一、前言

互联网公司常见工种有哪些?

互联网中一个项目的上线会需要各个工种间的配合,以研发为视角上会承接产品需求,下会交给测试验证,最终完成项目交付上线。其实除此之外,还会有业务、运营、UI设计、运维,来配合项目的发起、使用和运维维护。

图 18-1,互联网工种协同合作。

图 18-1 互联网工种协同合作

除了一条线上的工作交替配合,还有同工种间的跨部门协同工作。 比如:

  • 产品阶段:A产品中的部分服务,需要由另外一个部门配合开发相关服务支撑。那么双方产品需要协调好时间节奏,配合上线。
  • 研发阶段:承接着产品跨部门的对接功能,双方研发会定义好对接接口、对接时间,以及最终的联调上线。
  • 测试阶段:按照产品的功能节点、研发的开发流程以及接口描述,进行测试验证。

最终,同部门工作的交替、跨部门的工作协同,保障项目开发过程所需的各项物料都如期上线。

接下来我们来说一说,项目上线中各个阶段的执行过程。 当然,并不一定所有的开发都是按照这个过程执行。​会根据公司的体量、项目的大小、架构的模式有些许差异。所以,仅作为参考学习即可,不需要强制趋同。

# 二、时间节奏

图 18-2 定义时间节奏

  • 级别:⭐⭐⭐⭐
  • 事项:定义项目开发时间节点
  • 人员:业务、产品、研发组长、测试组长、架构师、核心项目成员
  • 描述:这个时间节奏的定义非常重要,它可以是项目经理发起也可以是产品发起。一般很多时候互联公司发一个项目,经常会听到老板说我要这个时间上。可能这句话看上去很不合理,但为了活下去,为了快速站住市场,压到下面执行人员就是一个必须要上线的时间。,这个上线的时间如果想满足, 那么就需要把整体的时间节奏确认出来。比如业务和产品什么时候把需求确认清楚什么时间与研发过PRD研发什么时候开发到提测测试什么时间测试完成如果,没有这个时间节奏,前面的职责人员把时间都耗费没了以后,越往后面风险越高。就像最后研发只有4天,测试只有2天,那带BUG上线吗!?所以要整体把控才是对项目的负责。

# 三、资源投入

图 18-3 安排资源投入

  • 级别:⭐⭐⭐
  • 事项:研发资源投入
  • 人员:架构师、研发人员、测试人员
  • 描述:站在研发视角,研发需要从工程开发、配合测试(改bug)、项目上线等的全流程参与,是一个较长周期的工作。但在某个阶段所投入的时间成本会有差异,可以按照一定的资源占比进行投入(1是100%、0.8是80%)。那么,当一个新的项目下来以后,就需要按照最近原则和项目的人员可投入情况,进行资源投入安排。如果项目较多的情况下,资源安排不合理。可能会导致项目提交测试晚或某些功能全部由一个研发提交测试的,最终改不过来BUG。从而也就导致了,项目的延期风险。

# 四、研发、测试、上线阶段

图 18-4 研发、测试、上线阶段

  • 级别:⭐⭐⭐⭐
  • 事项:研发、测试、上线阶段
  • 人员:研发人员、测试人员、架构师/技术组长
  • 描述:这个阶段包括的内容较多,主要是以研发视角看上下衔接人员。研发接过产品的需求开始做设计,设计完成后由研发主导发起设计评审,这个阶段参与的人员较多(研发、架构师、测试、产品等)。功能的合理设计也是可以非常有效的保障资源使用的重要一环,另外一个需求的合理架构将会为后续需求迭代做好铺垫。就像女厕改男厕,如果没有流出小便的水管,就很麻烦。 最终研发完成需要提交相应的成果物,尤其是提测报告、接口文档、单测信息。如果研发不能有完整的单元测试覆盖度,那么交给测试以后,日常的修复bug的事情就会非常多。当研发和测试工作完成以后,接下来就是发布上线。上线前夕会有研发发起上线报告,同时各方配合以及产品、运用准备相应的线上配置数据和权限。最终上线完成交付产品运营使用。

# 五、项目复盘

图 18-5 项目复盘

  • 级别:⭐⭐⭐⭐
  • 事项:项目复盘
  • 人员:面向研发和测试人员
  • 描述:复盘可能会因为出现事故、技术总结、分享成长,几个方向而进行的归纳、总结,避免同类事情的发生。复盘内容一般会包括技术方面的使用,例如:DB、应用开发、网关等,也包括业务领域逻辑的建设。
  • 复盘DB:
    1. 数据库连接数配置依照业务场景申请增加
    2. 禁止使用复杂嵌套和函数类等做业务查询
    3. 防重逻辑字段加强避免造成不能防重问题
    4. 索引字段初始化检测以及慢查询问题优化
  • 复盘业务:
    1. 对于所有营销类场景的设计需符合标准流程,缓存使用的一致性问题
    2. 资金流水结算方面在防重复设计上加强验证,测试环境模拟多样场景
    3. 对于外部支撑系统的依赖按照业务体量发展,进行通知压测报告流量
    4. 所有核心功能流程加强研发侧代码评审质量,并不断按照发展量优化
    5. 研发侧代码质量提升定期复盘问题以及优化,通过锻炼不断加强质量
    6. 在研发提测、修复、上线流程注意开发分支,避免错乱合并产生问题
    7. 所有的业务流程配置监控与图表并打印日志,方便及时追踪线上异常
    8. 核心场景的全链路压测可以有效的保证质量,也可很好降低流量风险
  • 复盘功能:
    1. 功能逻辑封装优化,缓存、线程、验证
    2. 日志完整性校验,入参、出参、异常
    3. 调用外部接口的超时时长设定以及重试约定
    4. 异常展示的紧急问题,测试环境复现追溯
  • 复盘部署:
    1. 按照压测标准部署服务
    2. 核心业务双机房三机房
    3. 非核心业务隔离RPC接口配置
    4. 按需调整JVM、连接数、日志等参数
  • 复盘接口:
    1. 功能验证的完整性
    2. 异常流程的复测性
    3. 数据指标监控范围
    4. 新上线后定期检测

综上,可能仅仅是对某一次项目的总结性复盘,便于新人接受和理解项目的重点内容。如果团队中能及时有效的汇总技术并落地资料,可以非常有效的做好技术传承。

# 六、总结

  • 互联网中一般中大型项目的开发过程,涉及的流程一般较多,也需要合理的把控。否则可能会出现一些过程中的风险,导致项目不能如期上线。当然也并不是所有项目都需要这样处理,例如一些小功能的迭代和简单需求的开发,可以简化流程,快速迭代。盖茅坑、猪圈、三居室还是不同的,不能一概而论
  • 做好技术分析、复盘、总结、归纳,沉淀出的技术资料非常有价值,既可以把项目开发经验传承给新人,也可以让所有人做好各自的技术成长。并且通过复盘和总结,又可以提炼出更多新的思路和提升技术氛围。
  • 好了,本章就总结到这,可能对具体的你或者具体的公司,会有不同的视角和结果。如果有一些好的点可以互相讨论学习。另外最近学会了个新东西分享给大家:内卷的反义词是:外包,合同的反义词是:离异!