談談 T 型人才
昨天的圖片發模糊了，正好我把這個話題展開聊一聊吧。這個話題是關於復合型人才的，我把它稱作 T 型人才。
「全棧」工程師
前一段時間，「全棧」工程師的概念很火，不過大多數時候，「全棧」工程師指的是一個人同時寫 Web 前端和后端，頂多加上一些運維工作。通常情況下，我很少見到一個人能夠同時寫 Web 前端 + 后端 +iOS 端 +Android 端。
在猿題庫（我們現在改名叫猿輔導了）創業初期，我曾經試圖同時寫 iOS 和服務器端，但是我很快就放棄了。因為當時服務器端的代碼量還是很大，同時有好幾個人在編寫。有些時候我需要加邏輯時，會涉及到他們的代碼修改，這個時候我就會需要花費額外的精力來看懂他們原來的邏輯。
當時正值創業初期，我們的 Code Review 並不嚴格，代碼的相關設計文檔也不多，我只能通過閱讀源碼來跟上另外幾個服務器端開發同學的邏輯。很快我就放棄了，因為在創業階段，效率是第一位的，同時做 iOS 和 服務器端，使得我在服務器端不夠專注，效率變得低下。
從那之后，我就意識到，「全棧」工程師可能最適合的場景就是 Web 前端 + 后端的偏前端的邏輯。因為那個場景下，前端工程師可以省掉溝通接口的時間，也可以自己統一前后端的模版，甚至他可以嘗試統一語言，同時用 JavaScript 寫前后端（在后端使用 nodejs）。
而在別的職位上，是很不適合全棧的，因為這樣工作產出會下降。
T 型人才
那我為什么又想聊 T 型人才呢？是因為我覺得 T 型人才和全棧不一樣。在我看來，T 型人才有一門自己擅長和精通的語言，同時又有足夠寬的視野，使得他在合作的時候，能夠更多地站在對方的立場上考慮問題。
打個比方，做過服務器端開發的同學，再轉而做客戶端開發，就會更加注意 Restful 接口的設計合理性。相互之間協商接口時，知道什么樣的方式服務器端好實現，什么樣的方式不好實現，然后定出來的接口就會讓對方非常舒適。
與此同時，T 型人才對於自己理解和學習新東西，也是有很大幫助的。我之前做過 Java 語言的服務器端開發和 JavaScript 語言的前端開發，之后才轉做 iOS 開發。各種語言和開發環境接觸多了就發現：其實很多概念都是相通的。我想我之所以當時學 iOS 開發上手那么快，也是由於在別的語言上有積累。
其實對於移動開發來說，iOS 和 Android 也有很多相同的概念，比如 iOS 的 UIViewController 和 Android 的 Activity。當然，它們也有很多不同的技術細節，比如對界面排版設計，iOS 因為設備屏幕單一，所以剛開始選擇了簡單的絕對定位，后面選擇了 size class 的方式。而 Android 因為屏幕分裂嚴重，所以選擇了更加流式的排版設計。
iOS 因為追求界面的流暢和性能，選擇了引用計數這種相對麻煩的內存管理方式，而 Android 因為需要借力 Java 語言本身的生態和蘋果競爭，所以采用了垃圾回收這種會帶來潛在卡頓風險的內存管理方式。
每年的 Google IO 大會出現的新技術，並不比 WWDC 遜色。今年 iOS 10 的一些改進，也看到了不少 Android 的影子。
如何成為 T 型人才
那么如何成為 T 型人才呢？我們老大郭常圳想了一個辦法：輪崗。輪崗的意思是，當你成為某一方面的專家后，跳出自己的舒適區，轉而到一個新的技術領域從頭學起。
在我們公司，很多早期員工都經歷過輪崗。比如我曾經從服務器端轉到前端和 iOS 端，也是輪崗這個激勵帶動的。yangyz 從服務器端轉到 Android，xuhf 從 Android 轉到服務器端，zhangyc 從 Web 前端轉到后端。每一個輪崗工作，都是對我們極大的挑戰，但是讓我們都成長為 T 型人才。
但是，輪崗的意思絕不是做一個技術方向「三心二意」，每一次轉換技術方向，都應該是對前一個技術方向至少做到熟練掌握的程度才行，而我自己覺得，不經過一到兩年的實踐，很難稱作熟練掌握。所以，輪崗的行為應該是低頻的，而且是面向那些最優秀的開發者的。
這一點有點像大學的換專業，在我們學校，大一的學生可以在一學期后申請換專業，但是前提是這個同學在願專業成績達到前 10%。
換專業和換技術方向一樣，機會只會給做得最好的人，公司不會因為一個人在 iOS 開發上做得不好，就把他輪換到別的開發崗位。