一、"技术鄙视链？"

如果你是一个技术人，相信都知道技术圈有个相互的鄙视链，这个链条从技术人自己认知的角度在以业务价值为中心嵌套的一层一层的环，就像洋葱，具体的描述这里不赘述了。

出门左拐随便抓住一个人问一下。这种偏自嘲类的观点，有点类似 "程序员的穿着必须是格子衫"、"你们只会和电脑打交道" 这种自嘲。开心一下，无可厚非。但是在玩笑之外，一个合格的技术人的内心要时刻谨记自己在一个企业内的价值所在，并不断的通过技术提升来扩大价值，才可以在当下的环境中，个人价值与企业价值形成正向循环。那我们此次就聊一聊，前端职能如何在不同的业务场景中落地价值。

二、"技术人，你有价值吗？"

说到业务价值，有一个关键词，就是 "特定的业务背景"。有人会说，技术就是技术，是通用的，为什么要把业务的概念引入到技术价值中呢？我对这个问题的回答也相当简单：技术本身没有业务属性，但是技术人所处的业务环境，从而决定了技术人此时此刻应该为环境提供什么类型的价值输出。

对于前端领域的岗位职责，如前文（《“前端” 工匠系列：合格的工匠，究竟该搞什么（一）》），“它的岗位角色更应该关注’采集和呈现‘两个部分”，这种职能定位就决定了它在具体业务场景中的价值定位。

首先，从粗粒度进行大维度的划分，B 端和 C 端来先划分一刀。国内外从岗位招聘、岗位定位到 OKR 制定、绩效评估，都要先从端类型来做最起码的区分，原因是 B 端和 C 端对于前端技术栈、技术深度及输出价值的要求都是不一样的，甚至 B 端的研发人员对于原生、多端等研发领域并不熟悉，如果有岗位的调整，会有一段比较长的技术切换期的，根据人员软素质的不同，这段时间从 1 个月到一个季度不等。

B 端研发是什么？

B 端通常指 “Business 端研发”，但当前很多企业对 B 端研发的岗位职能描述也包括了 A 端（即业务管理员 Administrator）的研发，这样囊括也是有道理的，A 端和 B 端的共同特点是大部分业务都是 “以 PC 浏览器为运行时环境，基于 Web 技术栈的企业级后台管理系统” 来运作、赋能具体场景。

至于 B 端研发人员的技术价值，根据业务领域不同，可以切为企业级应用（如飞书、腾讯文档）、商业化解决方案（toB、toG 的业务，比如一些企安类业务和商业化业务）、业务后台管理（辅助 C 端业务逻辑的管理后台）等细分方向，前者用于商业化变现，所以这些后台项目对用户体验有一定程度的要求，其他的 B 端业务对体验和性能的要求都是相对较低的。

C 端研发是什么？

C 端也称为 “客户端（Client）研发”，从技术岗位要求维度可以细分为端侧研发（IOS、安卓、鸿蒙）、H5 研发、小程序研发等。

很明显，维度划分的依据是代码运行容器，那么存不存在 “一次开发，多处运行” 的研发方案呢？这就产生了多端研发这个岗位角色，对应的技术栈是 React Native、Flutter、Taro 等为代表的解决方案，由于各自对多端的实现方案不同，导致了各自有各自的优劣势，具体的选型，要研发团队根据业务背景以业务属性（是否对特殊端侧有倾向）、团队成本、维护成本、研发效率、社区活跃度、未来技术栈的持久性等维度来做最合适的技术选型。

因为 C 端的输出直接面对用户，而且用户量级大，因此 C 端页面对于设计、交互、业务可用性、用户体验是否良好等专项指标都有很高的要求，因此，在技术型企业，一些企业对于其中的每个专项都会有一批人在做专门的优化提升处理。

以下分研发阶段对 C 端研发的关注点进行简述。

• 设计阶段：研发人员需要对设计稿件、UI 切图的合理性更加关注；
• 研发阶段：研发人员需要有更频繁、更合理、更清晰的代码注释；
• 提测阶段：提测前，研发人员需要保证用例冒烟质量，提测后，研发人员更加关注千行代码 bug 率这种质量指标；
• 上线阶段：研发人员需要保证上线流程的切实无人化、自动化和日志详细程度，因此，CI/CD 的上线流程中每个阶段的处理脚本都必须完全严谨和可用；
• 上线后：研发人员需要通过监控、告警和日志平台，对线上代码在用户设备端的运行状况进行监控。如果出现异常运行，研发人员需要及时被告警平台告知、根据 SOP 对线上故障进行合理处理及时止损，修复后 bugfix 上线；

