阿里一年，聊聊我成长了什么，入职阿里的职业生涯感悟

2018.5.31~2019.5.31，一段精彩的旅程，渡过了在阿里一年的时光，这段时光有快乐、有焦虑、有迷茫、更有思考，思考的是本身过去的种种不足、思考的是一些如今看来以前错误的想法、思考的是如何成为一个更好的技术人，将这一些思考分享给看到这些文字的每一个人，共勉。

应当如何面对线上的异常/故障

看起来毫无心义的一个问题，碰到线上异常/故障如何面对，排查解决了不就行了，可是这真的只是第一层。

最近在想“消防”这个词语颇有意思，它实际上是两层意思：

• “消”是消除问题
• “防”是防止问题

即“消防”这个词语表达的意思应该是先消除问题再防止相同的问题再次发生。其实线上的异常/故障也是一样的道理，咱们应当先及时止血，把问题处理掉，而后深挖问题，探究根因，举几个例子：

• 假设是某段代码的空指针异常致使的，那么是否考虑增强Code Review，或者使用findbugs插件去自动扫描代码中可能的异常？
• 假设是线上某个配置修改致使的，那么是否从此变动的修改必须有人双重检查一遍才能够修改？
• 假设是本地内存中某些值由于系统重启丢失致使的，那么是否引入定时任务，定时把值写入本地内存中？
• 假设是某段代码逻辑没测试到致使的，那么是否能够反思总结为何这段逻辑没有测试到，将来的测试应该如何改进？

根据我过往的经验，太多公司、太多团队处理线上的问题仅仅知足于把问题处理完就完事，忽略了对问题的复盘，这对团队/对公司的发展都是不利的。

什么是真正的技术能力

以前加了几个技术微信群，看到不少技术朋友在兴高采烈地讨论各类源码，spring源码我完全撸了一遍、最近深刻学习了dubbo底层实现方式，固然曾经的我也是这样的，记得学习volatile的时候一直挖到了volatile在硬件层面上的实现方式，可是这真的说明技术能力强吗？从今天的思考去看这个问题，我认为这更多反应的是一我的的学习能力、钻研能力以及对技术的热情，除此以外再体现不出太多其余东西了。

这个话题，多是这一年思考的最多个的一个点，钻研是好事，可是实际上大多时候的深刻钻研并不在实际工做中有用，且研究得越深，忘得越快，由于研究得越深，那么这个技术点关联的技术点就越多，边边角角的忘了，核心的东西不容易串起来。那么什么是真正的技术能力，我画一张图归纳一下：

简而言之，技术能力 = 解决问题的能力，那么一样都在解决问题，你们之间的技术高低又有什么区分呢？我认为有如下几个层次：

• 第一层级，解决当下问题
• 第二层级，以优雅且可复用的方式解决当下问题
• 第三层级，解决的问题不只仅能知足当下，还能知足将来一段时间

其实从这个角度上来看，不一样的技术能力，在工做过程当中区分度是很明显的：

• 写的代码是否存在异常风险，多线程运行下是否存在线程安全问题，某段代码是否会致使内存泄露
• 写的代码是否优雅可复用，设计的框架是否足够符合开闭原则，代码结构层次是否清晰明了
• 针对特定的场景，技术选型、库表结构设计是否足够合理，今天你设计的框架是只能用一年，仍是将来三年五年均可以持续使用
• 来了一个大的需求，就好比作一个App的会员体系功能好了，是否能够在充分分析需求后，精确将需求划分为几个特定的子模块并梳理清楚模块之间的关系

越厉害的人，在代码设计与开发过程当中，越能看到想到一些别人看不到想不到的问题，这叫作高屋建瓴；当代码运行出现问题的时候，有人1小时排查出问题，有人1分钟发现问题，这叫作举重若轻。

所以我认为解决问题的能力才是技术能力的真正体现，这一年对技术的探究我也从研究源码更多的转变去学习设计模式、去学习分布式环境下各类NoSql的选型对比、去学习使用Lambda让代码更简洁，往真正在实际工做中解决问题的方向去努力。

