工具類前端項目的複雜度真的可以跟後端相提並論嗎？

在我看來，後端的複雜度依然遠高於前端，因為工具類產品非常需要協同，這就不得不引入相關的OT演算法，對高可用的要求也很高，同樣，安全性是毋庸置疑的，工具類產品很多時候是私有的生產工具，這些要求遠比所謂複雜前端要更複雜。

其他先不說，我覺得你對IDE的難度太過低估了。VSCode為什麼牛逼，據呂鵬說，一個很重要的原因是VSCode的項目經理是兩個寫了20年Eclipse的老傢伙，你所能想到的所有坑他們都踩過。要知道Eclipse在當年IDE大戰中也就欺負一下NetBeans，前面是XCode、JetBrain系列還有宇宙第一IDE VS。

WebIDE的後端的難度和許多其他產品的後端一樣主要是建立在尺度上的（比如你要服務GitHub規模的群體還要高可用），你如果沒有上規模很多問題就不存在，說句難聽的，要是只是內部自己用用，派兩個CRUD碼農說不定也能給你堆出來。就算上規模，和其他大規模高可用應用的後端還是基本相通的，絕大部分經驗（包括安全性之類的）是可以互通的。

而WebIDE的前端的難度，是橫跨多個領域知識的，隨便拿出來一個領域知識都夠你學上好幾年。比如國際化本地化和多語言支持。不要說跟後端沒有共通性，跟其他前端也可能沒啥共通性。（不同端項目的領域知識的差別還隨手找了個這個例子：https://www.zhihu.com/question/275915023/answer/403127961。這個其實還容易理解，我還見過一些更特別的前端項目如果你不懂該項目的領域知識你幾乎根本看不懂。當然後端項目也會有類似的情況，不過前端出現多領域交叉的幾率更高。）

以本地化舉例，就算VSCode這麼逆天的牛逼項目，就算是在中文這麼這麼重要的語言（而不是蒙文藏文之類的小眾語言），隨便就可以找個本地化bug出來給你，我昨天剛剛在群里抱怨的：MacOS下搜狗輸入法、鼠須管等用capslock切換到英文，在VSCode的terminal窗口裡會變成全大寫，導致基本無法使用。

現在咱們評估一下，這個bug要多久能修好？

……

實際上很可能根本評估不出來，甚至是不是VSCode的bug（還是說這是輸入法本身的bug？比方說MacOS自帶的拼音輸入法也用capslock切換就沒有這個問題）都不好斷言，除非你已經有足夠的Mac下輸入法領域知識……但是這它喵的是前端的技能範疇？

還別說，說到輸入法有關的bug，我突然想起十幾年之前我在老IE上就發現過一個和輸入法相關的奇葩bug：https://www.iteye.com/topic/191555?page=4 。但是我這經驗對於現在也並沒有什麼卵用。

我們一直說技術變化快，這麼多年以來，後端的核心知識還是有很大的延續性的。前端不能說沒有延續性，但前端相比後端有很多類似我前面說的這類的跨領域且結合非受控環境產生的瑣碎問題。前端的非受控環境遠超後端，從某種角度說和終端硬體產品類似。前端本來有個超大優點是（無論編程語言還是API都）工作在比較高的抽象層次上，可以很大程度消解非受控環境的困難，但也會遇到一些穿透抽象層的棘手問題（如輸入法bug可能是頁面級別，也可能是瀏覽器級別，也可能是輸入法級別，也可能是操作系統級別，或者是多個級別的綜合作用）。而像WebIDE這類項目甚至可能需要經常主動打破通常前端所依賴的抽象層，這下大優勢一下就變成了大劣勢（因為高抽象的反面就是無論編程語言還是API都缺乏底層控制能力）。

我講的這些，還是我作為一個敬畏WebIDE之難的門外漢管窺所知，你要去問真搞的人（比如呂鵬大大），估計給你講各種奇葩血淚史三天不帶重樣的。

@winter 同志講過一段無用的實話：「實際上討論某個工作難不難，特別是跟XX比難不難，毫無意義。市場是自由流動的，如果同等價錢下，前端技術真的"簡單"，那必然會出現後端大量轉前端的流動，但是並沒有發生，說明什麼？說明它確實是某種意義上的"難"。」

實際上那個問題下有好多很好的回答，可資參考：https://www.zhihu.com/question/275915023

以上。

工具類項目之所以複雜度高，就是因為它本身是前端項目而不是後端項目。

所有給人用的軟體都是最複雜的，因為機器講道理而人不講道理。機器的需求增加是線性的，通常理論上只要給無限多的機器，都可以滿足需求而無需修改程序。而人的需求是跳變的，一個小的創意可能整個前端全部要重做。

舉個可能大家都沒有關注的方向，在100%單測覆蓋率的情況下，很多工具類軟體依然每年改幾百甚至上萬個Bug，而同期的後端已經在聊到底是4個9還是5個9的可用性保證了。

操作系統、編譯器、IDE、Office說到底都是前端項目，都可以在斷網的時候獨立使用，這些玩意才是計算機的軟體的基石，他們出現的時候，網路還沒有出現呢。

另外，不要高估了演算法問題的複雜度，演算法問題通常都是有解或者無解的，大概也就是牛頓力學的範圍。而複雜的工程問題很多情況下是同時有解和無解的，基本上相當於量子力學的範圍，你不去實際觀測用戶行為，你根本無法知道你寫的程序是不是正確的，即使你去觀測，你也無法同時知道你寫的程序的是不是正確的(位置)和程序的演進方向是不是正確的(動量)，你只能通過大數據用戶行為的變化來決策(概率)。