以上只是简单论述了 B 端业务和技术对研发人员基本素质要求的差异。基于以上的业务背景，以下分别从技术角度、人力资源角度及团队能力设计的角度进行阐述怎么做好相应的工作。

三、"B 端，怎么做好？"

如果你在做业务交付类的 B 端研发工作，做好业务支持后，想办法通过 "低代码" 或者 "零代码" 的方式进行更加高效、高质量的交付。

具体的实现方案有很多，比如 AntDesign、FusionDesign 以及很多商业化的 Design 们，实现思路就是基于业务场景，建立一套通用的、可复用的物料组件，在业务交付的时候，只需要对物料进行拼装组建即可，有些想乐高积木，但是这种 Design 们对于应用场景的要求是比较高的，如果你想用这种方案（尤其是业务场景比较复杂，只能用低代码方案），就要进一步思考物料间的数据通信、UI 通信等问题，甚至需要随着业务物料的发展去迭代 DSL 解析引擎。

对于前端人员来说，启用初期的搭建的效率反倒是降低的，但如果用起来，用的越久，沉淀的物料就会越丰富、与场景的匹配度越高，交付效率也越高。但从成本的角度，一部分研发成本也会转嫁到后端服务的封装度提升、合理性提升，整个的业务交付就会向搭建驱动的角度倾斜，综合成本的降低需要结合整体研发交付的维度来考量，但如何考量、考量口径是否合理、是否可落地，每个研发团队就要 "八仙过海，各显神通" 了。

但是 B 端业务交付的低代码方案的选型，从人力的角度，只要做好数据和代码安全处理，采用 “搭建 + 外包” 的方式是完全可以应对的。

如果你在做商业化的 B 端产品的研发，那就要更加偏向产品诉求，不断的与产品、客户进行沟通调研，甚至要去现场沟通去发现用户使用产品过程中遇到的真实体验和功能问题，从而不断做好产品迭代和优化。"低代码" 和 "零代码" 的提效方案只能作为产品孵化的工具，但具体能不能用起来，就要自己评估了。

四、"C 端，怎么做好？"

如果你在做 C 端产品的交付，那你应该关注研发流程的顺畅度和合理性，研发环境、测试环境、预备发布环境以及线上环境的代码隔离、数据隔离、发布隔离是否良好，坚决避免环境污染导致业务异常或者工作量激增；

你应该关注 UI 设计稿件的还原度、动效效果是否顺滑、页面加载效率是否良好、Crash 率是否达标、埋点是否正常上报。

这里值得提一下的是埋点这个事儿，对于 C 端业务，需要有专门的工作来处理埋点工作，埋点工作的质量直接影响到功能需求上线后业务是否可以拿到正确的用户数据，进而做出业务的运营策略调整。所以，埋点质量这个工作的成本投入是必须的，也是应该受到研发团队重视的。否则，就会出现，明明功能没问题，也没有客诉，但是，业务因为拿到了错误的用户行为数据而不自知，却先入为主的认为自己的策略太 "哇塞" 或者太 "喔去" 的结果。如果根据错误的埋点做出了错误的决策但是不自知，对于业务价值的影响是巨大的，更加严重的事，很久以后你发现错了，最佳业务的时机，早就白驹过隙，飞逝而去了。

如果你在做 C 端基建工作，恭喜你，你可能已经离很多研发人员羡慕的架构师的岗位很近了。

你需要关注技术栈的选型、物料及组件建设、活动搭建平台、设计智能交付、多端编译、渲染引擎等离业务更远但离技术更近的话题，每一项都充满了挑战，每一项达成都能给你更多的成就感。但是，因为离业务更远，就要避免 "自嗨" 的情形出现，你要少一些年度规划，多一些技术用户的痛点调研行程的季度规划和 OKR，只有让自己的技术孵化落地到具体的业务场景中，你的技术价值才能得以体现。

五、"价值，价值，还是价值"

请各位技术人时刻谨记，如果你的代码不上线、如果你的代码没有经受住用户的使用考研、如果你没有关注代码上线后的质量和功能的相关告警、如果你不关注业务和用户行为数据，那你的工作价值就会大打折扣，甚至，没有价值，因为，你和一样工作方式的那个谁，对于业务的正常运转来说，没有区别。

来源：京东云开发者社区

作者：京东零售 刘伟东（未经授权请勿转载）