RD：前端工程师( Front End Engineer)
定义：从职业角度来说，现在的大前端模式，前端开发工程师不仅仅要将跨平台的界面高质量还原，保证良好的页面性能和交互之外；还要聚焦业务，能做业务串讲和分析，从面向界面到面向业务，业务驱动转变的开发模式，进而最好可以去定义接口文档，提升前后端接口开发效率；并能为自己的界面开发提供性能优化，当然，这些基础都需要高质量的组件化构建你的前端应用。
⚖️ 履职规范
一、需求理解与评审
1. 参与需求讨论
场景：👀
在项目立项阶段，与 产品经理、后端开发 人员等一起参与需求会议。产品经理 介绍软件的功能需求和用户场景，前端开发认真倾听并提出与用户界面（主要流程和交互）相关的问题和建议。例如，对于业务系统，了解 业务呈现、功能交互，便于快速梳理前期准备工作，为后续开展的 技术选型，配置，甚至如何抽离页面组件 充分准备。
通过参与需求讨论，前端开发能够深入了解项目的整体目标和功能需求，从前端视角为产品设计提供可行性建议，确保后续前端开发工作符合统一标准，兼容 客户体验 和 业务逻辑。
🦴 输入
这个阶段, 根据需求参与和讨论，应该就要开始聚焦输入输出，让业务和技术双向绑定，有一个相对基本的前端实施预案，应出具前端技术需求建议书，一方面给到 产品组，一方面给到 专业组。
2. 理解业务逻辑和数据流程
场景：👀
在评审前后，如需求文档或技术方案讲解会上，前端开发能反讲业务逻辑和数据在系统中的流转过程。了解后端提供的数据接口和数据格式，以及前端如何展示和处理这些数据。比如，对于一个通用界面，明白用户操作的功能点，交互数据是如何从前端表单提交到后端，需要哪些字段和数据，数据类型大概什么样，又如何从后端 获取并展示 在系统界面中的，要有一个立体的意识形态界面呈现。
前端不是页面仔，不是螺丝工，只有清晰理解业务逻辑和数据流程，前端开发才能正确、主动、高效、主导的的构建用户界面，趋同于实现与后端的接口低成本联调的有效交互，保证数据的准确展示和字段的精确回溯，从而聚焦页面性能流畅等体验，对自己职业要求高点，标准高点，才能更好的为经营指标，为能效赋能。
🦴 输入
这个阶段, 根据需求的一个评审，深入的了解，不但可以有效串清范围内的业务交互，确定业务流程，功能模块，页面组件，数据模型等等。
🎗️ 输出
01-前端技术需求建议书
二、技术选型与架构设计
1. 前端技术选型
场景：👀
项目规划阶段，根据项目需求、团队技术栈和性能要求等因素，配置合适的前端技术框架和工具。例如，对于一个业务系统项目，考虑到项目规模和开发效率，要做哪些框架预设和准备，要设计和调整哪些业务组件，要预研哪些工具库，要裁剪哪些项目约定俗成的专业标准等等。
合理的技术选型准备能够提高开发效率，保证项目的可维护性和性能，同时也有利于专业协作和技术积累。不同的项目需求可能适合不同的技术方案，前端开发需要综合评估各种因素做出最佳选择，做好充分的准备工作，不要等业务砸下来了再吭哧吭哧，不一定是让你搭个脚手架才是准备工作，基于业务，高于业务。
🦴 输入
根据项目场景、诉求，以及专业标准化的统管要求，高效协同的目的，找参考做分析，讨论验证。。
2. 参与前端架构设计
场景：👀
与团队中的架构人员和其他前端开发人员一起，围绕专业组，设计和优化前端项目的架构。确定项目的目录结构、模块划分、组件通信方式、库包模块等。比如，在一个大型系统应用中，将前端项目划分为多个模块，每个模块对应不同的业务功能，细化模块之间定义和要求，上下螺旋，贯穿和完善专业组的标准。
良好的前端架构设计能够提高代码的可读性、可维护性和可扩展性，便于团队协作开发和后续功能迭代。前端架构需要考虑到项目的复杂性、性能要求以及未来的重构调整，以持续构建的思维，设计一个稳定且灵活的前端系统。
🦴 输入
根据项目项目的体量大小、复杂程度，以及未来的扩展性和不确定性需求对架构模式的要求和影响。
🎗️ 输出
02-前端技术架构选型说明书
三、页面开发与实现
1. UI 设计及原型实现
场景：👀
根据设计师提供的 高保真设计稿，统一的设计标准要求，精确还原设计稿，当然，原则上需完全跟设计稿保持一致，若在没有设计稿的前提下，按照统一的组件标准，跟原型保持一致，请务必抖掉上下游吐槽的，设计不如原型，前端实现不如设计的包袱和刻板印象。
前端开发的主要任务之一就是将设计稿转化为可交互的用户界面，需要尊重设计，尊重原型。同时，要关注客户体验，确保页面的美观性、易用性和性能流畅度。
🦴 输入
ui 提供统一规范的设计稿或者整理内审过后的产品原型，前端针对高精度还原，将相似的功能交互剥离出来，形成组件，快速构建出来可复用的前端界面。
2. 前端交互开发
场景：👀
为标准化的界面添加各种交互功能，当然，在这里你应该统一按照前端标准组件化的数据驱动，构建你的交互行为，交互的代码应按照前端开发规范来进行逻辑代码的编码，使其具备更好的可读性、可维护性、并给逻辑添加有效的注释。
交互功能是前端业务驱动，代码逻辑的核心部分。前端需要深入理解业务逻辑，用户行为和需求，用代码实现更自然的交互效果，为了便于别人更好的交叉和接手工作，甚至后续的运维，交互逻辑的注释，也是考究开发人员编码功底的一个体现。
🦴 输入
根据原型图交互逻辑，结合业务流程图，数据模型，以及前端标准化的业务组件等，有效输出精简的交互逻辑。
3. 与后端接口对接
场景：👀
理想一点来说，最好能前端提供界面数据呈现字段的数据结构，基于数据结构构建数据模型去匹配组件，当然，这样最好，但也不强制要求；但是，最起码你要符合和精益 restful 的接口规范，避免源数据污染，上传和接收冗余字段，构建健康的接口，精简接口数据获取和提交的逻辑。
前后端接口对接是数据交互和协同工作的关键环节，处理不好这个环节，接口联调就容易是一个黑洞。前端需要了解接口标准规范、请求方式、参数格式和返回值结构，确保数据的正确获取和发送，保证功能完整性和数据一致性；否则，就容易挤牙膏一样，一步一卡，要不呢，前端花大量时间对标字段，寻找数据，处理数据，导致最后提交的数据也是乱七八糟，这里还要反向的根据场景，对后端明确数据要求，但是你连数据格式和模型自己都没概念，你能要求个毛啊。
🦴 输入
最后根据接口文档，再则是原型界面的 数据格式呈现要求，以及充分 mock 自测好接口交互。
🎗️ 输出
03-符合统一标准的组件化前端界面|04-带有清晰逻辑的交互注释|05-符合restful的接口处理
四、性能优化
1. 页面加载优化
场景：👀
分析 页面加载过程中 的性能瓶颈，采取相应的优化措施。例如，压缩和合并 CSS、JavaScript 文件，减少文件大小和请求次数；优化图片的加载，使用合适的图片格式（如 WebP）和压缩工具，降低图片的加载时间；使用懒加载方式，延迟加载页面中不立即显示的内容，包括交互中的频繁操作按钮请求接口的，节流，防抖，还有动态加载等等。通过一系列优化意识，可以显著提高页面流畅度和性能。
前后端接口对接是数据交互和协同工作的关键环节，处理不好这个环节，接口联调就容易是一个黑洞。前端需要了解接口标准规范、请求方式、参数格式和返回值结构，确保数据的正确获取和发送，保证功能完整性和数据一致性；否则，就容易挤牙膏一样，一步一卡，要不呢，前端花大量时间对标字段，寻找数据，处理数据，导致最后提交的数据也是乱七八糟，这里还要反向的根据场景，对后端明确数据要求，但是你连数据格式和 数据模型 自己都没概念，你能要求个毛啊。
🦴 输入
根据良好的 专业素养，职能要求，本着为输出和交付负责的敬业态度，矫情点说体现自己专业赋能也罢，免得最后被测试也好，产品也好，甚至客户，吐槽，这写的神马玩意，卡塞的一批。
2. 代码性能优化
场景：👀
在开发过程中，注重代码的性能优化。避免编写复杂的嵌套循环和过多的不必要计算，优化函数调用和算法实现。例如，让代码更加精简，逻辑更加清晰，克制各种骚包炫技的回调和闭包等，避免 cv 大法下大量无效的面条代码等等。
高效的代码性能可以提高页面的响应速度和整体渲染效率，减少浏览器的负载和资源消耗。前端开发需要具备良好的编程习惯和性能优化意识，不断改进代码质量，有辣么一些代码洁癖和追求 Write Better Code 好不好，并且有标准版本记录可以回溯。
🦴 输入
根据开发规范，以及专业组 和 Code Master 的检查，测试及协同伙伴的反馈。
🎗️ 输出
06-代码走查评审单|07-标准的版本管理及代码提交记录
五、测试与调试
算了，单元测试我就不要求了，以后做自有产品化再说。
1. 集成测试与联调
场景：👀
在前端页面与后端接口集成后，进行集成测试。模拟客户的实际操作流程，验证前端与后端之间的数据交互和功能协同是否正常。与后端开发人员一起进行联调，及时解决接口数据格式不一致、请求响应异常等问题。例如，在一个功能的测试中，检查前端是否正确将数据发送到后端，后端是否返回正确的结果，并确保前端相应的页面跳转和提示信息展示。
集成测试和联调是确保整个系统功能完整性和稳定性的关键环节。通过与后端的协同测试，可以发现并解决前后端集成过程中出现的各种问题，保证系统在测试及生产运行环境中的正常，具备 showcase 发起提测条件。
2. 调试测改与问题索查
场景：👀
在开发和测试过程中，当出现错误或异常情况时。通过查看控制台输出的错误信息、调试脚本代码、分析网络请求和响应等方式，定位问题的根源。例如，当 showcase、提测、bug 反馈过来的时候，前端开发需要如何快速锁定问题，解决问题，并且去深入索查关联和潜藏问题，高效解决问题，避免开发和测试之间的来回拉扯。
调试测改是前端开发能力体现的核心的技能之一。在面对各种复杂的问题时，能够快速准确地定位和解决问题，保证项目的顺利进行。熟练掌握方法、工具和技巧可以更好的提高开发效率，提升质量保障,减少问题沟通及解决时间。
🦴 输入
根据开发计划，项目经理的任务分工，截止日期，前端快速完成前后端的联调自测，按照测试的要求，发起 showcase 和提测申请。
🎗️ 输出
08-showcase 申请单|09-提测申请单
根据输入并将输出物同步抄送至钉钉研发群里，让协同和职能角色更清晰的了解到项目的进度和质量情况。
六、团队协作与知识分享
1. 与项目成员有效协作
场景：👀
在项目开发过程中，为项目负责，与产品、设计、后端开发人员等有效而密切的合作。与产品沟通需求和变更预案；与设计确保 UI 设计的实现效果符合预期，沟通设计稿中可能存在的前端实现难度问题；与后端进行接口对接和联调，共同解决数据交互和系统集成过程中出现的问题；及时向项目经理反馈风险和应对建议。
软件开发是一个 TEAM协作的过程，前端开发需要与不同角色的人员进行有效的沟通和协作，共同推进项目的进展。良好的团队协作能够提高工作效率，减少误解和冲突，保证项目的质量和按时交付。
🦴 输入
根据项目经理指派的，执行的禅道任务 展开具体开发工作，做到及时维护，有效维护就离不开贯穿 为上游负责，为下游服务 的宗旨。
🎗️ 输出
10-禅道任务状态管理
2. 知识分享与技术交流
场景：👀
定期参加项目及专业组内部的技术分享会，分享自己在前端开发过程中的场景化的 开发经验和技术心得。向团队成员介绍新的前端技术和工具，共同学习和探讨 如何提升团队的技术水平。例如，分享自己在使用某个前端技术解决业务问题的的经验和技巧，或者介绍一种新的前端技术库的特点和应用场景。积极参与专业组内的技术交流活动，了解并学习前端技术的最新发展动态，将有用的收获反哺团队并应用到实际项目中。
知识分享和技术交流有助于团队成员的 共同成长和技术提升，既可以解决场景疑难杂症，也可以 拉通专业组的技术协同壁垒 ，更可以起到有效沉淀的作用。前端技术的场景化，业务化，专业化，通过分享和交流，团队成员可以相互学习，拓宽技术视野，提高团队的整体技术实力和创新能力，更好地应对项目中的各种技术挑战。
🦴 输入
项目中的专业技术难题，专业组的知识沉淀、技术分享指标，以及自己的技术成长心得，都可。
🎗️ 输出
11-知识分享成果上传语雀
七、交付运维与技术升级
1. 现有项目技术支持
场景：👀
在项目上线后，负责对前端代码进行技术维护，验收后交付运维提供技术支持。上线期间及时处理 质量跟踪小组 反馈的问题和缺陷，如页面加载缓慢、功能异常等。对代码进行优化和改进，以提高系统的性能和稳定性。例如，根据走查审计，或者问题处理过程中，自主的优化漏洞代码。
其实除了上线跟踪问题处理之外，核心更在于验收后，交付给运维伙伴的项目代码，是否能使运维人员平滑接手，使其有自主运维的能力，就在于上线跟踪，甚至从 项目开始到验收环节 对于代码标准化的编写，除却需求复杂化变更后，核心的技术难点问题，不应该遗留技术债务和心智包袱，这些其实都可以从交付的代码得以体现。
🦴 输入
根据运维交接清单要求，前端负责人及具体执行人，将前端代码、文档，串讲完整性的交付运维。
🎗️ 输出
12-前端代码交付清单及干系人确认签字
2. 项目升级与迭代
场景：👀
随着业务的发展和客户需求的变化，根据增补需求或长期运维协议，参与项目的升级和迭代工作。根据新的需求和设计，对前端页面和功能进行更新和扩展。前端开发根据新的设计要求，对功能进行 重新开发和整合，同时确保与现有系统的兼容性和一致性。在升级过程中，要注意对现有功能的影响，进行 充分的测试和验证，确保升级后的 系统稳定可靠。
为了保持系统的扩展性和适用性，部分项目可能需要不断进行升级和迭代，这时候，可能存在技术升级的方案，就需要具体的 开发执行人发起专业组决策方案。
🦴 输入
这一条的输入输出在交付项目中，或 不是必须，可根据实际的项目诉求，或者项目产品化的要求，预测未来产品规划，根据部门实际要求，再行预设和准备技术升级方案。
🎗️ 输出
13-运维交接资料清单|14-前端技术升级方案书
✨ 前端 Leader
前端负责人不再是长期陷入某一个项目中吭哧的写代码，而是需要梳理和服务前端，基于小组动态调配和把控前端的输入输出，围绕部门整体要求下的，项目建设、专业提升及分享沉淀，以及标准化要求，培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
那么作为组长，你要做人才识别，做一下小组的人盘盘点，你要有盘点的思路和章程，你对专业小组管理的理解，对同属性伙伴专业输出的识别，有一套方法论，基于这个方法论，针对动态的业务场景和公司战略需要，有人才分类匹配的依据，并且针对态度能力的融合，可以针对性的输出管理办法和考核标准，让大家知道需要把做的事儿，如何职业化的去做到什么程度，并把它的价值和能效体现起来，激活人才，凝聚一体，如臂指使。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
那么简单直白一点说，一线的管理动作是需要一些行为执行来拉通分工协同的，动作就是其中一个最直观的抓手；比如小组内部分享，识别擅长和偏好，优缺点，引导性和针对性的使成员共同成长；小组双周会，调动小组的集体力量和智慧解决点点滴聚焦的问题，以面破点，落地解决问题，体现赋能，也为后续的工作计划和人员调配有一个前置清晰的依据。
🦴 输入
可能是项目的刚需，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（项目疑难杂症，工作流，技术方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
要做到人员的有效调动，第一，对成员能力和项目匹配度有认知和判定；第二，能识别项目计划制定专业计划，避免人员空闲稀释成本和能效；第三，把控项目上专业人员的风险，有补台补位及预防措施，并确定末尾红线替换淘汰机制（比如任务完成度和输出要做到什么程度）若因为组人员调配，影响到项目组工作计划造成时间冲突的，需跟项目负责人和项目计划达成一致（计划识别和同步），有分歧上报部门调整优先级（尽量避免）。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据项目计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-项目人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
回归职场，职业发展的路径，公司团队发展的需要，内建都是核心，练武不练功，到头一场空，培养和晋升是相辅相成的，通俗直白一点说，你要晋升，就培养出来一个人来可以替代你现有，要把价值显性化，实例化，具象化，这才是管理的价值，赋能使能。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。