技术leader是在项目中起到承上启下的作用，对外要对业务方进行支撑，要出结果，对内要管理团队的整个过程，每天大部分的时间是在于沟通，协同，如果疲于奔命最终陷入恶性循环如何打造一个快速，稳定的技术团队成了很多信任上马的技术Leader需要解决的问题，大概整理了以下几点的需要做的事情checklist，下面我们就来聊聊关于后端技术架构图谱学习交流?接下来我们就一起去了解一下吧!
后端技术架构图谱学习交流
技术leader是在项目中起到承上启下的作用，对外要对业务方进行支撑，要出结果，对内要管理团队的整个过程，每天大部分的时间是在于沟通，协同，如果疲于奔命最终陷入恶性循环。如何打造一个快速，稳定的技术团队成了很多信任上马的技术Leader需要解决的问题，大概整理了以下几点的需要做的事情checklist。
开发规范需要制定一系列的开发规范，让团队形成一个整体，降低团队直接的沟通协同的成本。
命名规范
可以参考“阿里经济体开发规约”里面规定的命名规范，除了这些还需要把项目的模块，包路径的分层的规则定义好，例如dao包的路径是放操作数据库的类。很容易搞乱的是各层的一些入参，出参的规范，例如BO,DO,DTO,Query,Request这些也需要定义好。
统一IDE代码模板
设置好方法，类的注释，定义好缩进符号是用tab还是4个空格，这个如果不一致会导致代码格式化有差异，在进行代码评审的时候，很难看出哪些是真正有改动的地方。
Maven/Gradle使用规范
打包工具主要是定义好引用的包的管理方式，一般是把要引入的包放在最外层的pom文件进行管理，子模块按需加载，发布生产环境的包不引用快照版本（snapshot）。
参数校验规范
需要定义流量入口(restful入口的参数校验，微服务的入口请求)的参数的校验，统一的校验框架以及统一的返回参数。例如用Hibernate-Validator进行参数校验，需要在入口添加拦截器处理校验参数异常的返回值。
代码commit规范
可以让团队其他人在定位问题，可以通过提交的注释快速定位到哪个提交定位问题，commit message 格式如下，包含三个部分，header、body 和 footer，可以参考阮一峰老师的博客 《Commit message 和 Change log 编写指南》。
统一api规范
在rpc接口，http接口需要定义统一的返回对象的格式，分页对象的格式等，例如
public class ResultDTO<T extends Serializable> implements Serializable {
private String errorMsg;
private String errorCode;
private boolean success;
private T data;
}
异常处理规范
定义业务异常编码规范，定义统一的异常拦截器，处理异常校验类型，业务异常等转换成对调用方能友好提示。
分支开发规范
目前大部分的项目开发都采用了git进行代码管理，根据自己团队的实际情况采用一种固定的模式。目前有几种模式，
自由模式：可以使用任何主干或是分支进行打包和发布，
优点：自由度高，用户可以采用任何版本进行打包和部署;
缺点：代码的版本控制以及质量需要团队自己保证，风险较高；对于多人协作开发场景支持较弱，管理成本较高。
分支开发模式：
每个需求单独一个分支，各自在自己的分支开发，测试，冒烟完成后再集成一起发布。
优点：功能分支独立开发和测试，互不干扰；版本节奏可灵活控制，出现延期的分支可直接退出，代码可迅速剥离
缺点：每次部署都是临时release分支，可维护性较差；分支越多，集成越晚，冲突就越多，集成的成本以及测试问题越多，需要控制分支数量；
git-flow模式：
代码库存在两个长期分支。主分支master和集成分支develop。主分支（master）：用于存放线上稳定的版本，任何时候在这个分支拿到的，都是稳定的线上版本；集成分支（develop）：用于集成功能分支，用于各功能分支的集成测试和发布，发布完成后再合并回主干master。
优点：各分支用途明确，较好地满足了功能并行开发与持续集成诉求；分支过程与集成测试过程自动化程度较高，可随时交付
缺点：要求功能分支的质量达到要求，并且通过代码review后，后方可进入集成，对分支代码质量要求高。
统一日志规范
定义需要打印那些内容具体的格式是json或者|隔开，例如web层需要把用户id打印出来，微服务需要把链路id这些打印出来，打印的数据是否有敏感信息，是否需要脱敏。定义那些是切面层统一打印，那些是需要手动打印。日志打印的时候要考虑是否方便后续定位问题进行查看过滤。
统一的mysql开发规范
表的命名规范，字段类型的选择规范，索引的命名规范，索引的设计规范。
统一的开发工具与框架
包括dao层框架mybatis、cache组件redis、httpclient组件、common-tools(公共工具)，同时抽取出分布式锁、幂等、traceLog、公共异常拦截器等公共组件，把以上公共组件进行集成到各个应用，进行统一升级、维护
开发流程需求管理
需要跟需求方，团队成员同步好项目需求，日常迭代需求，紧急需求的开发周期，时间节奏。例如日常迭代需求需要提前一周写好对应的需求文档，定义好优先级以及上线时间要求；定义需求变更的流程，当有紧急需求插入的时候，是可以把日常迭代的一些优先级低的需求进行移除到下个迭代，释放相应的开发资源进行支持紧急需求。
技术方案评审
目标
- 设计把关，确保方案合格，各方面都考虑到
- 保证架构设计合理和基本一致，符合整体原则
- 维持对系统架构的全局认知，避免产生黑盒效应
- 通过评审发掘创新亮点，推广最佳实践
注意关注的点
- 技术选型
- 高性能，高可用，可扩展
- 安全性，可测试性，可运维，监控与告警
代码评审
代码评审前可以用一些工具例如阿里的代码编码规范先扫描一下，把一些基本的问题修复一下，还有一些重复代码的扫描插件，可以提前把这块优化掉。
目标
- 统一团队的编码风格
- 确认代码功能
- 发现潜在的bug
- 单测的代码覆盖率
发布计划评审
发布计划一般根据团队的项目周期的长短分为日常需求发布，紧急问题修复发布，项目发布等，一般都需要关注下面的几个点
- 是否有外部依赖，是否为强依赖，需要注意发布的顺序
- 是否有与环境相关的配置，例如中间件配置，参数配置这些
- 数据库是否有变更或者数据订正
- 回滚计划
- 发布后回归重点case
系统指标监控
需要监控系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。应用的jvm的各种情况，包括gc次数，gc的时间，堆内存的使用情况。
慢接口
需要对各个流量入口，例如http,rpc，mq的接口的耗时时间进行监控，一般要关注rt时间>1s以上的接口。
慢查询
主要是关注mysql的慢日志查询，随这样业务的发展，有可能之前没有问题的sql慢慢暴露出来，一般关注查询rt时间>500ms的查询。
错误日志
通过错误日志发现一些之前隐藏的bug，避免问题影响放大。
技术规划架构优化
前期的一些技术债务或为了赶进度进行妥协的一些技术方案导致模块之间耦合，沟通不顺畅导致一些功能重复建设了，需要进行统一收口等，需要有计划的把这些问题解决掉，不能越来越多，导致项目的后续开发成本变高。
性能优化
随着业务的发展，一些原来的功能的访问量变得比较多，成为一个热点的操作，原来的性能要求可能不满足业务需求了，这个时候需要提前计划性能优化的计划。
弹性与可靠性
当业务量增长，需要考虑应用的可靠性，需要保障业务的数据一致性，熔断，限流等。
,
