RD：后端工程师( Back End Engineer)
定义：从职业角度来说，现在的后端模式，是面向数据开发，数据驱动；要想有效驱动数据，就要聚焦业务，能做业务串讲和分析，从面向逻辑到面向数据，提升后端接口开发效率；并能为自己的业务开发保证数据性能，当然，这些基础都需要高质量的抽象化构建你的后端应用。
⚖️ 履职规范
一、需求理解与评审
1. 参与需求研讨会议
场景：👀
在项目启动初期，与产品、前端技术负责人以及其他相关人员一起参加需求分析会议。产品详细阐述软件系统的功能需求、业务流程和场景等。后端开发认真倾听，从技术实现角度提出问题和建议，如数据存储结构的初步设想、类图、逻辑关系、接口设计的合理性等。
通过参与需求研讨，后端开发能够深入了解业务需求，为后续的系统设计和开发明确方向，确保技术方案与业务目标紧密结合，同时也能提前发现潜在的技术难点和风险点，为项目的顺利推进做好应对准备。
🦴 输入
这个阶段, 根据需求参与和讨论，应该就要开始聚焦输入输出，让业务和技术双向绑定，有一个相对基本的后端实施预案，应出具后端技术需求建议书，一方面给到产品组，一方面给到专业组。
2. 梳理业务逻辑和数据流转
场景：👀
在评审前后，如需求文档或技术方案讲解会上，后端开发能狙击业务漏洞和数据关系。协助和支撑产品规避逻辑 bug 和数据断裂的问题，以及思考提供给前端的数据处理。后端伙伴也要要有一个立体的意识形态数据逻辑呈现。
业务流程和逻辑关系的严谨性，对于后端来说，是后续工作开展的核心条件，后端开发必须要求和验证，准确掌握每个功能点的细节，才能有效的输出。只有对业务需求有清晰的理解，开发过程中才能避免反复和沟通成本，构建清晰的健壮数据关系。
🦴 输入
这个阶段, 根据需求的一个梳理和评审，随着对业务深入的了解，可以有效串清范围内的业务流程，外部集成，数据关系，甚至后续的技术方案雏形等等。
🎗️ 输出
01-后端技术需求建议书
二、系统设计与架构
1. 架构规划与选型
场景：👀
根据项目的规模、性能要求、业务特点等因素，参与系统架构的规划和技术选型工作。对于不同的应用系统，可能需要考虑采用合理的架构模式，技术配置，结构调整，类库预设等。
合理的架构规划和技术选型决定了系统的可扩展性、稳定性、性能以及开发效率。后端开发需要认真对待，不是闷者头就一顿千行流，而是应该根据项目实际情况做出最佳配置，为后续的开发工作打下前置有效的基础准备。
🦴 输入
根据项目场景、诉求，以及专业小组的统管要求，项目高效协同开发的目的，对标组内架构。
2. 模块设计与接口定义
场景：👀
在架构确定后，需要对系统进行模块划分和设计。例如，在一个系统中，定义每个模块的职责、功能边界以及与其他模块的交互接口。同时，考虑模块的可扩展性和灵活性，以便应对未来业务的变化。
良好的模块设计和接口定义能够提高系统的可维护性和可扩展性。每个模块都应该具有明确的功能职责，模块之间通过清晰的接口进行通信，这样可以降低模块之间的耦合度，使得系统更容易理解和维护。同时，合理的接口设计也方便与前端和其他系统进行集成。
🦴 输入
根据项目项目的体量大小、复杂程度，以及未来的扩展性和不确定性需求对架构模式的要求和影响。
3. 数据库设计
场景：👀
根据系统的业务需求，设计数据库表结构。确定表的字段、主键、外键、索引等。以一个系统应用为例，设计用户表、关联关系表、动态表等。根据业务查询需求，为相关字段创建合适的索引，以提高查询性能。在设计过程中，要考虑数据的完整性、一致性和存储效率等问题。
数据库是后端系统的核心组成部分，合理的数据库设计直接影响系统的性能和数据管理能力。后端开发需要深入理解业务数据的关系和特点，设计出结构合理、高效可靠的数据库表结构，确保数据的正确存储和快速检索，为系统的稳定运行提供有力支持；比如数据库模式、数据字典、ER 关系图、数据流图、设置 SQL 脚本等等。
🦴 输入
根据项目业务需求，专业组制定的数据规范，或者现有系统数据改进扩展，以及数据合理及安全的诉求等。
🎗️ 输出
02-后端技术架构选型说明书|03-模块与接口设计文档|04-数据库设计文档（模板化）
三、编码实现
1. 业务逻辑实现
场景：👀
根据基与原型梳理的设计文档，按照专业组内达成一致的 Java 开发规范语言实现各个模块的业务逻辑。确保代码的可读性、可维护性和可扩展性。
业务逻辑的正确实现是后端开发的核心前提。后端开发要将业务需求转化为具体的代码实现，就要清晰的处理各种业务规则和流程，确保系统能够按照预期的方式运行。高质量的代码实现能够提高系统的稳定性和可靠性，减少潜在的错误和漏洞，尤其是返工和重构，以及脏补丁。
🦴 输入
要做到清晰的业务逻辑实现，就要根据是否用心梳理了需求文档，评审，做了模块接口定义设计，数据库设计，分类了业务规则，以及一些需要配置的信息，还有外部依赖库和框架等，都会是做好业务逻辑实现需要的必然输入。
2. 接口开发与实现
场景：👀
与前端和其他系统接口对接。例如，提供 RESTful API 供前端调用。在实现接口时，要确保接口的安全性、稳定性和性能达标。对接口进行输入参数验证，防止恶意请求和数据错误。对于敏感信息，进行加密处理。同时，优化接口的响应时间，提高数据响应的整体性能。
接口是后端系统与外部交互的核心，其质量直接影响系统的集成效果和用户体验。后端开发需要按照规范开发安全、可靠、高效的接口，满足不同系统和客户的需求，实现前后端以及不同系统之间的数据交互和业务协同；验证点包含数据结构，状态信息，异常处理，日志记录，消息传递，HTTP 响应等。
🦴 输入
明确接口的功能需求，包括接口应提供哪些服务、接收哪些输入参数、返回哪些结果等；接口设计文档，详细描述接口的结构、方法、参数、返回值等；如果接口需要与数据库交互，需要提供相应的数据库设计文档和数据库访问层代码等诉求和准备；
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. 技术升级与优化
场景：👀
随着业务的发展和项目产品化的沉淀，对技术进行升级和优化，这里我不提系统，而是站在业务侧，针对业务的拓展聚合，复用增效，抽象剥离，要预设的一系列业务服务化，以及技术升级准备和手段。
不应该无休止，无穷尽的 CURD，在开发建设系统过程中，基于业务的沉淀，技术配置、编码的复用，可能需要有意识的不断进行升级和优化。确保系统能够适应不断变化的环境和新的业务需求，是不是应该也有一些针对项目输出的可移植，复用的业务侧或技术侧的代码模块、库。
🦴 输入
这一块其实没有非常指向性的输入，而是一些被动的，需要发挥主观能动，根据项目建设以及对未来类似项目的业务技术预判，作为一些技术及业务专家方面的，有意识的一些准备，输入更多的其实还是关注项目发展的态势，组织资产沉淀的诉求等。
🎗️ 输出
15-运维交接资料清单|16-后端技术升级方案书
✨ 后端 Leader
后端负责人同样不再是长期陷入某一个项目中吭哧的写代码，而是需要梳理和赋能小组，基于小组动态调配和把控后端的输入输出，围绕部门整体要求下的，项目建设、专业提升及分享沉淀，以及标准化要求，培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
那么作为组长，你要做人才识别，做一下小组的人盘盘点，你要有盘点的思路和章程，你对专业小组管理的理解，对同属性伙伴专业输出的识别，有一套方法论，基于这个方法论，针对动态的业务场景和公司战略需要，有人才分类匹配的依据，并且针对态度能力的融合，可以针对性的输出管理办法和考核标准，让大家知道需要把做的事儿，如何职业化的去做到什么程度，并把它的价值和能效体现起来，激活人才，凝聚一体，如臂指使。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
那么简单直白一点说，一线的管理动作是需要一些行为执行来拉通分工协同的，动作就是其中一个最直观的抓手；比如小组内部分享，识别擅长和偏好，优缺点，引导性和针对性的使成员共同成长；小组双周会，调动小组的集体力量和智慧解决点点滴聚焦的问题，以面破点，落地解决问题，体现赋能，也为后续的工作计划和人员调配有一个前置清晰的依据。
🦴 输入
可能是项目的刚需，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（项目疑难杂症，工作流，技术方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
要做到人员的有效调动，第一，对成员能力和项目匹配度有认知和判定；第二，能识别项目计划制定专业计划，避免人员空闲稀释成本和能效；第三，把控项目上专业人员的风险，有补台补位及预防措施，并确定末尾红线替换淘汰机制（比如任务完成度和输出要做到什么程度）若因为组人员调配，影响到项目组工作计划造成时间冲突的，需跟项目负责人和项目计划达成一致（计划识别和同步），有分歧上报部门调整优先级（尽量避免）。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据项目计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-项目人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
回归职场，职业发展的路径，公司团队发展的需要，内建都是核心，练武不练功，到头一场空，培养和晋升是相辅相成的，通俗直白一点说，你要晋升，就培养出来一个人来可以替代你现有，要把价值显性化，实例化，具象化，这才是管理的价值，赋能使能。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。