这三点
前言
「技术经理」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。
一个技术经理的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～
40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术经理的大部分管理工作都是针对具体研发任务和技术事务的。接下来基于我在技术 TL 这个角色上，在开发规范、开发流程、技术管理与规划等方面我的一些心路历程，和大家共勉。
开发规范
我当时负责的业务是集团收购一家子公司的业务，在整体技术标规范上与集团的技术标准存在很大的差异。开发规范可以说是我来到这个团队干的第一件事，我当时面对的问题是 API 接口格式混乱，没有标准的 RPC 服务化，代码没有统一标准的开发规范，技术框架组件非标准化等一系列问题，作为一名业务上的新人，我第一时间制定了一套相对标准、全面的技术开发规范，边写代码边梳理开发规范，引领团队走
向统一标准化开发道路。
针对团队研发规范暴露的上述问题，主要制定了如下规范：
命名规范
我自己非常注重搭建项目结构的起步过程，应用命名规范、模块的划分、目录（包）的命名，我觉得非常重要，如果做的足够好，别人导入项目后可能只需要 10 分钟就可以大概了解系统结构。
具体规范包括包命名、类的命名、接口命名、方法命名、变量命名、常量命名。
统一 IDE 代码模板
约定了 IDEA/Eclipse IDE 代码的统一模板，代码风格一定要统一，避免不同开发人员使用不同模板带来的差异化以及代码 merge 成本。使用 IDEA 的同学可以安装 Eclipse Code Formatter 插件，和 Eclipse 统一代码模板。
Maven 使用规范
所有二方库、三方库的版本统一定义到 parent pom 里，这样来所有业务应用工程统一继承 parent pom 里所指定的二方库、三方库的版本，统一框架与工具的版本(Spring、Apache commons 工具类、日志组件、JSON 处理、数据库连接池等 )，同时要求生产环境禁用 SNAPSHOT 版本。这样以来升级通用框架与工具的版本，只需要应用工程升级 parent pom 即可。
代码 Commit 规范
基于 Angular Commit Message 规范生成统一的 ChangeLog，这样一来对于每次发布 release tag 非常清晰，Mac 下都需要安装对应的插件，IDEA 也有对应的插件，具体可以参考阮一峰老师的《Commit message 和 Change log 编写指南》。
此刻忽然想起 Linus 面对 pull request 里的骚操作所发的飚：
Get rid of it. And I don’t ever want to see that shit again. ——Linus
代码的 commit 的规范对团队非常重要，清晰的 commit 信息生成的 release tag，对于生产环境的故障回滚业非常关键，能够提供一些有价值的信息。
统一 API 规范
统一 Rpc 服务接口的返回值 ResultDTO, 具体代码如下：
success 代 表 接 口 处 理 响 应 结 果 成 功 还 是 失 败，errorCode、errorMsg 表示 返 回 错 误 码 和 错 误 消 息，module 表 示 返 回 结 果 集， 把 ResultDTO 定 义 到common-api 顶层二方库，这样以来各个应用不需要来回转换返回结果。
Http Rest 接口规范约定同 ResultDTO 相差无几，需要额外关注一下加解密规范和签名规范、版本管理规范。
异常处理规范
异常处理不仅仅是狭义上遇到了 Exception 怎么去处理，还有各种业务逻辑遇到错误的时候我们怎么去处理。service 服务层捕获的异常主要包括 BusinessEx-ception( 业务异常 )、RetriableException ( 可重试异常 ) 到 common-api，定义一个公共异常拦截器，对业务异常、重试异常进行统一处理，对于可重试的异常调用的服务接口需要保证其幂等性。
另外其他业务层有些特殊异常不需要拦截器统一处理，内部可以进行自我消化处理掉，根据场景对应的处理原则主要包括：
● 直接返回
● 抛出异常
● 重试处理
● 熔断处理
● 降级处理
这又涉及到了弹力设计的话题，我们的系统往往会对接各种依赖外部服务、Api，大部分服务都不会有 SLA，即使有在大并发下我们也需要考虑外部服务不可用对自己的影响，会不会把自己拖死。我们总是希望：
● 尽可能以小的代价通过尝试让业务可以完成；
● 如果外部服务基本不可用，而我们又同步调用外部服务的话，我们需要进行自我保护直接熔断，否则在持续的并发的情况下自己就会垮了；
● 如果外部服务特别重要，我们往往会考虑引入多个同类型的服务，根据价格、服务标准做路由，在出现问题的时候自动降级。
推荐使用 Netflix 开源的 hystrix 容灾框架，主要解决当外部依赖出现故障时拖垮业务系统、甚至引起雪崩的问题。目前我团队也在使用，能够很好的解决异常熔断、超时熔断、基于并发数限流熔断的降级处理。
分支开发规范
早期的时候源码的版本管理基于 svn，后来逐步切换到 git，分支如何管理每一个公司（在 Gitflow 的基础上）都会略有不同。
针对分支开发规范，指定如下标准：
● 分支的定义（master、develop、release、hotfix、feature）
● 分支命名规范
● checkout、merge request 流程
● 提测流程
● 上线流程
● Hotfix 流程
虽然这个和代码质量和架构无关，按照这一套标准执行下来，能够给整个研发团队带领很大的便利：
● 减少甚至杜绝代码管理导致的线上事故；
● 提高开发和测试的工作效率，人多也乱；
● 减少甚至杜绝代码管理导致的线上事故；
● 方便运维处理发布和回滚；
● 让项目的开发可以灵活适应多变的需求，多人协同开发。
统一日志规范
日志是产品必不可少的一个功能，具备可回溯性、能够抓取问题现场信息是其独一无二的优点，尤其在生产系统上问题定位等方面具有不可替代的作用。
这里着重强调一下针对异常的日志规范：
● WARN 和 ERROR 的选择需要好好考虑，WARN 一般我倾向于记录可自恢复但值得关注的错误，ERROR 代表了不能自己恢复的错误。对于业务处理遇到问题用 ERROR 不合理，对于 catch 到了异常也不是全用 ERROR。
● 记录哪些信息，最好打印一定的上下文（链路 TraceId、用户 Id、订单 Id、外部传来的关键数据）而不仅仅是打印线程栈。
● 记录了上下问信息，是否要考虑日志脱敏问题？可以在框架层面实现，比如自定义实现 logback 的 ClassicConverter。
正确合理的使用日志，能够指引开发人员快速查找错误、定位问题，因此约定了一套日志使用标准规范，现在可以更多的参考《阿里经济体开发规约——日志规约》。
统一 MYSQL 开发规范
表的设计和 Api 的定义类似，属于那种开头没有开好，以后改变需要花 10x 代价的，我知道，一开始在业务不明确的情况下，设计出良好的一步到位的表结构很困难，但是至少我们可以做的是有一个好的标准。
统一工具与框架
对开发过程中所用到的公共组件进行了统一抽象与封装，包括 dao 层框架mybatis、cache 组件 jetcache、httpclien t 组件、common-tools ( 公共工具 )，同时抽取出全局唯一 ID、分布式锁、幂等等公共组件，把以上公共组件进行集成到各个应用，进行统一升级、维护，这样以来方便大家将更多的精力集中到业务开发上。