谁说明天上线，这货压根不知道开发流程！

一、前言

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

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

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

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

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

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

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

二、时间节奏

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

三、资源投入

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

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

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

五、项目复盘

• 级别：⭐⭐⭐⭐
• 事项：项目复盘
• 人员：面向研发和测试人员
• 描述：复盘可能会因为出现事故、技术总结、分享成长，几个方向而进行的归纳、总结，避免同类事情的发生。复盘内容一般会包括技术方面的使用，例如：DB、应用开发、网关等，也包括业务领域逻辑的建设。
• 复盘DB：
• 1. 数据库连接数配置依照业务场景申请增加

1. 禁止使用复杂嵌套和函数类等做业务查询
2. 防重逻辑字段加强避免造成不能防重问题
3. 索引字段初始化检测以及慢查询问题优化

 

• 复盘业务：
• 1. 对于所有营销类场景的设计需符合标准流程，缓存使用的一致性问题

 

1. 资金流水结算方面在防重复设计上加强验证，测试环境模拟多样场景
2. 对于外部支撑系统的依赖按照业务体量发展，进行通知压测报告流量
3. 所有核心功能流程加强研发侧代码评审质量，并不断按照发展量优化
4. 研发侧代码质量提升定期复盘问题以及优化，通过锻炼不断加强质量
5. 在研发提测、修复、上线流程注意开发分支，避免错乱合并产生问题
6. 所有的业务流程配置监控与图表并打印日志，方便及时追踪线上异常
7. 核心场景的全链路压测可以有效的保证质量，也可很好降低流量风险

 

• 复盘功能：
  1. 功能逻辑封装优化，缓存、线程、验证
  2. 日志完整性校验，入参、出参、异常
  3. 调用外部接口的超时时长设定以及重试约定
  4. 异常展示的紧急问题，测试环境复现追溯
• 复盘部署：
  1. 按照压测标准部署服务
  2. 核心业务双机房三机房
  3. 非核心业务隔离RPC接口配置
  4. 按需调整JVM、连接数、日志等参数
• 复盘接口：
  1. 功能验证的完整性
  2. 异常流程的复测性
  3. 数据指标监控范围
  4. 新上线后定期检测

 

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

六、总结

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

via https://segmentfault.com/a/1190000038793048