来源：孔凡勇（云狄）的分享：《细说Tech Leader在开发团队的核心职责》
协作流程
配置规范
统一配置规范，包括IDE、maven、git、各种环境参数等。这些配置都放在WIKI上，方便新来的同学看。
命名规范
包、类、接口都要按规范来命名，不要整些半土半洋，只有你自已理解的命名。可参考阿里之前出过一个JAVA编码规范。
API规范
前后端分离、微服务架构，API规范尤其重要，版本的兼容性、错误码的规则、鉴权方式、数据脱敏、设计API时的防重、幂等性问题要考虑到。
异常处理规范
好的程序，必定有好的异常处理机制，重试机制、超时的处理、极端情况下的熔断机制、降级机制。
不要小看这些“雕虫小技”，比如重试，如果没有一个好的重试设计，在对方接口调不通的时候，调用端不做控制，频繁重试，这不亚于一次DDOS攻击，整个服务会被压垮。
分支开发规范
分支管理同样要遵守约定，什么时候用双主干、什么时候锁分支，谁来负责分支的管理，紧急版本用主干还是分支来发版，要根据实际情况来制定标准。
代码commit规范
commit的标识要统一，如：feat : 新功能；fix : 修复bug；docs : 文档改变；style : 代码格式改变；refactor : 某个已有功能重构；perf : 性能优化；test : 增加测试。
可以结合IDE插件来实现。
日志规范
通常公司的开发框架里都会集成日志处理模块，在编码的时候按规范调用，禁止用System.out/error来输出日志。上线后有统一的配置中心来控制日志的输出。
MySQL开发规范
在开发过程中，建表的规范，索引使用和优化，SQL语句的内联、外联，好的SQL习惯要养成。
统一工具与框架
常用的工具封装，如http连接、ORM、文件读写。
分布式基础组件的使用，不要每个人自已实现，尤其是锁、限流机制等，使用不当很容易造成线上事故，而且不好查。
需求要有治理机制，要根据对主营业务的贡献度来衡量价值，而不是哪位老板的声音大，需求要评出A\B\C等级，根据等级安排资源。
架构设计的目标
架构评审的原则：合适原则、简单原则、演化原则，“刚好够用”也许是最“完美”的方案。
架构评审，要兼顾功能需求、非功能需求。
不要流于形式，不要变成批斗会，或是华山论剑，比谁的技术niublity。
目标是找出设计和实现时遗漏的地方，帮助开发人员成长。
对比较大的版本发版，要做发布计划评审，要有外部依赖检查、配置确认、二方库与应用发布顺序、数据订正和变更、回滚计划、线上回归冒烟等。
作为技术经理，要做团队的技术规划，如每周、每半年。
平时的技术运维要关注：系统指标、慢接口、慢查询、错误日志等等，从小处发现改进的点，尽早防范。
依据团队不同阶段，分为集权式管理、放权式管理。
团队管理，分成“管”和“理”。
初级员工要“管”，设定目标、给与辅导，手把手帮助员工提升能力。
资深员工要“理”，给以空间，设定目标，帮助协调资源，有兜底方案，让员工自由发挥。
1on1
1on1是非常重要的沟通方法，尤其跟员工进行辅导的时候。
遵循3分讲7分听的原则，关注个人工作、个人成长、团队、公司四个方面。
要提好的问题，比如：
你对近期工作满意吗？为什么？
现在做的事情，跟你的发展方向是一致的吗？
团队员你最佩服谁？为什么？
你对公司战略有什么不清楚的吗？
人才选拔要关注：专业能力、沟通、责任心、是否靠谱、价值观等。不要只看技术，别忘了这个人进来是要跟人打交道的，要综合考量。
管理者的职责是：定出高目标，带领团队共同前进，把团队从愚昧之巅推向绝望之谷，帮助团队成员走上开悟之坡。