另外，抛开这个点，这两天我在思考，还有一个体现技术能力的点，就是学习能力。现实中的全栈是不多的，互联网这个行业的程序员的方向一般有几类：

• 服务端
• 前端
• 移动端
• AI
• 嵌入式
• 大数据

在同一类中，基础知识、基本概念、思惟方向是一致的，更多可能差别在开发工具、语言上，我精通Java，可是若是明天有一个需求，使用nodejs、scala、go更好，那么是否能够快速学习、快速上手？甚至明天有一个需求须要写前端代码，是否能够快速开发、无bug上线？

因此，解决问题的能力 + 学习能力，是我认为真正的技术能力，不过说到底，学习能力某种程度上也只是为了解决问题而已。

不要轻易造轮子

曾几什么时候，当咱们看着github上这么多优秀的源代码的时候，默默立誓，这辈子我必定要写出一个牛逼的框架，开源在网上。

曾几什么时候，公司招聘的时候，技术负责人激情满满地介绍着公司内部自研了多少系统并在线上投入使用。

不少对技术有追求的朋友，进入一家公司可能时时刻刻在寻找机会去作一些本身造轮子的事情，可是就如同前面所说的，衡量真正好技术的标准就是可否实实在在地解决问题，本身造轮子风险高、周期长，且须要长时间的验证、排坑才能达到比较好的效果。

随便举几个例子，在互联网发展的今天：

• 数据库链接池有dbcp、c3p0、druid
• 本地缓存有ehcache、要用中心缓存有redis、tair
• 服务化有dubbo、跨语言能够用thrift
• 分布式任务调度能够考虑schedulex
• 搜索能够选es、solr
• 更高级一点图片存储能够用七牛、im能够用融云/环信、音视频这块声网作得比较成熟，全部这些都提供了各个开发版本的sdk，接入简单

只要你有的技术方面的需求，绝大多数业界已经有了成熟的解决方案了，根本不须要去专门本身搞一套。所以我认为轻易必定不要造轮子，若是必定要造轮子，那么请想清楚下面几个问题：

• 你要作的事情是否当前已经有了相似解决方案？
• 若是有，那么你本身作的这一套东西和相似解决方案的差别点在哪里？假设不用你这套，基于已有的解决方案稍加改造是否就能达到目的？
• 若是没有，那么为何以前没有？是大家公司这种场景是独一无二的？仍是这种场景对应的解决方案根本就是不可行的因此以前没人去搞？

若是想清楚了这些问题，那么就去干吧。

关注软技能的成长

这个点以前没有写到，深感遗憾，文章发表以后一直想要补充进来，由于关注软技能的成长是我这一年除了技术思惟转变之外成长最大的地方。

咱们是一个技术人没错，技术是咱们每一个人的立身之本，可是在工做中咱们又不是单纯与代码打交道：

• 咱们有PD，须要向他们了解需求的总体交互
• 咱们有业务，须要全面了解需求的背景
• 技术团队内部，咱们须要相互之间沟通进度，交流技术方案、设计方案
• 技术团队外部，咱们须要对相互之间的交互方式，上下游进度不理想如何去推进
• 出了问题，咱们须要知道对外应当怎么说，对内应该怎么作
• 有一个想法，应当如何以正确的方式去落地，而不是我有一个想法直接说也不说、讨论也不讨论干就完事了

凡此种种，都须要经历和成长，曾经我也觉得程序员只要把代码写好就行了，来了阿里，才深入地感受到写代码真的只是工做的一部分（可能50%？）而已。

我相信不管你在50我的的小公司仍是在5000我的的大公司，身处3我的的技术团队仍是30我的的技术团队，没有一我的是单兵做战的，这个行业对技术人的要求从单纯的技术要求已经愈来愈往综合素质去靠，因此，关注对本身软技能的，相信不管对当下仍是对将来，百利而无一害。

去提高看问题的高度

过去有太多人在个人公众号或者博客下反馈了一个问题：在这个公司，成天作着增删改查的工做，对本身一点都没有提升。

