在滴滴，我是如何指数级提升开发技术的？

如何提升开发技术的方法很多，比如专注，刻苦，热情，兴趣等，不过我这里不会提这些，下面想说的是我觉得能够指数级提升的窍门和一些自己在求索路上的一些体会，也算是一个阶段性的总结吧。趁着今天是程序员节，给大家做个分享，希望对需要的同学有用。

窍门一，将代码放到 GitHub 上

看到这个标题一般人的反应就是觉得自己的代码和那些高大上的开源库比起来相形见绌，有种拿不出手的感觉。但是要想提高技术，是提高自己的技术，只要和自己比就好了。将代码发出来不是献丑而是为了交流，交流就会获得信息，都说信息时代科技进步都是指数级，这个道理在这里也同样适用。

记得以前我特别喜欢 Google 做的 Google Reader，每天打开电脑第一件事器就是浏览下关注的那些 RSS Feeds，自己定制的信息流和 Google Reder 对信息的完整保留，体验上轻松的标记已读和全部已读，当时是再也找不出替代品了。在 Google 关闭这个服务后很长一段时间我都没有看过 RSS，转向使用 Twitter 和后来的微博来关注自己感兴趣的内容，比如国内的一些插画家，漫画家，游戏媒体，Cosplay 当然还有一些感兴趣的相关开发的人。

后来，我发现关注微博的人多了后，一些好的博客内容很容易被埋没在 timeline 中。这个时候我发现了 Reeder 这个 RSS 阅读器 APP，体验做得非常棒，不光是 UI 设计和交互，还有应用的流畅度，离线浏览等体验都是顶级的。我打算也弄一个学习下，就跟小学时喜欢七龙珠就模仿着画一样。实现基本几个功能后我就发到了 GitHub 上，结果碰到了好几个也喜欢 RSS 的开发者，他们看我在 README.md 里提到了后面计划做的事情，分别提了 PR 完成了那些功能，还有一个把界面翻天覆地的改了一通，还加了 icon 和启动图，最后还加上了两个主题选择，还修改了好几处代码不规范和不合理的地方，我 review 完就知此人设计和代码功底都很深，对这样一个艺术和程序完美结合的人佩服不已。

后来这个项目让我认识了不少的朋友，在他们提交的代码里我也学习到了很多。

窍门二，选择优秀同事

和优秀同事共事利于成长这是个显而易见的道理，但我为什么还要单拎出来说呢。因为这个点我体会非常深，也感觉是我技术提升的一个很大的节点。在这些优秀的同事里有位大家都很熟悉的孙源一直是我学习的榜样。记得在微博上第一次看到他分享的 RunLoop（视频地址：http://v.youku.com/v_show/id_XODgxODkzODI0.html ） 就很有感触，讲得通俗易懂由浅入深，后面只要他有新的文章和新的技术分享不管是对外的还是公司内部的还有直播平台的我都一个一个看完了，其中有好几篇都看了好多遍。这个过程犹如海绵吸水，停不下来。

滴滴里还有好多高手，方方面面，除了对各个技术点有深入研究的人外，还有整体架构设计高手。安全，性能，数据，智能都有着很多非常专业和领域影响力的老师们，公司内会有很多技术讲座，涉及到各个领域，滴滴的大数据和人工智能在业界也是很有名的，内部也有着系列的讲座可以去学习，最近的系列课程我都有在追。每期的讲师都是这个领域最有权威的人。当然也少不了孙源的讲座，自热每次我也都听了。

窍门三，主题分享

记得第一次技术分享是在组内做的一个白板分享，为了避免分享时跑题和讲不全，我在分享前专门把要分享的内容在 A4 纸上画了一遍。白板讲时拿着那张纸边看边讲，讲完后我发现在 A4 纸上画的这个过程最有价值了，在这个过程里我对整个相关内容会做一个总结，会考虑重点，铺垫等等因数，这个轮回下来在整理过程中我发现其实对知识点有了更深的记忆。

每次的分享其实都会考虑比较多的事情，首先是内容。谁都不愿意听到处都能够看到的东西，这样为了保证新鲜感，首先要根据自己的主题看看那些到处都能看到的东西是什么（这个过程其实比较痛苦需要查找大量资料），尽量避免那些大家耳熟能详的料，多分享些经过自己思考总结出来的理解，我觉得某个知识点只是搞懂了和实践成功了还是远远不够的，在搞懂的基础上去想为什么这样设计而不那样设计，通过自己的理解想通了那才是有意思的事情。这样就会迫使自己看大量的知识，自然而然也就学习到了大量的知识，是不是有种被推着往前进的感觉。

