我看全棧工程師

　　“全棧工程師”是近幾年流行的說法。按照一般人的理解，“全棧工程師”就是“包打天下”的工程師——從後端到前端，從設計到測試，從開發到運維，都能一肩挑。其實這樣的概念早年也有，只是當時不叫這個名字，我還記得自己有個朋友說過：“創業，一定要找到無所不能的超級程式設計師”。

　　十年前我剛剛工作的時候，這樣的“超級程式設計師”非常稀罕，每每遇到都會讓人膜拜。隨著“全棧工程師”的流行，我見到的“全棧工程師”似乎越來越多了（甚至我自己有時候也會莫名其妙地被人稱作“全棧工程師”）。這個現象很有點意思，到底是“全棧工程師”的絕對數量更多了，還是我見到的“全棧工程師”更多了？我仔細思考，覺得應該是“全棧工程師”的絕對數量更多了，這種增長的動力大概來自兩個方面。

　　第一個方面是軟體開發的“工業化”，提高了“全棧工程師”能夠把握的複雜度。

　　“工業化”這個說法或許不太合適，但我也想不到更易懂的說法。經典的“工業化”指的是將越來越多的簡單重複勞動交給機器，把人解放出來。軟體行業雖然一直在推動“把越來越多的事情交給計算機去做”，但最近一二十年的速度是明顯增加了的。越來越多的問題有了現成的類庫和框架，越來越多的問題有了現成的解決方案。

　　舉我印象深刻的例子：十來年前C10K已經算難倒眾人的大問題，現在哪怕是C100K，也有現成的解決方案；三四年前Android的推送還很讓人頭痛，現在剛入門的小朋友也能可以輕鬆解決……

　　結果，不但“軟體開發的門檻越來越低”，“搭建出質量‘足夠好’的軟體產品”的難度也越來越低。或者更清楚一點說，軟體的工業化提高了大家對複雜度的掌控能力：在瞭解了“軟體要解決的是什麼問題”以及“軟體應該怎樣解決這個問題”之後，剩下的實現工作已經被大大簡化了。於是才可能出現能“包打天下”的全棧工程師。否則，倒回去三十年，在沒有標準GUI庫的Dos下開發程式，光是一個小小的動畫效果就能要了工程師的命，更談不上“全棧”了。

　　第二個方面是開發節奏和競爭的加劇，溝通和協調成本的壓力直接產生了對“全棧工程師”的需求。

　　如今越來越多的人進入軟體開發領域，軟體越來越多地深入生活的各種場景，創業拿到風投的機會也越來越高。每時每刻、每個領域、每個問題，都有人在動腦筋，在設想更好的解決方案。而且，光有解決方案還不夠，還必須迅速地實現出來，接受實踐的檢驗。

　　傳統（經典）的軟體開發模式很像工業時代的企業：眾多職能通過磨合確定出最有效率的工作方式，並照此精密化運營。這種方式沒有錯，但只適合解決相對固定的問題。如果企業要面對的是激烈的競爭，多變的環境，這種方式很難跟上外部的節奏。

　　軟體開發也面臨同樣的問題。配齊產品、開發、測試並磨合完畢就不是簡單的任務，要適應“小步快跑”、“先開火再瞄準”的節奏，配合起來更是難上加難（比如，產品人員看到一個不錯的點子決定要借鑑，開發和測試卻遲遲無法理解），難以在競爭中立足。

　　相反，如果把所有的職能集中到一個“全棧工程師”身上，溝通和協調的成本就大大降低。因為產品、開發、測試都是一個人，所以產品人員要借鑑某個點子的決策，一定可以準確流轉到開發和測試環節。同樣，因為開發和運維都是一個人，也很難出現為了穩定、效率、安全等因素的權衡爭得面紅耳赤的局面。

　　以上兩個方面互相靠攏。軟體行業的“工業化”提供了邏輯的可能，降低協調和溝通成本的考慮直接產生了迫切的需求，於是，“全棧工程師”應運而生了。

　　可惜，許多人對“全棧工程師”的理解比較片面，有些公司費勁找來了“每種技術都會一點”的“全棧工程師”，卻發現事與願違，協調和溝通的成本不降反升。問題在哪裡呢？

　　我認為，原因還是複雜性。“全棧工程師”的“全棧”是有機的整體，他能定義、理解、把握自己面對的問題，並妥善選用合適的工具，搭建出複雜性可控的解決方案。有時候甚至需要“現學”一些知識來填補自己的“棧”。這種能力通常離不開長期的工作積累和思考，甚至是刻意的訓練。所以很多的“全棧工程師”都比較謙虛，因為相比單一方面的工程師，他們更瞭解每個領域的修煉難度，清楚自己並沒有那麼多“絕學”，依靠的是學習能力和從整體把握複雜性的能力。

　　相比之下，很多“什麼都會一點”的人，反而很樂意自詡為“全棧工程師”。好幾個朋友跟我反饋，“什麼都懂一點，但其實既不紮實，也不能融匯貫通”的人到處都有，而且竟然“什麼都敢幹”，挖了大量的坑，還非常樂意自詡為“全棧工程師”。要我說，這樣的人不但與“全棧”無緣，連“工程師”都算不上。