关于前端:前端工匠系列二合格的工匠怎么做好价值落地-京东云技术团队

3次阅读

共计 3285 个字符，预计需要花费 9 分钟才能阅读完成。

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

出门左拐轻易抓住一个人问一下。这种偏自嘲类的观点，有点相似 ” 程序员的衣着必须是格子衫 ”、” 你们只会和电脑打交道 ” 这种自嘲。开心一下，无可非议。然而在玩笑之外，一个合格的技术人的心田要时刻谨记本人在一个企业内的价值所在，并一直的通过技术晋升来扩充价值，才能够在当下的环境中，集体价值与企业价值造成正向循环。那咱们此次就聊一聊，前端职能如何在不同的业务场景中落地价值。

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

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

首先，从粗粒度进行大维度的划分，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 端研发工作，做好业务反对后，想方法通过 ” 低代码 ” 或者 ” 零代码 ” 的形式进行更加高效、高质量的交付。

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

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

然而 B 端业务交付的低代码计划的选型，从人力的角度，只有做好数据和代码平安解决，采纳“搭建 + 外包”的形式是齐全能够应答的。

如果你在做商业化的 B 端产品的研发，那就要更加偏差产品诉求，一直的与产品、客户进行沟通调研，甚至要去现场沟通去发现用户应用产品过程中遇到的实在体验和性能问题，从而一直做好产品迭代和优化。“ 低代码 ” 和 ” 零代码 ” 的提效计划只能作为产品孵化的工具，但具体能不能用起来，就要本人评估了。

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

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

这里值得提一下的是埋点这个事儿，对于 C 端业务，须要有专门的工作来解决埋点工作，埋点工作的品质间接影响到性能需要上线后业务是否能够拿到正确的用户数据，进而做出业务的经营策略调整。所以，埋点品质这个工作的老本投入是必须的，也是应该受到研发团队器重的。否则，就会呈现，明明性能没问题，也没有客诉，然而，业务因为拿到了谬误的用户行为数据而不自知，却先入为主的认为本人的策略太 ” 哇塞 ” 或者太 ” 喔去 ” 的后果。如果依据谬误的埋点做出了谬误的决策然而不自知，对于业务价值的影响是微小的，更加重大的事，很久当前你发现错了，最佳业务的机会，早就白驹过隙，飞逝而去了。

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

你须要关注技术栈的选型、物料及组件建设、流动搭建平台、设计智能交付、多端编译、渲染引擎等离业务更远但离技术更近的话题，每一项都充斥了挑战，每一项达成都能给你更多的成就感。然而，因为离业务更远，就要防止 ” 自嗨 ” 的情景呈现，你要少一些年度布局，多一些技术用户的痛点调研行程的季度布局和 OKR，只有让本人的技术孵化落地到具体的业务场景中，你的技术价值能力得以体现。

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