一个技术主管/团队Leader的工作职责有哪些？

精选30+云产品，助力企业轻松上云！>>>

一个技术主管的工作职责

• 开发规范
• 开发流程
• 技术规划
• 管理

---

• 开发任务分解分配
• 开发实践
• 技术架构评审
• 代码审核
• 风险识别

开发规范

命名规范

统一IDE代码模板

IDEA插件Eclipse Code Formatter

Maven使用规范

二方、三方包版本全部有parent pom管理

代码Commit规范

基于Angular Commit Message规范生成统一的ChangeLog，这样一来对于每次发布release tag非常清晰，Mac下都需要安装对应的插件，IDEA也有对应的插件，具体可以参考阮一峰老师的《Commit message 和 Change log 编写指南》。

统一API规范

（success代表接口处理响应结果成功还是失败，errorCode、errorMsg表示返回错误码和错误消息，module表示返回结果集，把ResultDTO定义到common-api顶层二方库，这样以来各个应用不需要来回转换返回结果。Http Rest接口规范约定同ResultDTO相差无几，需要额外关注一下加解密规范和签名规范、版本管理规范。）

异常处理规范

BusinessException、RetriableException（幂等性）、common-api、异常拦截器

方法内异常自我消化处理：

• 直接返回
• 抛出异常
• 重试处理
• 熔断处理
• 降级处理

使用Netflix开源的hystrix容灾框架进行弹力设计，解决异常熔断、超时熔断、基于并发数限流熔断的降级处理。

分支开发规范

• 分支的定义（master、develop、release、hotfix、feature）
• 分支命名规范
• checkout、merge request流程
• 提测流程
• 上线流程
• Hotfix流程

统一日志规范

日志脱敏（比如自定义实现logback的ClassicConverter）

《阿里经济体开发规约——日志规约》

统一MYSQL开发规范

统一工具与框架

开发流程

瀑布开发模式（需求评审、测试用例评审、技术架构评审、开发与测试、验收与上线）

需求管理、技术架构评审、代码评审、发布计划评审

需求管理

技术架构评审

敏捷迭代、日志审计

• 技术选型
• 高性能
• 高可用
• 可扩展性
• 可伸缩性
• 弹性处理
• 兼容性
• 安全性
• 可测性
• 可运维性
• 监控与报警

代码评审

代码质量包括功能性代码质量和非功能性代码质量

CodeReview：

• 确认代码功能
• 编码规范
• 潜在的BUG
• 文档和注释
• 重复代码
• 复杂度（如圈复杂度）
• 监控与报警
• 测试覆盖率

发布计划评审

• 各环境配置信息是否存在差异化；
• 数据库是否有表和数据的变更；
• 是否有二方、三方的jar包、接口等依赖，确认各应用和服务的发布顺序，包括内部和外部，提前协调好相关人员和业务方；
• 回滚计划，如果某些发布不可逆，确保限流降级等容灾计划；
• 发布完毕后的回归测试

技术规划与管理

系统健康度巡检

• 系统指标：系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
• 慢接口：通常rt大于3s的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。
• 慢查询：MYSQL慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。
• 错误日志：通过错误日志去发现系统隐藏的一些bug，避免这些bug被放大，甚至极端情况下会导致故障。

技术规划

• 架构优化（高内聚低耦合、单一职责原则、模块化/服务化）
• 性能优化
• 弹性与可靠性
• 可伸缩性

总结

大局观

• 业务发展趋势
• 技术演进趋势（架构能力）
• 良好的管理能力
• 执行力、学习能力、解决问题的能力