前端业务开发流程的哲学

671 阅读10分钟

前面的上、下两篇用了较长时间整理,这里合并一下。

先强调一下:我只待过国内公司,这只是我的个人经历。

笔者在工作过程中,接触下来,每一个开发小伙伴都有各自的开发流程。

本文,希望能够成为“最佳实践”

home (1).png

一、常见的开发模式

在在整个软件开发生命周期中,“研发”只是其中一个阶段;而在“研发”阶段中,又包括了许多与研发相关的流程;在这些流程中,包含了前端开发的流程。

从项目管理的角度来看,前端开发只是一个很小的环节,甚至有些领导“不知道”有专门的前端岗位。然而,经过多年的前端开发工作经验,包括游戏开发、后台系统和H5项目,我发现,在业务开发中,前端的工作量非常大(其他岗位边界更加清晰一些,在整个研发流程中,看起来有很多事情做,实则不然)。

尽管如此,在展示研发成果时,前端开发显得很被动,展示内容也比较少,特别是面对不懂技术的人。外部人员通常更喜欢听到诸如“数据”“安全”“云计算”“分布式”等词汇,对于前端工作的认可较少。这也应验了一句话:“管理流程的人看起来更重要,事情更多;执行细节的人看起来微不足道,产出也少。”

本文中,我会讲在一个常见的团队中,包含产品经理,UI/UX,前端研发,后端研发,测试等岗位,前端开发流程的方法论。秉持着“在粪坑中搞科研”的精神,总结这些年的心得。

1. 瀑布/迭代模型

瀑布模型强调在所有准备工作完成后开始开发;迭代模型则强调“循序渐进”的开发模式。这两者都是线性的开发模型,笔者经常会听到“迭代”这个词。

2. 敏捷开发

敏捷开发是一种灵活的开发方法,强调迭代和持续反馈。它是一种方法论,可以应用到所有能够提升效率的开发模型中。通过短周期的迭代,团队可以不断调整和优化产品,快速响应需求变更。这种方法特别适用于需求动态变化的项目。笔者也接触到许多自称“敏捷开发”的团队。

3. 玄学/其他

有些项目的开发模式难以定义,通常是由老员工或老板制定的,后来者必须适应前者留下的方式。

笔者认为,线性的开发模式对“细节执行”的岗位是有利的,它会明确执行者的上下文和边界,给予执行者“保护”;而非线性的开发模式对执行者是不友好的,会将人性的丑陋暴露出来,体现出人性的“反复无常”。

综合来看,“迭代”开发对于研发同学比较有利。

二、前端开发流程

假设,团队里面只有老板与前端,我们可以“多快好省”的实现老板的目标:产品我们直接从老板(客户)口中获得,UI我们根据UI库提供的组件来实现,数据我们自己来管理。但是,当团队出现了其他岗位以后,所有的事情都变了。我们不能“最大化”的为老板做贡献了,他们成了“魏忠贤”。

1. 前端的视野

在常见的敏捷团队中,前端的视野是这样的:

很明显,前端在开发过程中,属于最下游。

2. 笔者的开发流程

基于最下游的地位,对于拿到一个功能后,笔者的开发流程是这样的。

  • 第一步:实现前端骨架(如同”react编程哲学“那样),包含各种嵌套关系,各种静态展示;
  • 第二步:mock后台数据,填充;
  • 第三步:根据UI稿完成样式,如果有”基础组件“变动,比如 组件库里面的button(设B)与UI设计稿上的button不一致,可能会有两种处理方式,一种自己写一个简单的,丢失了很多交互以及样式,另一种是直接拿组件库里面的button来修改;
  • 第四步:根据后台接口数据进行调整,有时候有些状态可能在接口里面不存在,需要各种状态拼接;
  • 第五步:自测,完善UI,完善交互;
  • 第六步:联调
  • 第七步:产品、UI验收
  • 第八步:修复问题
  • 第九步:提交测试

这几步中,第三步、第四步非常不可控。他们来源于别的岗位,别的人,而他们在做的时候可能会很少考虑到前端实现组件所需要的物料。

在无法push别的岗位的情况下,我们只能调整自己的开发步骤,跟别的岗位battle来获得自己需要的物料。

因此,需要前端调整自己的开发路径,让编码过程可以被可控。

先跟UI同学沟通,是为了保证不需要重新开发组件,防止UI同学自由发挥;

然后与后端同学沟通,是需要让后端同学能够写出符合UI组件需求的数据结构,减少因为后端数据没有”适配UI“产生的不必要的心智负担;

当然,上面所有的只是一个”假设“,有很多情况需要根据具体情形进行调整。

3. 理想的模型

一个相对理想的模型是这样子的:前端可以关注最少得点,心智负担降到最低

这里的关键是:组件库。

UI/UE在设计的时候,就要考虑通用的UI组件,而不是自由设计;

