我最近的項目，團隊都是以前端、後端兩個分離的形式。作為一個大前端，不論是在 Web 開發的時候，還是開發 Android 應用的時候，經常遇到：
- 後端 API 產能不免，供給不上的問題後端 API 出現 BUG，需要等待修復的問題後端 API 發生了修改，沒有通知到前端，showcase 的時候發現了 bug……
這一系列的問題，讓我覺得特別不開心，我浪費了大把地青春在等後端寫代碼。而聯想起很早以前的全功能型團隊，我不禁要寫一篇文章吐槽一下，WTF，前後端分離團隊的資源浪費。
全功能型開發團隊
全功能型開發團隊是一個膠水團隊，用一個更好的詞就是精益團隊，團隊裡的成員可以獨立地處理大部分的前後端問題。它並非指每個成員都同時擅長前後端，而是在前後端裡各有所長。但是，對於業務問題來說，前後端的編碼並沒有太大的區別。
當一個擅長前端的開發人員，遇到複雜的後端問題，就會找團隊裡相應的後端開發人員來解決。同理，當一個擅長後端的開發人員，遇到複雜的前端問題，就會找團隊裡相應的前端開發人員來解決。
我工作的第一個團隊是一個全功能型團隊，在這個團隊裡沒有前後端之分：Only Developer。只是 Developer 分成了：
- 擅長前端的 Developer擅長後端的 Developer
又或者是：
- 往前端發展的 Developer往後端發展的 Developer
在這個 10 個開發人員的團隊裡，每個開發人員，即是一個前端開發，又是一個後端開發，還有些人充當了臨時的 Ops 或者 DevOps 的角色。在一段時間裡，我們還嘗試著讓開發人員擁有測試、業務分析技能，但是我們失敗了——Developer is Deverloper，脫離一線就相當的困難。
前後端分離團隊的資源浪費
與前後端團隊相比，一個全功能型團隊接觸到新的任務時，他接到的是一個開發後端 API、前端 UI 的任務。而不是一個後端 API，又或者僅僅是一個前端 UI 的 story。
設計不當導致的浪費
兩種不同的團隊類型，意味著全功能型團隊的成員：
- 節省了大量的時間在 API 溝通上可以設計出符合前端 UI 的 API遇到 Bug 時，可以快速地修復
而在一個前後端分離團隊裡，他們需要：
- 花費時候在制定 API 的接口上設計出的接口，可能並不適合前端使用遇到 Bug 的時候，修復完後，需要前端或者後端配合
進度不一致導致的浪費
可是當前後端進度出現不一致的時候，特別是後端進度落後於前端的時候，會在後期導致大量地返工，並且有大量地開發人員在等待另外一端的實現。
當後端完成開發時，前端去集成代碼，遇到一些 Bug，又進一步地需要等待後端去修復這些 Bug。
溝通不暢導致的浪費
對於那些前、後端不在同一地方開發的團隊來說，他們可能使用 API 文檔或者契約來溝通。而在開發的過程中，有一些補充的修改，在即時通信軟件上通知了，但是執行的人忘了這回事。那麼，就會進一步地導致各式的溝通問題（撕逼）。
總之言之，全功能型開發團隊好。
什麼阻礙了全功能型開發團隊
但是要實施全功能型開發團隊一點兒也不容易，你要遇到合適的人、合適的項目，還要有適合的領導。
然後，團隊就可以關注於技術溝通，和提升技術水平上。
技術溝通
在我司我們採用的是開放式辦公，任何時候你遇到任何遇到，你都可以輕鬆 Touch 到團隊的每一個人。
對，這種類似於網吧的佈局。
那麼，剩下的唯一擔心的可能就是代碼質量了。請注意兩個點：
- 單元測試。即使是不擅長後端，足夠的 Test Case，也能提升代碼的質量。適當地結對編程。當一個不擅長後端的成員，剛接觸項目時，適合時間的結對編程可以提升他的後端能力。同理於前端能力。Code Review。代碼檢視，對於不擅長後端的人來說，仍然是一個相當好的成長機會。
在大部分的公司裡，基本上很難做到上面三點中的任意一點，所以更難實現這種類似的團隊。而當我們嘗試去建立這樣的團隊，那麼幫助他人成長就是永遠的主題。
原文鏈接：https://zhuanlan.zhihu.com/p/39710161
閱讀更多 前端小學生 的文章
