如何提升開發技術的方法很多，比如專注，刻苦，熱情，興趣等，不過我這里不會提這些，下面想說的是我覺得能夠指數級提升的竅門和一些自己在求索路上的一些體會，也算是一個階段性的總結吧。

竅門一，將代碼放到 GitHub 上

---

看到這個標題一般人的反應就是覺得自己的代碼和那些高大上的開源庫比起來相形見絀，有種拿不出手的感覺。但是要想提高技術，是提高自己的技術，只要和自己比就好了。將代碼發出來不是獻丑而是為了交流，交流就會獲得信息，都說信息時代科技進步都是指數級，這個道理在這里也同樣適用。

記得以前我特別喜歡 Google 做的 Google Reader，每天打開電腦第一件事情就是瀏覽下關注的那些 RSS Feeds，自己定制的信息流和 Google Reader 對信息的完整保留，體驗上輕松的標記已讀和全部已讀，當時是再也找不出替代品了。在 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?。里面涉及的編譯相關的技術，我也寫了篇博客進行總結，地址：深入剖析 iOS 編譯 Clang LLVM

再列個經歷，當時在研究自動布局的過程中，我發現蘋果基于自動布局抽象出一個 Stack View 來做布局，這種布局思路更加規范，更容易提高開發效率，但是卻不支持低版本 iOS 系統。那時，我就在想能不能和 VFL 語言結合起來，這樣開發起來豈不會效率更高？想了幾天，覺得考慮的比較全面了，就差一個落地項目來推著自己完成它了，我就跟老大申請了在一個小版本對一個大需求涉及的頁面和功能進行重構。當時就是想著是有了一個時間節點就能夠推著自己走了，想做的事情也不會爛尾。

理想是豐滿的，可現實卻是骨感的——只有4天開發時間，前3天我才勉強完成庫的開發，里面殘缺不堪的，所以我只好把周末都搭上去了。周日下午，主要流程都完成后，我買了杯咖啡來到軟件園湖邊休息了半個小時。現在回想，這半個小時算是版本開發周期里除了睡覺外唯一的休息了。從開發到后面測試的那些天里，我都是每天6點到公司，晚上12點離開公司。最后，掐著點完成了功能版本的上線。

這個庫我也是基于自動布局來包裝的一個類似 Stack View 的庫，能支持低版本，同時設計了一個簡潔的界面描述語言，通過解析這個語言來對應生成界面，這樣開發時只需要使用簡單的語言描述即可。雖然這個開發的過程比較痛苦，但是完成后的喜悅感和成就感還是蠻大的不是么。

總結

以上是生活随笔為你收集整理的我是如何指数级提升开发技术的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。