“前端”工匠系列（一）：合格的工匠，究竟该搞什么

“前端”工匠系列（二）：合格的工匠，怎么做好价值落地

此文为系列文章第一篇，为浅尝辄止的引入，目的是为了让前端从业人员及非从业但是对此领域感兴趣的人对于”前端“是干什么的这个话题有个无门槛的了解。

“前端职能是什么”

说起"前端"，维基百科对这个技术角色的定位是“前端（英語：front-end）和后端（英語：back-end）是描述进程开始和结束的通用词汇。 前端作用于采集输入信息，后端进行处理。 计算机程序的界面样式，视觉呈现属于前端。”对于当下服务于互联网各企业的前端研发人员来说，这个岗位定义是很清晰的。前端是个对于后端的相对概念，它的岗位角色更应该关注“采集和呈现”两个部分。

从以上的概念来看，前端研发的正常职责是通过编码工作对数据及业务逻辑进行展示，用户通过操作界面（或其他交付方式）与系统进行交互，最后用户的交互信息可以按照功能逻辑的预期传输到后端服务递交给业务后端及更下游的算法层处理。

“编码工作包括什么呢？”

前端研发人员工作对接的上游干系人包括产品和 UI 设计，必要输入有产品文档和 UI 设计稿件，下游干系人为后端研发人员，必要的输出为一整套界面交互及逻辑处理实现代码。

产品要向研发团队输出 PRD（产品需求文档 Prodcut Requirement Document 的简称）来对此次产品或者迭代的具体的功能细节进行详细的描述，通过需求评审会议的方式与研发人员和设计人员进行“语言的互通转换及翻译”工作，得以把所有的产品逻辑向不同专业人员表达清晰，这是一切需求交付最重要的环节。对于新增的或者复杂的需求，需要有交互设计人员与产品人员共同输出交互设计稿件，从另外一个维度对产品需求逻辑进行阐述，对于前端研发人员对于需求理解的清晰程度来看，交互设计稿件的严谨和质量十分重要。

UI 设计人员需要根据产品需求文档和交互设计稿件对界面的 UI 风格、色系及动效等素材进行设计画制作，向研发人员输出 UI 设计稿件，此项工作需要前端研发、产品和设计人员进行多轮沟通以便敲定所有元素细节。UI 设计稿件的设计质量和对产品逻辑的描述精细度，直接对前端研发人员的编码设计方式和效率产生影响，前端研发人员必须对 UI 设计稿件有足够的重视，避免在实现过程中反复与产品和设计人员对设计稿件的细节进行确认甚至重新设计。如果这种情况出现，势必对项目的排期产生影响。最后，前端研发的界面输出要通过 UI 设计人员的验收测试才算完成界面编码工作。

与后端研发人员的对接是研发工作中的重中之重，最终，一整套前后端研发人员公认的经过冒烟用例自测的代码包才是此阶段的合格产出物。接口规范、约定习惯以及默契度较高的对接伙伴，都是业界不断在研发调试、联合调试以及提测冒烟过程中提效降本的思路。“一切都是人的事”“约定大于习惯”这些对软实力、流程的严谨程度都提出了要求。

研发流程中最后的步骤是 UAT 验收后上线。上线一定要采用“流水线自动化”的方式才行，也就是大家常说的“CI/CD”。只有这样做，才能保证主干版本代码与线上代码版本完全保证一致，不会因为人为把自己本地代码编译打包后发布到线上，导致主干分支成为摆设；所有上线相关的合并、编译、打包、发布等核心流程都是流水线自动跑事先部署在流水线各个节点的脚本，才能避免人为操作“失误”导致的线上问题。

“上线了？”

上线是个很值得探讨的话题，因为对于研发来说，只有上了线并且发挥了预期或者超预期的业务价值的代码，才算是对企业、对社会有一点点贡献，个人的价值才能在工作中得以体现。上线完成就是研发工作的结束吗？对于很多研发团队来说，这就是最后一步了。但是，研发流程仅仅止步于此，是不符合“合格”这个标准的。一套代码，只有在上线后，才开始受到真正用户的亲测使用，研发人员的产出物才算是“生命开始”。产品功能在用户的使用中“表现是否符合预期”、“是否有边界异常”、“是否存在打不开页面的情况”、“是否存在显示异常的情况”，诸如此类的问题，都应该是产研需要关注的话题。

因此，研发人员需要预先在代码包中预留与线上真实用户“交流”的抓手，通过分析用户在“可用性和性能”做出可以提升用户体验的改进措施，例如，“特殊逻辑自定义埋点上报”、“边界兜底监控”、“系统运行时监控”等，只有做到了这些，才能说对一个用户功能的真正上线，后续也才有精细化运营的可能。可是，对于很多研发人来说，“上线即需求的终点”、“线上问题由业务反馈”、“有客诉吗？”都是研发普遍存在的心理。

那如何通过“预先”的方式建立与用户之前的沟通通道呢？因为此文为前端领域文章，所以我们此次只说前端部分。

“与用户交流”

有效的交流是需要以有效的信息为载体的。对于技术实现来说，就是对核心代码块进行合理的代码埋点。当特殊用户行为发生时，当代码处理逻辑走向了一个非正常的处理单元时，当发生了代码处理逻辑没有覆盖到的情形时，埋点上报代码就会触发执行，向中心化的埋点服务发送消息。技术人员通过对此次用户行为触发的埋点信息的分析，从而得到用户在浏览或操作页面过程中的“正常或异常”情况的“现场复现”，当然，这种复现可以是数据信息，也可以是截图或视频回溯，具体要用什么方式来复现用户行为，要以“有效”为目标，综合考虑“用户流量成本、研发成本、性能影响以及存储成本”等因素来最终选型。

“实时 OR T+1”

对于业务前端用户行为及触发逻辑的监控，有实时监控和异步监控两种。

在实时关注用户行为、实时分析等场景里，需要使用实时监控，这个“实时”，一般到秒级就够用了，一些业务使用分钟级也是可以的，具体看业务的需要。对于实时监控，上报行为是从每一台用户的设备上触发并上报的，应用于大体量业务来说，这个数据量的采集、上报、收集、存储、分析和报表的生成，都是相当耗费资源的。为了降本提效，埋点服务首先会对用户数据按照特殊的规则（比如正态分布）进行一层比例的抽样，降低分析及报表生成过程中对资源和人力的消耗。

在用户端日志查询、特殊边界场景复现、日志排查定位故障等场景，“实时”就不是必要的，这种场景下一般采用 T+1 查询，但是又引入了大量级日志的存储周期的话题，一般企业应用级的用户日志保存 14 天就完全够用了，因为对于 C 端日志来说，更多的是对现场故障的复现、处理及跟进，如果算法策略对用户日志有需要，只需要在一定时间内采用处理任务对用户日志进行一次处理，把输出的标签、行为特征等关键数据存储就可以，基础的用户日志还是应该被存档或清除释放资源供给更有价值的最新日志来使用。

综上所述，实时监控和非实时监控分别应对两种场景：实时对应“业务可用性、线上运行时异常”等使用诉求，非实时对应“性能指标、用户日志查询、用户行为复现”等使用诉求。

“后续”

之后会继续讲述一些有关"用户体验、效率提升、页面搭建"相关的话题。