再就是要考虑准备的时间，如果时间长那么就可以专门准备一个 Demo 现场来演示，或者美化美化幻灯片之类。时间短的话只要力保内容有用就好了。上次 GMTC 大会前组织方极客帮专门邀请了左耳朵耗子来给我们这些讲师们分享如何做分享。他提到很重要的一点就是内容要有用，就是所谓的干货，为了不让分享枯燥那么使用讲故事的方式来吸引听众是最有效和最容易让人记住的。

分享当然还有一个很重要的好处就是和其他分享者还有听众交朋友，每次分享都会遇见很多人，新朋友老朋友，还有不同公司的人，能够了解到其它公司正在做什么，他们的成果和他们正在攻克的难题，了解现在流行的方案是什么。开阔了视野也就开阔了思路。

窍门四，在定的时间节点里将涉及到的问题尽可能问到底

大多数人都是有惰性的，那么什么样的窍门是能够适合所有人的呢。我觉得时间的节点设定非常关键。先说下什么是时间节点呢？比如某版本需求提测时间点，再比如某次分享的时间点。有了这个时间点，就可以在节点时间到达前将问题考究透，这段时间先不去关注其它东西，运气好的话时间充沛就能够考究的多些。每次节点完成都可以好好犒劳下自己，这样下次进入另一个周期时能够充满战斗力。

有一个我影响很深刻的工程大小瘦身的任务，这个也是有个时间节点。在这个任务下达之前，我们已经手动做过了一轮对无用资源的清理，剩下的只能依靠工具了。我几乎用遍了所有相关工具，当时有种孙悟空在东海龙宫试兵器的感觉，怎么都不顺手。又没有定海神针，那么只能自己造了。现有工具主要的问题是准确度不高，所以每次都需要手动核对下，这样每个版本来回几次，我们代码又这么多，这种工作量会让人吃不消的。但是任务又不能不完成，想着用户在外面急着打车需要安装滴滴时，程序包太大耽误下载时间又浪费流量该多不好。

这种检查核对工作重复枯燥又很耗时，工期又很紧，但是为了用户体验，我还是决定挑战下自己。我发现，提高准确度达到不需要人工检查是很有难度的，连 App Code 都没有做到。可人有急智，我发现通过模拟编译的过程，将代码整理成有效的结构进行分析和比对可以很容易自己控制各种检查规则。想完就撸起袖子加油干，几天后就做了出来。不过开始时没注意时间复杂度，导致速度慢得无法接受。于是一点一点地抠，把它们一个个转成空间复杂度后速度得到了质的飞跃。接下来几天，在实际工程代码检查过程中又解决了一些运行时写法的问题。为了提高体验我还做了一键清理，将无用的代码直接注释掉。这样在后面版本里节省了大量的人工检查时间。这次的“瘦身”过程也在今年的 GMTC 大会上做了分享，分享的 Slides 我放到了这里 https://pan.baidu.com/s/1skPAIID 。里面涉及的编译相关的技术，我也写了篇博客进行总结，地址：https://github.com/ming1016/study/wiki/深入剖析-iOS-编译-Clang---LLVM。

再列个经历，当时在研究自动布局的过程中，我发现苹果基于自动布局抽象出一个 Stack View 来做布局，这种布局思路更加规范，更容易提高开发效率，但是却不支持低版本 iOS 系统。那时，我就在想能不能和 VFL 语言结合起来，这样开发起来岂不会效率更高？想了几天，觉得考虑的比较全面了，就差一个落地项目来推着自己完成它了，我就跟老大申请了在一个小版本对一个大需求涉及的页面和功能进行重构。当时就是想着是有了一个时间节点就能够推着自己走了，想做的事情也不会烂尾。

理想是丰满的，可现实却是骨感的——只有4天开发时间，前3天我才勉强完成库的开发，里面残缺不堪的，所以我只好把周末都搭上去了。周日下午，主要流程都完成后，我买了杯咖啡来到软件园湖边休息了半个小时。现在回想，这半个小时算是版本开发周期里除了睡觉外唯一的休息了。从开发到后面测试的那些天里，我都是每天6点到公司，晚上12点离开公司。最后，掐着点完成了功能版本的上线。

这个库我也是基于自动布局来包装的一个类似 Stack View 的库，能支持低版本，同时设计了一个简洁的界面描述语言，通过解析这个语言来对应生成界面，这样开发时只需要使用简单的语言描述即可。虽然这个开发的过程比较痛苦，但是完成后的喜悦感和成就感还是蛮大的不是么。