談談 T 型人才

談談 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 開發上作得很差，就把他輪換到別的開發崗位。