滴滴在職iOS開發人員，告訴你他是如何?指數級提升開發技術的？

標籤：影響力   落地   開公司   清理   問題   技術提升   面試題   無法   告訴   

前言：

如何提升開發技術的方法很多，比如專註，刻苦，熱情，興趣等，不過我這裡不會提這些，下面想說的是我覺得能夠指數級提升的竅門和一些自己在求索路上的一些體會，也算是一個階段性的總結吧。給大家做個分享，希望對需要的同學有用。

竅門一，將代碼放到GitHHub 上

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

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望協助開發人員少走彎路。

記得以前我特別喜歡 Google 做的 Google Reader，每天開啟電腦第一件事器就是瀏覽下關注的那些 RSS Feeds，自己定製的資訊流和 Google Reder 對資訊的完整保留，體驗上輕鬆的標記已讀和全部已讀，當時是再也找不出替代品了。在 Google 關閉這個服務後很長一段時間我都沒有看過 RSS，轉向使用 Twitter 和後來的微博來關注自己感興趣的內容，比如國內的一些插畫家，漫畫家，遊戲媒體，Cosplay 當然還有一些感興趣的相關開發的人。

後來，我發現關注微博的人多了後，一些好的部落格內容很容易被埋沒在 timeline 中。這個時候我發現了 Reeder 這個 RSS 讀取程式 APP，體驗做得非常棒，不光是 UI 設計和互動，還有應用的流暢度，離線瀏覽等體驗都是頂級的。我打算也弄一個學習下，就跟小學時喜歡七龍珠就模仿著畫一樣。實現基本幾個功能後我就發到了 GitHub 上，結果碰到了好幾個也喜歡 RSS 的開發人員，他們看我在 README.md 裡提到了後面計劃做的事情，分別提了 PR 完成了那些功能，還有一個把介面翻天覆地的改了一通，還加了 icon 和啟動圖，最後還加上了兩個主題選擇，還修改了好幾處代碼不規範和不合理的地方，我 review 完就知此人設計和代碼功底都很深，對這樣一個藝術和程式完美結合的人佩服不已。

後來這個項目讓我認識了不少的朋友，在他們提交的代碼裡我也學習到了很多。

竅門二，選擇優秀同事

和優秀同事共事利於成長這是個顯而易見的道理，但我為什麼還要單拎出來說呢。因為這個點我體會非常深，也感覺是我技術提升的一個很大的節點。在這些優秀的同事裡有位大家都很熟悉的孫源一直是我學習的榜樣。記得在微博上第一次看到他分享的 RunLoop視頻 就很有感觸，講得通俗易懂由淺入深，後面只要他有新的文章和新的技術分享不管是對外的還是公司內部的還有直播平台的我都一個一個看完了，其中有好幾篇都看了好多遍。這個過程猶如海綿吸水，停不下來。

滴滴裡還有好多高手，方方面面，除了對各個技術點有深入研究的人外，還有整體架構設計高手。安全，效能，資料，智能都有著很多非常專業和領域影響力的老師們，公司內會有很多技術講座，涉及到各個領域，滴滴的大資料和人工智慧在業界也是很有名的，內部也有著系列的講座可以去學習，最近的系列課程我都有在追。每期的講師都是這個領域最有權威的人。當然也少不了孫源的講座，自熱每次我也都聽了。

竅門三，主題分享

記得第一次技術分享是在組內做的一個白板分享，為了避免分享時跑題和講不全，我在分享前專門把要分享的內容在 A4 紙上畫了一遍。白板講時拿著那張紙邊看邊講，講完後我發現在 A4 紙上畫的這個過程最有價值了，在這個過程裡我對整個相關內容會做一個總結，會考慮重點，鋪墊等等因數，這個輪迴下來在整理過程中我發現其實對知識點有了更深的記憶。