后端在给前端提供数据的时候,也要考虑组件需要的数据结构,而不是直接简单数据库数据拼接;

虽然上面对比第一幅图貌似前端关注点只减少了一根,但是后端、UI/UE提供的物料,对前端友好

这里,UI/UE与后端同学可能都“不愿意”被前端组件影响到,需要用些时间来对齐思想。

这个时候的开发步骤,就可以重新梳理:

红色背景的框里面的步骤基本上占用的开发时间相对可控,而且较短,前端可以不太”受制“外部的印象,关注点集中于prd功能的实现。

需要强调一下,前端组件库对于后台管理系统来说,至关重要!或者说,是第一位的重要!

三、“敏捷开发”下前端做的事情与他人的事情

看到的大多数技术博客都是前端技能点相关,很少有看到系统的关于前端开发流程的分析与研究。

1. 业务的开发流程

首先明确一点,我这里描述的是一个敏捷小组,包含人员有限,可以独立完成一个项目。这里之所以从业务的开发流程说起,是因为对于整个项目的流程属于更大的范畴,需要更多的人,甚至包含老板,因此,只能将范围约定到业务范围里面。对于整个项目,

当然,有人说,“前端没有业务”。

业务的特征:

  1. 可以被交付给客户的;
  2. 满足客户单个需求的;
  3. 可以在一个短期时间内完成的;
  4. 明确边界与范围;
  5. 可以被量化的;

对于单个业务,从项目的视角来看,开发流程如下图所示:

从前端的角度来看,如下图:

2. 前端需要做的事情

从上图中,我们发现,前端处于产品、UI人员的下游,后端人员的中下游,处于测试人员的上游;在提测阶段与测试人员互为上下游。

前端需要根据别的岗位的要求,完成:

  1. 需要根据产品文档,产出符合功能要求的软件产品;
  2. 需要根据UI人员的设计稿,产出样式合格的软件产品;
  3. 需要根据后端人员的接口返回数据,来填充软件的展示数据;
  4. 为测试人员提供可测试的版本,根据测试人员反馈的问题,来修改或者修复软件。

3. 前端难么

在许多人看来,前端开发并不难。这种误解源于大家在思考业务时,通常采用“流程控制”的思维方式来表达复杂性。以制作香烟为例,可能会被描述为:

  1. 制作过滤嘴;
  2. 制作烟草部分;
  3. 拼合在一起。

这种思维方式适用于状态流转非常确切的场景,如后端开发。然而,前端开发的过程更加复杂。通常,上面的3步只是前端开发需要首先实现基础结构。

在此基础上,还需要对美观性、舒适性等方面进行大量完善。而这些方面,客户和其他角色往往忽视,或者认为是理所当然的。对于客户能直观看到的事物,一般人会认为“不难”。

需求方通常认为,美观、舒适等细节简单且易于实现,因此这些内容常被忽略。人们有“抓大放小”的本能,但正是这些细枝末节需要前端开发投入大量时间来完善。

总结以下几点:

  • 前端开发的基础结构部分确实不难,因此其重要性常被低估。
  • 然而,在美观性和易用性方面,前端开发需要投入大量时间和精力,这些地方会产生许多细节和不可预知的情况。

此外,前端开发者在处理大量细节时,通过脑力难以全面感知和衡量。经验表明,在业务需求开发上,前端代码复用性较低。例如,第一次开发登录功能可能需要3个工作点,第二次开发即使流程一致,也仍需3个工作点。

综上所述,尽管前端开发在基础结构部分并不复杂,但在细节完善上需要大量时间和精力,这一点常被忽视和低估。

4. 前端,请提出你的要求

很少看到前端开发人员对“上下游“提出过要求,明确界限。

首先,我们看一下前端在一个迭代计划里面的完整生命周期

可以看到,真实的开发周期需要很多节点。每个节点,我们都要对合作岗位提出自己的 合理要求。这里,我罗列一下每个阶段,前端对于合作岗位的要求,以及前端在当前阶段需要做的事情。

由于流程太长,我这里用一张Excel生成的图片来说明(点击放大)。

前端开发流程的哲学.png

表格链接:【腾讯文档】前端开发流程的哲学 docs.qq.com/sheet/DWnR1…

总结

作为开发人员,要明白自己的定位,要明白开发的流程;

作为前端开发,一定要有自己的原则,明确自己的边界,明确他人的定位;

作为“底层”,一定要讲规则,有效利用规则,可以“保护”自己;

对于其他岗位,一定要“严格要求,宽于落地”;按照上面各个阶段对其他岗位的的要求,去要求其他岗位;提前把规则确立好,弹性的去验证“对于他人的要求”,“严于立法,选择执法”,这样才能让自己的工作更有效,才能做的更长久。

最终,前端开发在敏捷开发中的作用将更加突出,工作流程也会更加顺畅,有助于提升整个团队的开发效率和产品质量。