213 lines
6.1 KiB
Markdown
213 lines
6.1 KiB
Markdown
### **0到1级：初步了解**
|
||
|
||
**学习&训练**：
|
||
|
||
1. **基础知识学习**：
|
||
|
||
- 阅读模块的文档、技术手册。
|
||
|
||
- 学习模块的核心概念、架构图和基本工作流程。
|
||
|
||
2. **代码层面了解**：
|
||
|
||
- 阅读模块的核心代码，理解关键函数和数据结构的功能。
|
||
|
||
- 通过代码注释和文档，了解代码的组织结构和调用关系。
|
||
|
||
3. **简单操作练习**：
|
||
|
||
- 运行模块的单元测试（UT），观察输出结果。
|
||
|
||
**证明方法**：
|
||
|
||
1. **代码阅读报告**：
|
||
|
||
- 提交一份代码阅读报告，描述模块的核心代码结构和关键函数的作用。
|
||
|
||
- 报告中需包含对代码逻辑的理解和疑问。
|
||
|
||
2. **操作报告**：
|
||
|
||
- 提交一份详细的操作报告，包括UT编译运行和结果确认。
|
||
|
||
- 报告中需包含遇到的问题及解决方法。
|
||
|
||
3. **展示讲解**：
|
||
|
||
- 向团队展示模块的基本功能和代码结构，并解释其工作原理。
|
||
|
||
- 回答关于模块基础知识和代码逻辑的提问。
|
||
|
||
|
||
---
|
||
|
||
### **1到2级：熟悉**
|
||
|
||
**训练&实践**：
|
||
|
||
1. **任务实践**：
|
||
|
||
- 独立完成模块的常见任务（如：修复一个已知Bug、添加一个小功能）。
|
||
|
||
- 参与模块的日常维护工作（如：代码合并、上库）。
|
||
|
||
2. **问题定位训练**：
|
||
|
||
- 分析模块的日志，定位常见问题的根因，并记录分析过程。
|
||
|
||
- 使用调试工具逐步排查问题，并撰写问题排查报告。
|
||
|
||
3. **回溯分析**：
|
||
|
||
- 研究模块的历史问题（如：Git提交记录、Bug跟踪系统）。
|
||
|
||
- 分析过去解决问题的思路和方法，总结规律，并撰写总结文档。
|
||
|
||
4. **理解依赖和限制**：
|
||
|
||
- 学习模块的上下层依赖关系，理解模块在系统中的作用。
|
||
|
||
- 了解模块的技术限制（如性能瓶颈、资源消耗）和业务限制（如需求变更、时间压力）。
|
||
|
||
|
||
**自证明方法**：
|
||
|
||
1. **任务成果**：
|
||
|
||
- 提交一个修复Bug或实现功能的代码，并通过代码审查。
|
||
|
||
- 撰写任务总结报告，描述解决思路和步骤。
|
||
|
||
2. **问题排查报告**：
|
||
|
||
- 提交一份问题排查报告，详细描述问题的定位和解决过程。
|
||
|
||
- 报告中需包含使用的工具、分析方法和最终解决方案。
|
||
|
||
3. **展示讲解**：
|
||
|
||
- 向团队讲解一个历史问题的解决过程，展示回溯分析的结果。
|
||
|
||
- 分享自己在任务实践中的经验和教训，证明对模块的熟悉程度。
|
||
|
||
4. **依赖和限制分析**：
|
||
|
||
- 提交一份文档，描述模块的上下层依赖关系和技术限制。
|
||
|
||
- 在团队讨论中展示对依赖和限制的理解。
|
||
|
||
|
||
---
|
||
|
||
### **2到3级：高级**
|
||
|
||
**实践&分析**：
|
||
|
||
1. **复杂任务处理**：
|
||
|
||
- 参与模块的核心功能开发或性能优化，并记录开发过程。
|
||
|
||
- 解决模块中的复杂问题（如：并发问题、内存泄漏），并撰写解决方案。
|
||
|
||
2. **架构理解**：
|
||
|
||
- 深入研究模块的架构设计，阅读核心代码，并绘制架构图。
|
||
|
||
- 参与模块的设计讨论，提出改进建议，并记录讨论内容。
|
||
|
||
3. **回溯分析**：
|
||
|
||
- 分析模块中过去的高难度问题（如：性能瓶颈、架构缺陷）。
|
||
|
||
- 总结复杂问题的解决模式，并撰写技术文档。
|
||
|
||
4. **设计折衷与妥协**：
|
||
|
||
- 在设计和开发过程中，权衡不同的技术方案，理解每种方案的优缺点。
|
||
|
||
- 根据项目需求和限制条件，选择最合适的方案，并解释选择的理由。
|
||
|
||
|
||
**自证明方法**：
|
||
|
||
1. **复杂任务成果**：
|
||
|
||
- 提交一个复杂任务的代码，并通过严格的代码审查。
|
||
|
||
- 在团队中展示复杂任务的解决方案，并回答技术细节问题。
|
||
|
||
2. **架构图与设计文档**：
|
||
|
||
- 提交模块的架构图，并解释各组件的作用和交互。
|
||
|
||
- 撰写设计文档，描述对架构的深入理解和改进建议。
|
||
|
||
3. **展示讲解**：
|
||
|
||
- 向团队讲解一个复杂问题的解决过程，展示回溯分析的结果。
|
||
|
||
- 组织一次技术分享，讲解模块的架构设计和优化思路。
|
||
|
||
4. **设计决策文档**：
|
||
|
||
- 提交一份文档，描述设计决策的折衷与妥协，并通过团队评审。
|
||
|
||
- 在技术讨论中展示对设计折衷的理解和应用。
|
||
|
||
|
||
---
|
||
|
||
### **3到4级：专家**
|
||
|
||
**实践&分析**：
|
||
|
||
1. **技术创新**：
|
||
|
||
- 主导或参与模块的技术创新项目（如：引入新技术、重构核心代码）。
|
||
|
||
- 提出并实现模块的改进方案（如：性能优化、扩展性提升）。
|
||
|
||
2. **领导能力培养**：
|
||
|
||
- 带领团队完成模块的开发或优化任务，并记录项目管理过程。
|
||
|
||
- 指导其他工程师，参与技术决策和架构设计，并撰写指导文档。
|
||
|
||
3. **回溯分析**：
|
||
|
||
- 分析模块的历史技术决策，评估其成功或失败的原因。
|
||
|
||
- 总结模块的技术演进过程，撰写技术白皮书。
|
||
|
||
4. **全面掌握依赖和限制**：
|
||
|
||
- 从全局视角分析系统的依赖关系和限制条件，并提出优化方案。
|
||
|
||
- 在技术决策中，平衡短期需求和长期目标。
|
||
|
||
|
||
**自证明方法**：
|
||
|
||
1. **项目成果**：
|
||
|
||
- 提交技术创新项目的成果，并通过团队和上级评审。
|
||
|
||
- 展示项目对模块的实际影响（如：性能提升、成本降低）。
|
||
|
||
2. **领导能力证明**：
|
||
|
||
- 提交项目管理记录，展示任务分配、进度跟踪和风险管理能力。
|
||
|
||
- 通过团队反馈证明领导能力（如：沟通能力、决策能力）。
|
||
|
||
3. **展示讲解**：
|
||
|
||
- 向团队或公司高层讲解模块的技术演进和创新成果。
|
||
|
||
- 组织一次大型技术分享，展示模块的技术深度和未来方向。
|
||
|
||
4. **全局设计文档**：
|
||
|
||
- 提交一份技术白皮书，描述系统的依赖关系、限制条件和设计决策。
|
||
|
||
- 在技术评审中展示对全局设计的理解和应用。 |