对于这种见解，说难听点就是四个字----目光短浅。咱们看：

若是以普通的视角去看，那么一颗树那也就只是一棵树而已，可是若是跳脱出目前的视角，站在更高的角度去看，它实际上是森林的一部分。你的主管并非由于他是你的主管因此他就应该你比更高瞻远瞩，而是由于他看问题的高度比你更高、想得更远、作得更深，因此才成为了你的主管。

把这个问题说得实际点：

• 假设今天你负责的是一个系统，那么你仅仅是把这个系统的基本原理搞懂了？仍是能够把上下游有几个系统、每一个系统之间如何调用、依赖方式都理顺？
• 假设今天你负责的是一块业务，那么你仅仅把本身负责的功能点弄清楚了？仍是你能够从最上游开始，到你负责的系统，再到最下游，都思考得很是透彻？

今天与其在抱怨没有机会、抱怨公司对本身能力没有提高，为何不去思考机会为何降临在别人头上不降临在你头上？为何别人能够从小公司写着同样的增删改查走向BAT而你年复一年还在小公司写着增删改查？当你真正能转变本身的思惟模式，跳脱出如今的圈子往更高一个层次去看问题、去提高本身，我相信总会有发光发热的一天的。

一样在阿里巴巴，马老师思考天然、思考环保、思考人类的发展，你的主管思考团队将来的方向和打法，咱们在思考如何把某个客户需求完整落地，这就是高度，你未必能想到马老师想的，可是你能够对标层级高一点的人，一步一步尝试往他们的高度去靠。

总而言之：眼界决定高度，多看、多想、多保持好奇心、多问几个为何，长此以往天然就迈上了一个新的台阶。

学会总结

需求、项目的复盘是很是重要的一部份内容，然而我以前见过的太多团队、太多Leader，只顾着一个迭代接着一个迭代，一个版本接着一个版本，只知足于把需求作好，而忽略了总结的重要性。

我认为大到项目、小到需求，若是在完成以后缺少总结那么某种程度上来讲是失败的，能够总结的点很是多：

• 经过这个项目/需求，是否吃透了某一块业务，搞懂了前因后果
• 经过这个项目/需求，是否充分理解了公司某个技术框架/基础组件的用法
• 在整个项目的设计上，有哪些作的很差的地方
• 在整个项目的开发（针对程序员而言），是否踩了坑，犯了低级的错误
• 在整个项目的进度把控上、人员安排上、上下游协调上，是否存在不足之处
• 经历了某次大促的值班，是否对能够熟练使用公司的监控工具，遇到突发事件，是否快速有效地进行了解决

任何工做必定对我的都是有提高的，可是不会总结的人，在每一个项目/需求中成长的东西都是散的，长此以往就忘了。经过充分的总结以后，犯过的错误咱们不会二次再犯，理清楚的业务的前因后果铭记在心，对本身是一种提高，分享给别人对别人也是很大的帮助。

失败者失败的缘由各有不一样，成功者的作事方式老是类似的，从宏观角度去看，我认为总结就是成功者之因此能成功，很重要一个缘由。

选择大于努力

好吧，我认可调皮了，可是这一段我也是很真诚的！

人，努力是最重要的，可是选择也很是重要。有能力是很是好的，有能力的同时，一个好的Leader、一个好的团队将会让你在平时工做中感到无比舒心，将会让你有家通常的温暖，更能将你的能力最大化！

菜鸟国际物流技术团队就是这么一个团队！

最后，很是重要的一点：不要惧怕面试。经过面试才能发现不足，才能知道将来在技术道路上还须要在哪些方面进行提升，在面试的结尾，你也能够询问面试官本身有什么不足，面试官必定会给到你最诚恳的建议！

结合这篇文章和本身的总结：

一、学习能力影响技能，探索能力影响高度；

二、重复造轮子 = 时间成本浪费;

三、知识固化很重要(项目、文档、博客、总结...)；

四、把持自主选择权(大多数状况下莫得选)；

五、环境很重要

阿里腾讯Android开发十年，到中年危机就只剩下这套移动架构体系了！