問題：工具類前端項目的複雜度真的可以跟後端相提並論嗎？

最近越來越有這樣的一種認識了，

軟體工作的複雜度，是由解決問題的人決定的，而不是問題本身。這個說法看起來很荒誕，但仔細想想，竟然有幾分道理。

團隊即架構

首先關於軟體架構，我們知道有一個「康威定律」（Conways law）

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
設計系統的架構受制於產生這些設計的組織的溝通結構。

說白了，團隊有幾個人，軟體系統就傾向於被拆分為幾個部分。

因為事情終究還是會落實到人手上來的，與其爭論互相影響，倒不如獨立解耦更好。因此好的架構，往往能更準確的界定子系統的邊界，使得，各子系統之間的溝通成本最小（少了很多扯皮甩鍋的事情）。如何讓軟體開發顯得忙碌起來呢，那就是多拆系統和模塊，讓每個人維護好多模塊，且相互影響。

先有人後有問題

其次，我們是什麼樣的人，就會遇到什麼樣的問題，而不是反之。

這可能跟時下流行的觀點不太一致。

通常人們會覺得，是先有一個問題然後再想辦法去解決它，怎麼可能會反著來？這是因為有人先識別出了這個問題，在自己的能力範圍之內，後來才有了找人解決問題這件事。再回想一下，我們平時開發過程中解決過哪些問題？幾乎都是與我們工作經驗有交集的，那種努把力就能解決的問題。那些我們完全摸不到頭腦的，要麼根本意識不到這是個問題，一般早早得就放棄了。所以，有什麼樣的人，就會識別到什麼樣的問題，有什麼樣的團隊，他們擅長什麼，當前就正忙著做什麼。

開發複雜度

軟體複雜度有很多種說法，有很多種不同的評定方式。

關於軟體系統本身的複雜度，例如依賴複雜度，

或者關於要解決的那個問題的複雜度，比如業務場景的複雜度，這些複雜度，很多前輩都說得很多了，我覺得他們說的很有道理。只是，另外還有一個難以被注意到的複雜度 —— 軟體工作的複雜度。指的是，開發過程比較麻煩，難以理清頭緒，或者信息量比較大，開發效率很低。這種複雜度的形成是由多種因素造成的，但主要還是人為因素。不合理的系統劃分，或者不合理的分工安排，代碼的歷史債務比較多，等等，都有可能增加軟體工作的複雜度。從這種意義上來看，打個不恰當的比喻，

一個由 10 人組成的前端團隊，

他們的開發工作，並不比 3 人後端團隊的開發工作簡單。因為每個人都可能互相制約，並且需要頻繁溝通。

結語

總之，有很多言論是從軟體開發待解決的問題角度，來討論開發複雜度的，

也有一些言論，是從用來開發軟體的工具角度來討論，我覺得從這些角度理解，完全沒有問題。但有一個盲區，即從軟體開發工作的角度評判複雜度。正因為這樣，《人月神話》中才會提到理想化的「外科手術團隊」，意圖最大限度的減少開發（溝通）難度。最後，我認為技術本沒有貴賤，

無非是武器不同，作戰方式不同，敵人不同罷了。

好多年以前我有一個比喻，泛前端架構有兩個大方向，可以類比為蓋房子：

一個很大的小區，裡面房子都是赫魯曉夫樓，但是房子數量很多
一座摩天大樓

第一類，要解決的複雜問題並不在單一樓棟內部，而是整個小區的水、電、煤、網等等基建布設，以及整體的快速施工與交付能力，單一樓棟只需要很普通的工程師就能解決。當複雜度上來之後，甚至相當於城市規劃，需要考慮業務單元，比如工業區，商業區之間的協同能力，就會更多遇到另外一些比如交通規劃之類的問題。這個領域主要是工程複雜度，所以會有很多工具與發布體系去解決它們的問題。

第二類，蓋樓本身也是一個很有難度的事情，結構複雜度在其中佔有的比重就會大一些，你要考慮底座如何承壓，支柱如何設計，甚至如何抗風，這些在普通的幾層樓建築中，很可能都不需要太想。每往上蓋一層，就得從上到下都重新考慮、計算一遍。一旦成型，再重構的難度就是比較高的。

之前，Web應用偏簡單，很少有第二類問題，但是近年來，在瀏覽器這頭做複雜東西的越來越多了，這部分的複雜度就會逐步趨向於跟傳統客戶端大型軟體類同，那類東西，本質上就是一個客戶端/前端項目。OO領域的設計模式這本書，剛出來的時候其實是為了解決客戶端架構問題，只是這麼多年演化，大家在客戶端不太用得上，都以為它只解決服務端問題。

我一直反對使用比較通用的方案去解決第二類前端架構問題，因為至少在Web前端這塊，遠遠沒有特別通用的方案，需要根據業務特點去定製自己的架構，不應當直接使用某類全家桶，更不應當把自己提煉出的特徵方案往那些想要解決通用需求的全家桶方案里」沉澱「。

複雜度要看具體的項目，不能一概而論。

前端比較複雜的項目，比如 Google Doc ，Office 365 等等，複雜度是接近 Office 軟體量級的。

還有一些大型的頁游，複雜度也很高。

而後端也有大量很簡單的項目，甚至還有 serverless 模式的項目。

但是真正複雜的項目往往是同時包含前後端的。其前端、後端、通訊等部分，都有自己的複雜性，三者疊加就更大了。

所以，我經常說：別把自己當做前端，也別把自己當做後端，始終都要把自己當做程序員。