阿里研发的 6 年思考 - 技术层面 https://mp.weixin.qq.com/s/xL47iWUKJSfdbZ2tYgPJ5A
- 基本功（语言、编码这个层面，主要是动手能力）
- 大型分布式系统的实战经验（RPC、SOA、MySQL、Redis、MQ）
- 项目（ DB 设计、API 契约、DDD 抽象、链路设计、项目风险把控）
- 稳定性（可用 & 资损）
稳定性
记得在 2015 年年初，张雪峰加入饿了么担任 CTO 之后，从他嘴里最常听到的一句话就是“研发要对生产环境有敬畏”。
链路设计
日常不管是聊需求还是做系统设计，习惯性的把图画出来，就达成了一半。剩下的一半就要看图去想、去找问题。
技术债务
我以前处理技术债务的思路，是要有一个检查清单，我会定期的复盘所有的系统，并且结合自己团队和其他团队的事故去全量扫雷。所以技术债务对于研发同学的考验，不在于你怎么在日常工作中保证系统技术债为 0，而是你要评估清楚在有限的资源和时间下，哪些问题是刻不容缓的，哪些问题是可以往后放的。
那么如何处理技术债？
- 共识，上下一致的共识
- 在稳定后，收到稳定的回报后去还
- 破窗理论？点对点的还，不要一次性处理太多。打破一个窗户，封住一个窗户。
- 以业务的价值，进行部分的重构。用新技术替换旧技术，旧架构。
阿里研发的 6 年思考 - 业务层面
技术规划
- 建议规划要实在。做技术规划前，找你周边的研发团队聊一下，找你对口的产品、运营聊一下，知道他们的目标是什么，知道公司几个重点是什么，
- 规划中需要包含一些硬性的内容，比如这个目标要解决什么问题，怎么确定它解决了，解决得好不好，好的结果谁认可等。
懂业务
- 只熟悉自己负责的系统是不够的。
- 要知道它的前世今生，思考它的一路成长，纠结它的未来发展，同时还要清楚它的风险与隐患，它的生与死。
- 做业务场景上的外延，以此了解你的上下游，并且能做到结合业务场景去挖掘
阿里研发的 6 年思考 - 管理层面
向上管理
- 我有时候开玩笑和团队的同学聊，说你们要好好看看我的 Leader 到底想干嘛，这样你们做出来，我好去汇报。
阿里研发的 6 年思考 - 架构层面
- 首先比较重要的是定义问题，这到底是要解决什么、解决了有什么好处、怎么确定解决了。
- 其次是定义结构，这个问题的关键点组成，你对应的解法是怎样的，这其中得失要怎么权衡轻重，并且最终解决的效果如何贯穿和透传，由点及面。