軟件開發裏本沒有服務端，分的細了就有了服務端。做爲一個軟件開發者，每個人都可以是全棧。看到“服務端全棧”這個詞，不知道屏幕前的你現在腦子裏想到的是什麼問題。
- 老闆：我們團隊的服務端可以去寫前端麼？會不會搞出很多故障？能不能縮短開發時間？能不能給我節省成本？
- 前端：你都能寫前端了，那還要我幹嘛？
- 服務端：我有必要學前端麼？寫前端對我職業生涯有啥好處？學到啥程度可以寫前端需求，發佈前端的應用？
我第一次知道這個詞的時候，腦子裏是一片空白的狀態：老闆把我叫到茶水間，瞭解了一下前端經驗、排期情況，選了我去做“服務端全棧化”。具體就是有個項目前端缺人手，項目中已經有個前端大佬，讓我去打打輔助。
當時的我只在flask項目寫過簡單的html，三大前端框架都不會，滿心歡喜的準備去項目室抱大腿學前端。等我到了項目室發現，帶我的前端大佬是日理萬機的前端大團隊TL，我也不太好意思讓大佬陪着我寫代碼，我就變成了項目裏唯一一個前端開發，大家都叫我團隊的希（瓶）望（頸）。
從那天開始，我白天強裝鎮定在項目室寫前端，深夜瘋狂補課、學習前端知識，解決白天遇到的問題。過程中好在前端TL很給力，幫忙找了很多資源解決我開發中遇到的問題，就這樣磕磕絆絆持續了一個多月，項目終於上線了。這也成了我的全棧化初體驗。
在此後的一年中，我在沒有耽誤服務端成長的情況下，從一個需要前端協助的全棧開發，成長爲了獨當一面、可以牽頭整個模塊級的前後端系分設計、輔導其他服務端同學進行前端開發、把控前端項目質量、上線前端項目的全棧化同學。
作爲團隊的全棧化標杆同學，和我們團隊唯一的前端同學一起，在老闆的鼎力支持下，走出了一套可複製可遷移的服務端團隊全棧化道路，團隊裏年輕的服務端開發同學都具一定的全棧能力，團隊的前端資源不再成爲瓶頸。
在我和我們團隊其他同學的全棧化實踐中，我注意到每個階段都有一些共性的痛點和問題，也有一些自己的解決思路和經驗，希望分享出來讓後人可以更輕鬆加入全棧化大家庭，走的更快更穩。
第一步：從入門到不放棄——前端基礎學習
在入門階段，我們需要解決以下幾個問題：
- 前端知識去哪學，怎麼學？學到啥程度可以動手？看完我以爲我會了，一動手寫憋不出兩行代碼。
- 語言問題、開源框架的問題可以問chatGPT，內部框架、工具的問題沒有頭緒。
- 簡單的畫頁面和邏輯終於可以寫了，一遇到環境問題或者疑難雜症就只能求助或繞過。
Tip1 系統性快速學習，瞭解技術版圖，開發過程中扣細節
不知道大家在大學的考試周，有沒有過“一夜一門課，兩週一學期”的體驗。我作爲一個臨時抱佛腳選手，對這一點深有體會。這種學習習慣本身並不值得提倡，但是其中的一些學習技巧可以提煉出來遷移運用。
工作中的學習，很少能夠有讓人完全準備好再上的機會，往往也是類似考試周的這種系統性快速學習+突擊性詳細學習的組合。系統性的快速學習可以在整個知識體系中，畫出一張地圖；突擊性的學習能夠讓地圖上具體的一小塊更清晰。有了地圖和不斷的突擊，就可以更快把知識連成面，形成自己的知識體系。
以釘釘的前端知識體系爲例，我們團隊的前端同學已經給大家梳理了一份前端知識點大圖，這個大圖解決了從0到1學什麼的問題，它就像前文裏說的地圖，有了這個地圖，就有了前端知識海洋裏的導航，要做的就是探索和完善這個地圖。
關於看視頻還是看書學習，不同人的習慣各不相同，我建議選擇適合自己的就好，相關的資料也非常好找，不論是阿里內部的奇點學堂，還是外部的B站、油管、以及各種知識付費App，都有很多優秀的學習材料。
比學習知識點更重要的是實踐。在全棧化初期，我的前端能力之所以能快速成長，離不開前文提到的那段項目裏白天寫bug，晚上邊學邊修bug的經歷。例如學完React的hook，立刻用hook重寫一下自己之前的Class組件；學完高階函數，立刻用高階函數去重構一段適配器邏輯。我並不鼓勵炫技式的使用一些組件或特性，但是如果一個新知識點可以讓我們的代碼從中受益，我一定會去嘗試。
Tip2 不要放過任何一個疑難雜症或者彆扭的地方
在入門階段，我經常出現自己寫了一段爛代碼而不自知的情況，不過很快我有了感知這類爛代碼的技巧：當一段邏輯，自己都覺得寫的不順手或彆扭的時候，往往意味着有更好的解決方案。這時應該記下來，儘快查找、請教，尋取更好的實現方式，並對知識點查漏補缺。
下面這段代碼我自己第一次用React實現一個帶有篩選器的、支持分頁加載更多的表格。直觀看，就是有很多個state，並且state之間不是正交的。
const TableBizComponent: React.FC<ITableBizComponentProps> = (props) => {
const {dataId, corpId, yearMonth} = props; // 年月篩選和數據id從props傳入
const [pageNo, setPageNo] = useState(1); // 頁號初始化
const [selectedFilterId, setSelectedFilterId] = useState(null); // 篩選器選中id
const [filterData, setFilterData] = useState(null); // 篩選器數據
const [columns, setColumns] = useState([]); // table表頭
const [data, setData] = useState([]); // table 全部數據行
const [hasMore, setHasMore] = useState(true); // 是否更多 初始化
const [needUpdate, setNeedUpdate] = useState(false); // 是否需要調用loadMore
const [isLoading, setIsLoading] = useState(null); // 頁面級加載中
const [isPageLoading, setIsPageLoading] = useState(false); // 分頁加載中
// 初始化數據
useEffect(() => {
// ...
}, []);
// 頁面切換
useEffect(() => {
// ...
})
}
考慮到有讀者可能沒有React基礎，我形象的解釋一下上述代碼的問題：現在有10個開關，控制一個頁面的渲染，這些開關並不是獨立的，可能開了A開關，C開關也跟着開了；關閉了B開關，D，E開關也動了。這就導致一個簡單的用戶交互，我需要手忙腳亂的操控這些開關，讓他們微妙的配合，達到正確渲染頁面的目的。
雖然當時這段代碼沒有bug，但是調試和日後維護都是一場災難。所以我就去找了不少講state的文章，瞭解到了“單一數據源”、“最小狀態”等這些概念，也找到了更多成熟的邏輯封裝庫，最終改了一版代碼變成這樣。
const TableBizComponent: React.FC<ITableBizComponentProps> = (props) => {
const {dataId, corpId, yearMonth} = props; // 年月篩選和數據id從props傳入
const [selectedFilterId, setSelectedFilterId] = useState(null); // 篩選器選中id
const {data, loading, loadMore, noMore} = useInfiniteScroll( // 分頁查
(currentData: IData): Promise<IData> => {
return new Promise((resolve, reject) => {
const pageNo = Math.ceil((currentData?.list?.length ||0) / PAGE_SIZE);
// ...
})});
// ...
}
修改後的代碼去掉了不獨立的state，引入了自定義hook對分頁查詢的通用邏輯進行封裝，而這種通用封裝邏輯，已經有一些經過工業界驗證的開源庫可以使用，最終代碼變清晰了，後續的維護難度也大大降低。
除了上面這個例子，在項目中我還被移動端縮放適配的問題困擾過，儘管繞了很多彎路最終發現只是一行配置沒有加上，但排查問題的過程幫助我把前端的尺寸方案，webpack，瀏覽器的視口、根元素、物理/獨立像素比等這些基礎知識都補齊了一遍。
在全棧化成長的初期，獨立解決3-5個這類疑難雜症式的絆腳石，對自己的能力和信心的提升都會有很大的幫助。
Tip3 內部開發環境、工具相關的問題多問多總結，維護自己的QA
在全棧化開發過程中，遇到語言、開源框架相關的問題時，往往可以用好搜索引擎和chatgpt尋找解決方案。而不同公司、BU、團隊往往會有些內部開發環境、開發工具以及獨有的內部依賴，這類依賴或多或少會存在文檔沒有及時更新或丟失，找不到維護人等問題。
這些依賴出現問題時，如果你在前端團隊裏，往往都是通過老帶新，口口相傳，或者一些內部流傳的文檔解決的。但是作爲一個要做全棧化的服務端同學，身邊沒有一羣踩過坑的老司機，遇上這類問題就抓瞎了。
這個階段的問題，有時可能可以看到內部源碼，還可以自己嘗試解決；有時靠自己會花大量時間走大量彎路最終也很難找到問題原因。這種時候作爲全棧化同學，還是需要有一個部門裏的前端大佬報下大腿，畢竟站在巨人的肩膀上才能看的更高嘛。
以我自己爲例，當時我厚着臉皮加到前端團隊的知識庫裏，每次遇到這類問題時，我都會去知識庫中看看有沒有前人的沉澱可以解決，同時也在自己的知識庫裏分類做好沉澱和索引。如果知識庫的內容還是不能解決問題，就立刻去尋求前端同學的幫助。當我在做第一個前端項目的時候，是真的什麼都不會什麼都不懂，我實在沒轍就把前端TL的組織架構拉了出來，對着組織架構輪流找下面幾個花名眼熟的前端同學輪流問問題。
雖然有些工具缺少持續更新的文檔，但是大部分問題都是可以通過多問多找的方式，最終找到維護人或者瞭解這個工具歷史的人，給到解決方案或者解決思路。
作爲一個服務端的同學，一些服務端的問題自己解決不了時，可能還會因爲有些包袱不好意思請教別人；但作爲一個服務端同學寫前端時，在戰略上更要拿出“我不會我有理”的態勢；在戰術上虛心請教，比如提問時最好簡潔描述問題、帶上自己已經查找了哪些相關資料的背景信息；大佬幫忙解決完問題後，儘量想想自己可以怎麼給大佬提供價值，常見的手段可以是將問題和解決方案總結整理好，提供給大佬維護到QA。
Tip4 全棧化學習裏的二八定律
集中學習、集中實踐對於掌握一項技能來說往往是最高效的。
看到這裏的開發同學或者TL，我真誠的建議如果想在組裏推進全棧化的話，一定要在初期爭取讓全棧化同學去完成完整的有一定規模和難度的前端需求。
在我自己的全棧化成長過程中，我在前20%的成長週期裏摸索了80%的前端常用技術，快速形成了戰鬥力，能夠在前端需求彙總成爲獨當一面的多面手。在之後的成長週期中，纔是不斷遇到一些疑難雜症，並在挑戰這些疑難雜症的過程中繼續成長，向能夠把控前後端整體需求的目標看齊。
第二步：術與道——前端思維學習
對於一個服務端同學，一般走完了第一個階段，拿到一個前端需求都能夠實現。但是代碼距離優秀的前端工程代碼還有着巨大的進步空間，往往存在缺少抽象，實現比較笨拙的問題。套用馬丁福勒的話說，代碼沒有前端的味道，甚至有點壞味道。
我認爲造成這個階段的問題的原因，不是服務端同學的代碼能力不行，而是服務端同學讀過的前端代碼太少，輸入不夠、眼界不夠開闊，缺少對於一些編程套路、編程範式的瞭解，導致功能都可以實現，但是不夠健壯、不夠簡潔、對於需求變化不夠友好。
我選了幾個我們團隊的服務端同學在全棧化過程中寫下的前端代碼片段，在重構前後的對比作爲例子。這幾個例子有一定的代表性，在重構前，它們沒有語法錯誤，也基本能滿足功能性的要求，但是重構後代碼更加簡潔、健壯，並且更符合前端的編程思路，能夠有效的降低後續修改和維護的成本。
誤區1 把服務端的編程習慣帶入前端開發中
重構前：
const resultA = await rpc(request1);
const resultB = await rpc(request2);
if (ressultA !== null && resultB !== null) {
// process
}
對於服務端同學來說，這段代碼簡直不能再熟悉了，除了await這個關鍵字可能不認識以外，和服務端代碼沒有什麼區別。
這段代碼不能說它有問題，但是編程風格和前端強調的事件驅動、異步回調的風格不太一致。服務端同學，尤其是習慣了面向對象的服務端，寫前端時經常會把自己同步編程的編程風格和麪向對象的編程範式生搬硬套到前端代碼中。這樣的代碼在前端看來就像方言，在語法和語言自身的功能上沒有大的問題，但不是普通話，有一些理解成本和協同成本。
重構後的代碼如下：
Promise.all([rpc(request1), rpc(request2)]
).then((results) => {
// process
}).catch((e) => {
// process exception
});
Promise模型並不是什麼新東西，可能在常見服務端語言（Java、C++、Python等）中不太常見，但是在前端中，這個異步模型有着廣泛的使用。使用 Promise 的好處包括但不限於，
1.異步控制：Promise 提供了一種靈活的方式來管理和控制異步操作。通過鏈式調用then()和catch()方法，可以更好地處理異步操作的成功和失敗情況，以及鏈式執行多個異步操作。
2.並行執行：可以使用Promise.all()方法來並行執行多個異步操作，並在它們都完成後獲取結果。
3.更好的錯誤處理：Promise可以使用catch()方法來捕獲和處理異步操作的錯誤情況。
4.前端友好：在大部分前端都習慣使用Promise的環境下，使用Promise模型編寫的代碼，能降低理解成本。
值得一提的是，這裏的異步和服務端常見的線程池異步處理有一定的區別。js在執行過程中其實是單線程的，它的異步由主線程和任務隊列構成，在主線程空閒的時候，會遍歷隊列中的異步任務執行。
誤區2 對弱類型語言不夠敬畏
重構前：
fn1 = (alist) => {
if (alist !== null) {
this.props.myfunc(alist.length);
}
};
這段代碼咋一看也沒有問題，但是仔細一想，myfunc、length這些方法和屬性都來的莫名其妙。
如果這段js代碼服務端同學看完沒啥體感的話，拿python舉例大家可能更加親切。python的很多開源倉庫早期代碼都經常被吐槽“從褲襠裏掏出一個變量”，很難看出來這個變量是啥含義，什麼時候加進去的，什麼情況有值。弱類型語言如果沒有類型系統約束，在小腳本中看不出差異，但是在大型工程或者需要長期維護的項目中，經常出現寫時一時爽，維護火葬場的災難。
前端中爲了解決JavaScript弱類型語言的弱點，微軟發佈了TypeScript，ts作爲js的超集，自帶了一套非常強大的類型系統，但是爲了兼容js的一些場景，留了any這樣的超級類型，通過any可以繞過ts的類型檢查。
在服務端開發中，我們可以依賴編譯去避免變量、方法聲明前使用的錯誤。而在前端學習中，一些同學可能又是從js開始學起，對於前端中的類型系統使用不夠熟練，對於弱類型語言不夠敬畏，導致了前端開發中出現了大量any繞過編譯期檢查，不判斷直接使用屬性等問題，給線上留下巨大隱患。
重構後代碼如下：
fn1 = (alist: string[]) => {
this.props.myfunc && this.props.myfunc(alist?.length || 0);
};
這段代碼的改動很簡單：通過類型申明在編譯期發現隱患；方法和屬性使用前增加了檢查，避免由於不符合預期的使用導致頁面白屏；代碼加入了更多兜底，上線後更加健壯、安全。
前端代碼在業務邏輯上或許很多時候沒有服務端那麼複雜，大部分場景就是做一些數據適配和渲染的工作，讓全棧化同學在起初上手的時候覺得so easy。但是前端代碼藏有大量的細節容易被忽視，一個老道的前端和一個新手的代碼的差異可能也就多了幾個簡單的“?”和判斷，但是往往魔鬼藏在細節裏，少了任何一個判斷和申明，對應的都是線上的一個定時炸彈。
誤區3 代碼複用全靠粘貼，邏輯和渲染耦合嚴重
重複代碼是一種代碼的壞味道。帶來的問題包括但不限於理解成本和修改成本的增加。
在服務端開發中，我們往往可以通過提煉函數、函數上移等手段對代碼進行優化。在前端中，如果多個頁面都有無限滾動、分頁查詢、防抖、滾動監聽等這類邏輯，應該如何複用呢。如果兩個前端模塊，在樣式和結構上有80%的相似，但是又不完全一樣，要怎麼處理呢？
這時很多前端新手就會祭出CV大法，複製粘貼稍作修改，需求就完成了。但是同時，這也是在給代碼中注入新的壞味道。
當我遇到這個問題時，我的第一個想法是，複製粘貼稍作修改太不優雅了，一定有我不知道的知識點可以解決這個問題。通過我的搜索和學習，我發現前端的代碼複用主要有兩種，邏輯複用和渲染結構複用。
要想代碼能夠複用，就必須找到切面，把內聚的部分剝離，留下恰當的接口進行交互。
第一步要做的就是邏輯和渲染分離。具體到代碼上，一個業務模塊也可以拆分成MVC（model、view、control）三個部分，其中包含了請求數據、轉換數據、組裝數據、編寫不同渲染結構的控制邏輯、生成渲染結構幾個步驟。我們需要把生成渲染結構和前面的步驟分離，負責渲染的組件只負責畫頁面，頁面中的數據都是佔位符，通過外部組件傳入，這就形成了我們自己定義的UI組件。我們在前端開發中會用到一些UI庫，例如antDesign、bizChart等，這些庫的形成就是邏輯和渲染分離思想的體現。
第二步，UI組件的複用。有了UI組件後，我們可以再看看工程中是否有其他語義和功能相似的渲染結構，可以求同存異，相同的部分沉澱到UI組件中，不同的地方通過增加擴展點等方式匹配。
第三步，邏輯的複用。上面提到的無限滾動、分頁查詢、防抖、滾動監聽等邏輯有一定的特點，它們實際上是通用邏輯，在很多頁面都會用到。同時頁面渲染、交互和這些邏輯之間存在一定的關聯關係，例如這些邏輯裏面會維護狀態、會調用頁面的方法、頁面需要調用這段邏輯當中實現的方法等。這時可以藉助函數式編程的思想，把處理流程中不同的邏輯打包成方法，作爲入參傳進來，同時把外部都依賴到的方法，作爲方法的出參返回出去。對於函數式組件，可以通過自定義hook來達到上述目的；對於類組件，可以通過高階函數達到。
關於邏輯複用的部分，空講可能沒有什麼體感，建議讀者有空可以去讀一讀ahook[1]這個倉庫的代碼和demo，最好能在自己的前端項目中，把裏面的自定義hook用起來，對於理解邏輯複用會有很大的幫助。在上一節的Tip2中，我爲了優化自己的表格使用到的useInfiniteScroll便是出自於此。
經驗與解決方案
前端思想的積累，肯定不是一朝一夕的事情。於我而言，持續積累的動機來源於對高質量代碼的追求。在全棧化中不能只滿足於實現需求，而需要想方設法提高自身代碼的質量，對高質量的代碼做到先模仿、再創造。
爲了瞭解更多的工程範式，找到更多可以模仿的高質量代碼，在度過了“存活都是問題”的階段後，全棧化同學更要多讀一些前端代碼，找成熟且相對乾淨的前端工程進行參考。
作爲一個服務端同學，在初入前端時，對前端的語法和生態會產生一些“culture shock”，我在這裏簡單總結了一些TS+React生態和Java+Spring生態的異同，包括在編程模型、設計模式、語法等方面的相同點和不同點，幫助大家遷移和理解。
第三步：守好安穩底線
全棧化的最終一步還是需要安穩上線，讓服務端同學寫前端代碼能不能按時上線？敢不敢上線？都是巨大的考驗。在全棧化過程中我們發現，由於全棧化同學的經驗不足，在研發階段可能出現排期過於樂觀，上線階段容易出現“不知道我不知道”的風險等問題。
對於這類問題，我們團隊唯一一個前端同學在推進全棧化的過程中，也和全棧化的服務端同學一起踩了不少坑，總結了一些經驗和教訓。
排期過於樂觀
首先是排期管理和對老闆的預期管理，全棧化初期階段，由於同學對前端技術棧不夠熟悉，邊學邊做是常態，需要在時間上留足buffer，並且PM也需要做好相應的風險管理，遇到卡點需要及時找前端同學介入。我建議在一個同學開始做全棧化開發的前三個需求，排期按照正常前端排期/0.6的冗餘進行安排，之後逐漸收斂到和前端正常排期一致。
“不知道我不知道”的風險
爲了避免上線階段出現”不知道我不知道“這種問題，我們建立了把關機制和工作難度進階機制，對於一個從頭開始做全棧化的服務端同學，會經歷這樣幾個階段：
- 專業前端做系分，全棧化同學做模塊實現，專業前端做CR和上線；專業前端在系分編寫、開發、CR、迴歸、發佈節點把關。
- 專業前端輔導系分，全棧化同學完成需求實現，迴歸到上線的閉環；專業前端在系分編寫、CR、迴歸節點把關。
- 全棧化同學獨立完成需求系分、實現、迴歸、發佈；專業前端在系分評審、CR把關。
- 全棧化同學完成前後端需求整體閉環，專業前端在系分評審、CR把關。
每個階段做到沒有大的紕漏，能夠獨立完成後，可以挑戰下一個階段的工作。經過幾輪需求的學習，就能循序漸進的知道從需求系分到發佈整個過程中需要注意的問題。此外，我們團隊建立了一套全棧化認證等級，確保每個階段的同學都在做有一定挑戰性但是風險可控的全棧化工作，做好這個等級的工作後，有明確的晉級路徑，去完成下一個等級更加有挑戰性的工作。
這套機制具體可以參考我們團隊前端同學的文章釘釘全棧化實踐總結-前端篇（前端初學者落地指南）。
第四步： 全棧不止是前端開發
回想我在進行全棧化之初，要解決的是團隊內前端資源緊張的問題。但是從全棧化中獲得的不只是前端開發的能力。一個掌握了前端開發能力的服務端同學，在業務開發中就是打通了任督二脈，打開了全新的世界。
一杆到底解決問題的能力
我們小組當前做的業務是釘釘智能差旅，需要把市面上各類出行服務商和商旅服務商的機票、酒店、火車票、用車的服務能力接入到釘釘當中。對接的過程涉及到服務端的接口交互和前端的頁面交互。
以往這類對接需要拉上兩方的前端、後端、產品、PM等一系列角色到一個羣裏，進行對接和聯調，過程中如果涉及到其他一方能力提供方的問題，也需要把相關方拉到羣裏溝通。整個協同鏈條比較長，中間經常會出現“無能爲力的傳話筒”。在具有解決前端問題的能力之前，遇到前端問題時，我就是那個可憐的傳話筒。
例如在和美團的對接過程中，遇到了在美團的釘釘小程序的訂單下單頁面拉起支付寶收銀臺閃退的問題。這時候需要懂釘釘的支付jsapi的前端，懂支付接口的服務端，會定位容器層問題的同學一起進來排查。整個排查過程存在着大量的協同成本。
這時候，具有全棧化能力的服務端同學，一個人就能符合上面所說的這些要求，可以整體收口整個對接工作。我通過和美團側前端同學的溝通，構造出最小可復現問題的demo，並和容器同學一同定位了閃退原因，最終解決了問題，減少了大量溝通、協同的成本。
這種一杆到底解決問題後的酣暢淋漓，是我掌握全棧化能力後收穫的意外之喜。
前後端全局視角
差旅業務沉澱了組織大量的出行數據，分析這些數據對幫助管理人員決策有着一定的幫助。在智能差旅的報表需求中，我牽頭了整個報表模塊的前後端系分。
對客報表的需求本身不算複雜，它的特點是圖表數量多，每個圖表的業務流程比較相近，因此我們希望一套前後端方案滿足所有不同類型的圖表的取數、數據處理、數據渲染。具體而言，我們的方案是用一套schema定義圖表，服務端提供一個統一的接口，根據schema進行數據獲取和組裝；前端根據schema渲染特定的圖表類型並填充數據。
這套方案挺好，美中不足的問題有二：前端和服務端分別需要去理解一遍整套schema，並且圖表中的字段多，前後端的每一個小調整都需要來回對焦，增加了協同成本；每種類型的圖表都是一個前端組件，前端的工作量比服務端大，在前端資源緊張的情況下，前後端排期不匹配的問題加劇。
我們對此的解決方案是：
- 我作爲一個全棧化同學負責整體前後端的系分，並在開發中主要承擔前後端schema解析相關的部分，對其他參與開發的同學儘可能屏蔽schema細節；
- 一部分全棧化同學分到具體的圖表組件的前端開發工作，並行的完成不同圖表業務組件的開發；
- 團隊裏唯一的前端同學負責把控前端性能問題和穩定性相關的難點問題；
基於上述方案，我們通過團隊的全棧化，解決了前後端排期不匹配和協同成本高的問題。在牽頭前後端的整體系分過程中，無論是可行性還是工作量，我都能夠較爲準確的設計和評估，這都是得益於之前積累的全棧化的能力。
全棧化的不止是前後端
作爲一個業務開發同學，相較於後端研發這個職位定義，我更喜歡亞馬遜SDE的職位表述，Software Develop Engineer，業界戲稱Someone Do Everything。
當初因爲前端人力的緊缺，我們團隊邁上了服務端全棧化的道路，並在探索後發現，把服務端開發人力和前端的開發人力放在一起做資源規劃，讓服務端完成日常前端開發中80%以上的工作完全沒有問題。不僅資源瓶頸問題得到的瞭解決，團隊裏開發同學也拓寬了能力邊界。
實際在業務推進過程中，我們可能會遇到各種資源的瓶頸，可能是數據分析的排期不匹配，可能是算法支持的排期不匹配等等。對於開發同學而言，不妨結合自己的興趣點想一想能否向前一步，成爲團隊的多面手，幫助團隊解決資源瓶頸，發揮自己不可替代的價值。
作者｜鞍點
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。