在京东成为优秀的技术leader，需要做到这三点

 

我认为需要关注如下三点：

稳定，高效，创新。

我认为作为一名技术 leader，作为系统架构的负责人，系统稳定是首位的。更毫不夸张的说，系统稳定是研发团队的脊梁骨。其次，研发效率是研发的天职，不高效的团队是没有竞争力的。而技术创新是进步的主要生产力。

一、稳定

实现系统稳定，重要做到两点：

• 一、必须有明确的技术架构评审、代码评审和发布计划评审。
• 二、必须有报警，必须有日志。前者做到即时发现问题，后者做到迅速定位问题。

所以，总结出了问题，怎么办？

不要猜，更不要慌，通过报警点去找日志。

当然，大多数系统出了问题，都是事后诸葛亮，所以，事前保障，严格评审，是唯一有效的手段。

落地

如果你想在团队里实践评审制度，我的建议是，不要一下子把三个会一股脑都引入到团队，这会对团队产生一定的不适应感，而且，如果没有细化会议的内容和规则，最终会流于形式。

节奏应该是小步快跑，以点到面。

第一，技术架构评审、代码评审和发布计划评审，我先引入团队的是发布计划评审。之后技术架构评审和代码评审一起引入。

原因很简单，代码评审和技术架构评审相辅相成，否则只有代码评审往往只能评审出规范性的错误，业务逻辑的问题，需要对细节的把握，这往往又是非一线研发一时半会看不出来的。而只有技术架构评审则无法保证技术架构设计的实际落地。

这个过程大约一个月内逐步实施为妙，而且要不断的进行反馈和调整，才能找到一个合适团队节奏和方法。

第二，采用问题式的会议形式，涉及到10人日以上的项目和涉及到黄金流程的项目必须评审，要求项目干系人及T7+以上研发必须参与评审。

注意，采用的是会议，而非讨论。虽然会议是很重的一种形式，但也具有很重的仪式感，这会让团队重视这件事。

采用问题式的方式，而非漫无目的的讨论，这样的形式可以保障会议的高效性。通过规则选出评审项目和参会人员，控制了相关范围，而不是一帮乌央乌央的人，对每个细枝末节的需求都讨论来讨论去，造成极大的时间和成本的浪费。

那发布计划评审的问题有哪些，我列举一些必答的问题如下：

• 1、上线的内容是什么？
• 2、上线的顺序及步骤？
• 3、上线的影响范围有哪些？（依赖业务方、影响的端）
• 4、上线出了问题的回滚策略是什么？有脏数据产生么？（必须有预案）
• 5、上线的依赖资源有哪些？（MySQL、Redis、MQ、CDN …）
• 6、上线的 UCC 开关有哪些？
• 7、上线前变更配置有哪些？（如 MySQL、Nginx、RPC、JMQ 等各种配置）
• 8、上线的 UMP 报警有哪些?
• 9、上线的关键 LOG 有哪些？

那技术架构评审要评什么？我认为至少要弄清如下三件事：

• 一、你要解决什么问题？（即需求是什么？）
• 二、你解决问题的思路是什么？
• 三、你有几种解决方案可以选择？

然后，列举的解决方案从以下几点进行比较分析：

• 1、功能点有哪些？（需求边界）
• 2、流程是什么？（架构图、流程图）
• 3、依赖资源有哪些？（RPC、DB、Cache、MQ etc.）
• 4、存储结构是什么样？（Table、K/V、Index etc.)
• 5、技术难点和技术创新有哪些？（过度设计）
• 6、瓶颈和隐患可能在哪里？（调用量、并发量）

还有代码评审怎么做？我认为重点关注如下事情：

• 1、代码改动有哪些？
• 2、降级开关有哪些？（关键节点有没有监控和日志）
• 3、无效代码删除。（降低复杂度，提升可读性）

为什么不进行编码规范的评审，因为这个完全可以自己装个不管是阿里、还是 sonar 扫描，一些潜在的空指针等，都可以扫描出来。就不要在会上去浪费时间了。

还有几点，在执行中需要注意：

• 1、评审之前要先以邮件的方式发送给大家，参会人应该做好功课，是带着问题来的，否则，会上在思考会非常的低效。
• 2、评审之后要整理好会议记录发送给团队，将其作为一种沉淀和积累，否则，说说就完事了，很快就会被忘记了。
• 3、发布计划评审时间要定在上线前2~3天。如果定在前1天评审，评审发现问题，是没有充足的时间进行修改的。

最后，评审会的内容一定是一致的且确定的，是为上线服务的，不为上线进行的评审是没有意义的。注意，一定不要有太多的会议。

高效

为了能让上述的各项决议落地，必须让团队具备高效的执行力。而实现的方法，我认为只有一个，确定每个事情的 Dead line。假如要进行某项目的评审，那就明确确定下来在什么时间点进行，并以邮件 meeting 的方式发送给团队。

同时，保证会议的高效，控制时间20~30分钟。

总结

就像《在 Alibaba 成为优秀的技术主管，需要做到这三点》在文末所说，我真实的在实际工作中有过这样的经历，某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债，团队在失控的边缘。

那最终是靠什么熬过来的，就是重视系统质量，保障线上稳定，做需求慢一点没关系，但绝不能再出任何一个线上问题，因为连60分都做不到，怎么能做到80+分？后面在系统逐步稳定的基础上，进行团队提效，技术创新等。当然，真正实现了系统稳定，真的是偿还了大量的技术债和业务债。

摘抄《在 Alibaba 成为优秀的技术主管，需要做到这三点》的一句话作为总结：

一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。

 

 

获取以上Java高级架构最新视频，欢迎

加入Java进阶架构交流群：142019080。直接点击链接加群。https://jq.qq.com/?_wv=1027&k=5lXBNZ7