全棧化與效率

現在全棧化已經成為了很多團隊的預設標籤，但是對於全棧到底意味著什麼，為什麼要全棧化我們的同學還是有些困惑的，我嘗試著從自己的理解闡述一下，歡迎拍磚。

從生產線說起

話說當年亨利福特發明了生產線……
哦，不是亨利福特，其實細究歷史，生產線也不是憑空發明的，其雛形來自於手工生產中的分工合作，而分工合作最早起源於中國，中國自先秦時期就在武器製造等領域實踐了分工合作的方法來提高生產效率。

在生產線發明之前，所有的工作都是一個工匠按照工序順序完成的，比如就製作陶器來說，從挖泥、運泥、扮土、製坯等等一系列工作都是同一個人完成的，這樣這個工匠就具備完成工作的所有技能。

生產線模式徹底改變了傳統的生產模式，工匠按照工序來分工協作，每個人只負責整個工序上的一個片段，通過機械傳送帶輸送半成品。因為每個人的工作都是比較固定而簡單的，所以工人不需要太多的培訓就可以很熟練地完成工作，從而使整體效率得到了極大的提升，產品質量也得到了保證。

也許讀者看到這兒會有點疑惑，這麼看來千年前的工匠也是全棧化的，而我們今天竟然想回到千年前的工作模式去嗎？關於這個問題，後面會給出回答。

瀑布式軟體工程模型

傳統的瀑布式軟體工程模型其實就是生產線模式的翻版，大家根據工作職責來分工合作，看起來好像挺完美的，實際執行起來也還不錯，產出了很多優秀的軟體產品。但是隨著軟體行業的發展，大家越來越認識到這種工程模式的效率很低，已經無法適應現代軟體發展的需要。

那為什麼在製造業非常成功的生產線模式，到了軟體工程領域就不適用了呢？

在回答這個問題之前，有必要重提一本舊書，叫做《人月神話》，為什麼叫做神話呢，這本書的作者給大家講了一個例子：1個婦女懷孕9個月可以誕生健康的孩子，請問9個婦女懷孕多久可以生出健康的孩子？
這個例子說明的是，有些事情不是簡單地 人*月 就能計算出工作量的。

這本書給我們揭示了一個軟體工程中最大的問題，那就是溝通成本隨著人數的增加成指數級增加。
而軟體工程和傳統制造業有一個本質的不同，那就是：
軟體工程是創造性勞動，所以軟體工程的每一個環節，都有大量的溝通的需要

所以傳統的生產線模式會給軟體工程帶來嚴重的效率問題，具體表現在工程師們大量的時間用於溝通協調，而無法從事真正的研發工作。關於軟體工程的一些特點的詳細分析，請參考我之前的帖子。

全棧化是解藥嗎？

我們需要重新回顧一下生產線解決的問題，就是生產線的每一個環節的工人都只需要面對一個相對簡單的工作，所以能夠做到很熟練，從而提高效率。如果我們只是把軟體開發的所有事情都交給同一個人來完成，雖然這個某種意義上也是全棧，能夠大大降低溝通成本，但是很顯然並不能真正解決問題，因為這個人需要大量的時間來學習各種技能，同時完成軟體開發的每一步的時間也必不可少，一個人開發軟體會導致週期漫長，甚至超過人類壽命而變得完全不現實。

那有現實意義的全棧是什麼？

我們通過一個簡化版模型例子來說明這個問題，我們假設目前的工作時間類似下圖：

上圖中各個色塊表達了各種工作在軟體開發過程中所需要的時間成本，而紅色的部分也就是溝通成本實際是涵蓋了整個軟體開發的生命週期。

而理想的全棧模式下，我們期望時間成本變成下圖所示：

在理想的全棧模式下，我們希望能夠把前端和測試工作分離到儘量和具體業務無關的元件層，而由開發來負責解決所有業務層面的問題，包括和業務相關的前端和測試工作（上圖中的兩個淺色小方塊）。通過業務和元件的分離來最小化溝通成本（紅色部分），通過元件複用來最大化元件團隊的價值。

要想達到比較好的全棧模式，有一個非常關鍵的前提，那就是元件一定要能簡單易用，不需要很高的學習成本和使用成本。這個前提意味著我們需要清楚地定義元件的問題域和使用場景，清晰的模型以便於學習和理解，和其他部分的互動協議（通常來說也就是API）也需要非常清楚而簡單。而做到這個是整個全棧化中最難的部分，如果無法做好元件，那麼全棧化的效率提升也就會變成海市蜃樓。

回到本文開頭的生產線的例子，今天我們所說的全棧化，其實是工程組織的層次化和結構化之後，軟體工程師在不同的抽象層次和維度上的全棧化，並不是說一個開發人員會掌握一切技能解決一切問題。恰恰相反，專業分工依然存在，但是分工合作的時候，大家儘量避免在同一個抽象層次上協作。我們在一個特定的抽象層次上解決問題的時候，雖然也需要了解上層的需求，但是更多的時候不需要和上層應用溝通實現細節，這樣也就減少了溝通成本。

全棧化具體需要改變什麼？

對於元件開發者來說

需要我們深入理解業務問題背後的可以被抽象出來的問題，建立相應的模型，提出並且實現合理的解決方案和提供形式。這個過程中，要求我們不僅僅能夠解決問題，還需要分辨清楚哪些問題應該被抽象出來，哪些問題需要繼續留在業務層。這件事情沒有統一的標準，需要我們根據具體的問題來分析，站在使用者的角度來提出合理的互動協議。

全棧化的一個關鍵前提是簡單易用的元件（工具），但是不是所有的場景都能夠輕易抽象出簡單易用的元件的，所以最主要的困難在於對於複雜的現實問題，我們能否找到合理的抽象問題域和解決方案。如果暫時還沒有找到合適的抽象模型，我的建議是不要操之過急，而應該花更多地時間去了解和分析問題，找到一個合理的解決方案，而不是為了全棧而全棧。

對於應用開發者來說

需要我們對自己的產品承擔全部的責任，熟悉各個元件的能力和互動形式，不再按照專業分工來完成工作任務劃分，而是根據問題域來完成任務劃分。團隊中所有的同學都需要清楚地瞭解產品系統架構，以及不同架構層面所應該解決的問題範疇。

總結

總的來說，全棧化不是簡單地讓開發做所有的工作，而是通過合理的系統架構和組織架構，讓大家更加有效率地協作，這才是軟體工程全棧化的根本目的和方向。