12.团队管理
技术分享
比如帮助团队了解某个新技术或解决项目中的技术难点。然后，我会选择一个主题，比如最近项目中用到的性能优化方法，并准备结构化的内容，包括背景、核心原理、实践案例和总结。我会通过在线工具进行演示，并在分享过程中引导团队提问和讨论。最后，我会收集团队的反馈，改进我的分享方式，同时将内容整理成文档，方便后续查阅。
技术选型怎么做
- 在技术选型时，我会首先明确项目的需求和目标，包括功能需求、性能要求和团队的技术能力。
- 我会列出候选技术方案，会考虑项目的复杂性、团队的熟悉程度以及社区支持。
- 我会对比这些方案的优缺点，并进行小规模验证（POC），确保技术能够满足需求。
- 我会与团队讨论并达成一致，选择最适合当前项目的技术栈，同时为未来的扩展性留有余地。
如何做 code review？发现过哪些严重的问题？如何让 Code Review 更高效
流程是：两人及以上小伙伴的批准，每个合并请求指派人是团队小组长，review 是除小组长之外的另一个小伙伴，小组长和这个小伙伴都通过方可；
审阅： 实际工作场景会遇到一些开放式或紧急的提交，良好的 CodeReview 习惯自然是要严谨一些，讨论清楚再通过，并且要及时反馈。但某些比较紧急的提交就要区别对待了，更好的态度是在实践中灵活对待，但及时紧急通过了，也要保证问题在后续得以修复，比如在代码中留一些 “TODO” 或 “FIXME” 的标记，写上对应的负责人与预期解决时间；
代码自动化工具的目的，很大一部分也是为了保证代码一致性，从而降低 CodeReview 成本，也减少不重要的评论信息出现，让 CodeReview 尽可能反馈逻辑问题而不是格式问题。
具体：大部分问题通过 eslint 和 prettier 解决
- 代码质量与可读性（基础）
- 变量/函数命名是否清晰、语义化？是否使用了缩写或拼音？
- 是否存在 magic number？是否应该提取为常量？
- 注释是否必要、准确？是否用注释掩盖糟糕代码？
- 组件设计和封装粒度
- 是否符合“单一职责”？组件是否拆分合理？
- 是否存在 props 过多/重复逻辑/过度封装等设计问题？
- 是否有复用价值？能否提取为 hooks 或通用组件？
发现过哪些严重的问题？
- props drilling 过深 → 用 context 或状态管理；
- 使用了过时的 UNSAFE_componentWillMount → 建议迁移到 hooks；
- 把 UI 和数据强耦合 → 拆为 UI + 容器组件；
- 没有处理异常状态 → 增加 loading/error 状态。
如何让 Code Review 更高效 细节建议请写清楚 rationale（原因），比如：
“建议将这个 axios.post() 封装为 service 层，避免重复调用逻辑扩散。”
别只说“不好”，要建议替代方案
“这里的 loading 建议用全局 loading store 管理，更便于后期维护。”
平衡“完美主义”与“性价比”，不是每一行都要完美，而是找准重点。
什么时候会考虑封装组件，封装的时候会怎么思考
什么时候考虑封装
- 多个页面/模块中甚至多个项目重复出现的 UI 或逻辑
- 复杂组件需要统一交互和行为管理
- 抽象业务组件以复用逻辑
封装时候怎么思考
- 哪些部分是“变”的，哪些是“稳定”的？保持灵活性：不将所有细节写死
- API 是否简洁易用？命名是否语义化？是否符合直觉？能否一眼看出如何使用？- props 是否冗余或混乱？
- 是否考虑扩展性？将来变化是否好加？
- 边界情况和异常处理
我会优先识别出重复度高、逻辑固定的部分，抽象为通用组件。在封装时，我会平衡使用成本与扩展性，关注哪些 props 是稳定的，哪些可以通过 render-props 留给使用者自定义，同时保障类型安全和边界处理。