每次的分享其實都會考慮比較多的事情，首先是內容。誰都不願意聽到處都能夠看到的東西，這樣為了保證新鮮感，首先要根據自己的主題看看那些到處都能看到的東西是什麼（這個過程其實比較痛苦需要尋找大量資料），盡量避免那些大家耳熟能詳的料，多分享些經過自己思考總結出來的理解，

我覺得某個知識點只是搞懂了和實踐成功了還是遠遠不夠的，在搞懂的基礎上去想為什麼這樣設計而不那樣設計，通過自己的理解想通了那才是有意思的事情。這樣就會迫使自己看大量的知識，自然而然也就學習到了大量的知識，是不是有種被推著往前進的感覺。

再就是要考慮準備的時間，如果時間長那麼就可以專門準備一個 Demo 現場來示範，或者美化美化投影片之類。時間短的話只要力保內容有用就好了。上次 GMTC 大會前組織方極客幫專門邀請了左耳朵耗子來給我們這些講師們分享如何做分享。

他提到很重要的一點就是內容要有用，就是所謂的乾貨，為了不讓分享枯燥那麼使用講故事的方式來吸引聽眾是最有效和最容易讓人記住的。

分享當然還有一個很重要的好處就是和其他分享者還有聽眾交朋友，每次分享都會遇見很多人，新朋友老朋友，還有不同公司的人，能夠瞭解到其它公司正在做什麼，他們的成果和他們正在攻克的難題，瞭解現在流行的方案是什麼。開闊了視野也就開闊了思路。

竅門四，在定的時間節點裡講涉及到的問題儘可能問到底

大多數人都是有惰性的，那麼什麼樣的竅門是能夠適合所有人的呢。我覺得時間的節點設定非常關鍵。先說下什麼是時間節點呢？比如某版本需求提測時間點，再比如某次分享的時間點。有了這個時間點，就可以在節點時間到達前將問題考究透，這段時間先不去關注其它東西，運氣好的話時間充沛就能夠考究的多些。每次節點完成都可以好好犒勞下自己，這樣下次進入另一個周期時能夠充滿戰鬥力。

有一個我影響很深刻的工程大小瘦身的任務，這個也是有個時間節點。在這個任務下達之前，我們已經手動做過了一輪對無用資源的清理，剩下的只能依靠工具了。我幾乎用遍了所有相關工具，當時有種孫悟空在東海龍宮試兵器的感覺，怎麼都不順手。又沒有定海神針，那麼只能自己造了。

現有工具主要的問題是準確度不高，所以每次都需要手動核對下，這樣每個版本來回幾次，我們代碼又這麼多，這種工作量會讓人吃不消的。但是任務又不能不完成，想著使用者在外面急著打車需要安裝滴滴時，程式包太大耽誤下載時間又浪費流量該多不好。

這種檢查核對工作重複枯燥又很耗時，工期又很緊，但是為了使用者體驗，我還是決定挑戰下自己。我發現，提高準確度達到不需要人工檢查是很有難度的，連 App Code 都沒有做到。可人有急智，我發現通過類比編譯的過程，將代碼整理成有效結構進行分析和比對可以很容易自己控制各種檢查規則。想完就擼起袖子加油幹，幾天后就做了出來。

不過開始時沒注意時間複雜度，導致速度慢得無法接受。於是一點一點地摳，把它們一個個轉成空間複雜度後速度得到了質的飛躍。接下來幾天，在實際工程代碼檢查過程中又解決了一些運行時寫法的問題。為了提高體驗我還做了一鍵清理，將無用的代碼直接注釋掉。這樣在後面版本裡節省了大量的人工檢查時間。這次的“瘦身”過程也在今年的 GMTC 大會上做了分享，

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

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

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

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望協助開發人員少走彎路。

本文 戴銘

本文連結：http://ming1016.github.io/2017/10/24/how-do-i-improve-the-development/

文章來源於網路，如有侵權，請聯絡小編刪除。

滴滴在職iOS開發人員，告訴你他是如何?指數級提升開發技術的？