如何提升開發技術的方法很多， 比如專注， 刻苦， 熱情， 興趣等， 不過我這裡不會提這些， 下面想說的是我覺得能夠指數級提升的竅門和一些自己在求索路上的一些體會， 也算是一個階段性的總結吧。 給大家做個分享， 希望對需要的同學有用。
竅門一， 將代碼放到 GitHub 上
看到這個標題一般人的反應就是覺得自己的代碼和那些高大上的開源庫比起來相形見絀， 有種拿不出手的感覺。 但是要想提高技術， 是提高自己的技術， 只要和自己比就好了。 將代碼發出來不是獻醜而是為了交流， 交流就會獲得資訊，
後來這個專案讓我認識了不少的朋友， 在他們提交的代碼裡我也學習到了很多。
竅門二， 選擇優秀同事
滴滴裡還有好多高手， 方方面面， 除了對各個技術點有深入研究的人外， 還有整體架構設計高手。 安全， 性能， 資料， 智慧都有著很多非常專業和領域影響力的老師們， 公司內會有很多技術講座， 涉及到各個領域， 滴滴的大資料和人工智慧在業界也是很有名的， 內部也有著系列的講座可以去學習， 最近的系列課程我都有在追。 每期的講師都是這個領域最有權威的人。 當然也少不了孫源的講座， 自熱每次我也都聽了。
竅門三， 主題分享
記得第一次技術分享是在組內做的一個白板分享，
每次的分享其實都會考慮比較多的事情， 首先是內容。 誰都不願意聽到處都能夠看到的東西， 這樣為了保證新鮮感， 首先要根據自己的主題看看那些到處都能看到的東西是什麼（這個過程其實比較痛苦需要查找大量資料）， 儘量避免那些大家耳熟能詳的料， 多分享些經過自己思考總結出來的理解，
再就是要考慮準備的時間， 如果時間長那麼就可以專門準備一個 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 的庫，能支持低版本，同時設計了一個簡潔的介面描述語言，通過解析這個語言來對應生成介面，這樣開發時只需要使用簡單的語言描述即可。雖然這個開發的過程比較痛苦，但是完成後的喜悅感和成就感還是蠻大的不是麼。
作者：星光社的戴銘，轉載請聯繫作者獲得授權。
連結：http://www.jianshu.com/p/5cc64a10611b
但是任務又不能不完成，想著用戶在外面急著打車需要安裝滴滴時，套裝程式太大耽誤下載時間又浪費流量該多不好。這種檢查核對工作重複枯燥又很耗時，工期又很緊，但是為了用戶體驗，我還是決定挑戰下自己。我發現，提高準確度達到不需要人工檢查是很有難度的，連 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 的庫，能支持低版本，同時設計了一個簡潔的介面描述語言，通過解析這個語言來對應生成介面，這樣開發時只需要使用簡單的語言描述即可。雖然這個開發的過程比較痛苦，但是完成後的喜悅感和成就感還是蠻大的不是麼。
作者：星光社的戴銘，轉載請聯繫作者獲得授權。
連結：http://www.jianshu.com/p/5cc64a10611b