8

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

 3 years ago
source link: https://segmentfault.com/a/1190000038793048
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

作者:小傅哥

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

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

互联网中一个项目的上线会需要各个工种间的配合,以研发为视角上会承接产品需求,下会交给测试验证,最终完成项目交付上线。其实除此之外,还会有业务、运营、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. 数据库连接数配置依照业务场景申请增加
  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. 新上线后定期检测

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

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

七、系列推荐


博客:https://bugstack.cn
Github:https://github.com/fuzhengwei/CodeGuide/wiki


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK