RD：后端工程师( Back End Engineer)
定义：从职业角度来说，现在的后端模式，是面向数据开发，数据驱动；要想有效驱动数据，就要聚焦业务，能做业务串讲和分析，从面向逻辑到面向数据，提升后端接口开发效率；并能为自己的业务开发保证数据性能，当然，这些基础都需要高质量的抽象化构建你的后端应用。
⚖️ 履职规范
一、需求理解与评审
1. 参与需求研讨会议
场景：👀
在项目启动初期，与产品、前端技术负责人以及其他相关人员一起参加需求分析会议。产品详细阐述软件系统的功能需求、业务流程和场景等。后端开发认真倾听，从技术实现角度提出问题和建议，如数据存储结构的初步设想、类图、逻辑关系、接口设计的合理性等。
🦴 输入
这个阶段, 根据需求参与和讨论，应该就要开始聚焦输入输出，让业务和技术双向绑定，有一个相对基本的后端实施预案，应出具后端技术需求建议书，一方面给到产品组，一方面给到专业组。
2. 梳理业务逻辑和数据流转
场景：👀
在评审前后，如需求文档或技术方案讲解会上，后端开发能狙击业务漏洞和数据关系。协助和支撑产品规避逻辑 bug 和数据断裂的问题，以及思考提供给前端的数据处理。后端伙伴也要要有一个立体的意识形态数据逻辑呈现。
🦴 输入
这个阶段, 根据需求的一个梳理和评审，随着对业务深入的了解，可以有效串清范围内的业务流程，外部集成，数据关系，甚至后续的技术方案雏形等等。
🎗️ 输出
01-后端技术需求建议书
二、系统设计与架构
1. 架构规划与选型
场景：👀
根据项目的规模、性能要求、业务特点等因素，参与系统架构的规划和技术选型工作。对于不同的应用系统，可能需要考虑采用合理的架构模式，技术配置，结构调整，类库预设等。
🦴 输入
根据项目场景、诉求，以及专业小组的统管要求，项目高效协同开发的目的，对标组内架构。
2. 模块设计与接口定义
场景：👀
在架构确定后，需要对系统进行模块划分和设计。例如，在一个系统中，定义每个模块的职责、功能边界以及与其他模块的交互接口。同时，考虑模块的可扩展性和灵活性，以便应对未来业务的变化。
🦴 输入
根据项目项目的体量大小、复杂程度，以及未来的扩展性和不确定性需求对架构模式的要求和影响。
3. 数据库设计
场景：👀
根据系统的业务需求，设计数据库表结构。确定表的字段、主键、外键、索引等。以一个系统应用为例，设计用户表、关联关系表、动态表等。根据业务查询需求，为相关字段创建合适的索引，以提高查询性能。在设计过程中，要考虑数据的完整性、一致性和存储效率等问题。
🦴 输入
根据项目业务需求，专业组制定的数据规范，或者现有系统数据改进扩展，以及数据合理及安全的诉求等。
🎗️ 输出
02-后端技术架构选型说明书|03-模块与接口设计文档|04-数据库设计文档（模板化）
三、编码实现
1. 业务逻辑实现
场景：👀
根据基与原型梳理的设计文档，按照专业组内达成一致的 Java 开发规范语言实现各个模块的业务逻辑。确保代码的可读性、可维护性和可扩展性。
🦴 输入
要做到清晰的业务逻辑实现，就要根据是否用心梳理了需求文档，评审，做了模块接口定义设计，数据库设计，分类了业务规则，以及一些需要配置的信息，还有外部依赖库和框架等，都会是做好业务逻辑实现需要的必然输入。
2. 接口开发与实现
场景：👀
与前端和其他系统接口对接。例如，提供 RESTful API 供前端调用。在实现接口时，要确保接口的安全性、稳定性和性能达标。对接口进行输入参数验证，防止恶意请求和数据错误。对于敏感信息，进行加密处理。同时，优化接口的响应时间，提高数据响应的整体性能。
🦴 输入
明确接口的功能需求，包括接口应提供哪些服务、接收哪些输入参数、返回哪些结果等；接口设计文档，详细描述接口的结构、方法、参数、返回值等；如果接口需要与数据库交互，需要提供相应的数据库设计文档和数据库访问层代码等诉求和准备；
3. 代码质量保证
场景：👀
在编写代码的过程中，注重代码质量的把控。遵循团队制定的代码规范，进行代码的格式化、注释和命名规范。例如，对变量、方法和类进行有意义的命名，方便其他开发人员理解代码的含义。对关键代码逻辑添加详细的注释，解释其功能和实现思路。同时，最好进行代码的单元测试，用 JUnit 也好，忙的话可以考虑用 AI 插件 生成测试用例。确保每个函数和模块的功能都能正常工作，及时发现和修复代码中的缺陷。
🦴 输入
严格遵守小组内 java 开发规范，有点代码洁癖的追求；或者干脆点受标杆刺激，向之学习；好吧，若不能主动触发，咱被动触发，测试的质量反馈，项目或专业组代码检查、评审的要求等等。
🎗️ 输出
05-标准代码（接口定义，实现类，标准规范等）|06-apifox等接口文档|07-接口部署和配置说明|08-showcase1次通过|09-codeReview通过
四、性能优化
1. 系统性能分析与监测
场景：👀
在系统开发过程中和上线后，使用性能监测工具对系统进行性能分析和监测。例如，使用 Java 性能分析工具如 JProfiler 或 VisualVM，监测系统的 CPU 使用率、内存占用、线程状态等指标。发现系统响应变慢，通过性能监测工具发现是某个数据库查询操作占用了大量的 CPU 资源。
🦴 输入
根据需求文档明确的性能目标，比如响应时间，吞吐量，并发数等；JVM 版本及配置；标准库或第三方库使用情况；日志配置和预警及性能数据等等。
2. 代码优化
场景：👀
基于性能分析或小组内 codeMaster 的检查结果，对代码进行优化。例如，减少循环中存在不必要的计算。不要频繁执行的数据库查询语句，优化查询逻辑、添加索引等方式提高查询性能。使用合适的索引，提升查询速度。甚至编写和逻辑不符合规范，存在漏洞等等。
🦴 输入
编写的源代码、性能分析的数据，代码检查反馈的问题，质量检查的问题，以及代码分析工具，合并审查等等，这些输入都应该从专业组到 codeMaster 到执行人员。
3. 数据库优化
场景：👀
对数据库进行性能调优。包括数据库表结构优化、索引优化、查询语句优化等。例如，定期对数据库表进行碎片整理，优化表的存储结构。对于大数据量的表，根据查询需求合理创建分区，提高查询效率。在一个日志管理系统中，随着日志数据的不断增加，查询速度变慢，通过对表进行分区，按照时间范围进行分区管理，使查询特定时间段的日志数据时速度提高。
🦴 输入
编写的源代码、性能分析的数据，代码检查反馈的问题，质量检查的问题，以及代码分析工具，合并审查等等，这些输入都应该从专业组到 codeMaster 到执行人员。
🎗️ 输出
10-性能分析报告（代码/数据库/提炼的建议）
五、安全保障
1. 安全漏洞防范
场景：👀
在开发，注重安全漏洞的防范；避免脚本注入，密码篡改等其他验证漏洞问题出现。
2. 权限管理与访问控制
场景：👀
设计和实现系统的权限管理和访问控制机制，这基础的做透了的东西，就不赘述了。
🦴 输入
根据梳理的文档，代码逻辑，角色关系等，明确要输出的角色权限控制清单。
🎗️ 输出
11-集成系统接口设计表（梳理表）
六、系统集成与测试
1. 与其他系统集成
场景：👀
在我们的项目业务场景中，往往需要与很多其他现有系统进行集成对接。例如。后端开发需要了解其他系统的接口和数据格式，进行相应的接口开发和数据交互实现。比如泛微的 OA 了，财务的 K3 金蝶了，外部的平台系统了，内部的生产、物流、不同业务衔接的 ERP、SAP 了不一而足等等。
🦴 输入
根据需求文档，技术协议，业务梳理，甚至数据库设计，功能设计等等，应快速就聚焦到发生的协同关联关系的业务系统和数据流转诉求，不再赘述。
🎗️ 输出
11-集成系统接口设计表（梳理表）
2. 集成测试
场景：👀
参与系统的集成测试，与前端开发和测试人员一起进行联调测试。做好充分的自测和联测，showcase 一把过。在集成测试中，模拟真实的业务场景，检查系统各个模块之间的交互是否正常，数据传递是否准确。
🦴 输入
根据已完成的后端代码，结合标准化 showcase 和提测要求，以及前端闭环测试的诉求。
🎗️ 输出
12-showcase 申请单联名|13-提测申请单联名
3. 问题排查与修复
场景：👀
无论是 case 环节，打回的 case 清单还是提测到测试环境也好，出现问题后，按时间要求及时完成修复，并进行回归测试，确保问题得到彻底解决，避免反复。
🦴 输入
根据 showcase 也好，提测的 bug 单也好，或者是自己优化代码发现的也好，排查到了，就快速根源解决。
🎗️ 输出
14-showcase 解决进度|15-禅道bug 解决进度
七、项目维护与技术支持
1. 系统维护与监控
场景：👀
在系统上线后，关注和跟踪系统运行情况，快速解决生产问题，避免阻塞业务的生产或运行，关注客户群，业务人员在上线期间反馈的问题，bug 异常问题快速响应解决，跟测试回归闭环，生产环境的问题修复，不得私自发版，必须由测试及项目负责人确认，方可发版。
🦴 输入
根据客户群跟踪，客户各渠道信息反馈，如电话，微信，对接人等，以及优化过程中的发现的隐性问题。
2. 技术支持与问题解决
场景：👀
在验收以后，为客户和运维相关伙伴提供技术支持，解决他们无法处理的问题。当遇到系统故障或功能异常时，可以由运维伙伴跟进解决处理，但是如果一些技术性较强，关联性较强的复杂问题，需要原开发伙伴，协助解决问题，并将此按标准化要求，平滑交付运维团队。
🦴 输入
应该是运维跟踪，问题处理，解决不了反馈，或者客户直接联系反馈。
3. 技术升级与优化
场景：👀
随着业务的发展和项目产品化的沉淀，对技术进行升级和优化，这里我不提系统，而是站在业务侧，针对业务的拓展聚合，复用增效，抽象剥离，要预设的一系列业务服务化，以及技术升级准备和手段。
🦴 输入
这一块其实没有非常指向性的输入，而是一些被动的，需要发挥主观能动，根据项目建设以及对未来类似项目的业务技术预判，作为一些技术及业务专家方面的，有意识的一些准备，输入更多的其实还是关注项目发展的态势，组织资产沉淀的诉求等。
🎗️ 输出
15-运维交接资料清单|16-后端技术升级方案书
✨ 后端 Leader
后端负责人同样不再是长期陷入某一个项目中吭哧的写代码，而是需要梳理和赋能小组，基于小组动态调配和把控后端的输入输出，围绕部门整体要求下的，项目建设、专业提升及分享沉淀，以及标准化要求，培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
🦴 输入
可能是项目的刚需，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（项目疑难杂症，工作流，技术方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据项目计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-项目人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。