Web開發流程

有人曾開玩笑說，全棧工程師是資本家的陰謀，因為老板想雇一個人來做三個人的工作。

其實在2000年第一次互聯網泡沫破裂之前，那時候的Web工程師也許符合“全棧工程師”的簡單定義：一人包攬整個網站的構建。

那時的Web工程師們所面臨的挑戰比今天小很多，他們可能只是制作一些靜態的頁面，不會面對如今富交互的Web應用程序。那時網站可能包含數據庫和一些HTML表單，但僅此而已，甚至只需要將一些靜態頁發布到服務器上。在網站的前端無需視覺設計和交互設計，因為網站屈指可數，市場競爭很小，工程師僅用一些基本的HTML標簽和閃亮的GIF圖片就可以吸引網民的目光。同時，網站訪問量都比較小，前端資源的體積也不大，無需關注服務器壓力和CDN，網民對加載速度的容忍度比較高，也不需要過多考慮用戶體驗。

但隨著技術的發展、用戶量的增加、客戶端種類變多，每一個小小的細節都需要優化和考慮。在海量的訪問量面前，也許改變一個按鈕的位置和顏色就能影響上千萬的訂單。如今的互聯網產品已不是以一己之力就可以完成的樂高積木了，Web開發需要以某種可控的方式來管理。

于是，所有認真對待互聯網產品的大公司都引入了流水線開發流程，在這條流水線上誕生了多個非常專業的職位。

產品經理：產品經理其實是對一個產品負根本責任的管理者。他通常的工作包括制訂產品規劃、協調多方資源、把控產品方向和質量細節，等等。有時候，他會從頭策劃一個新的產品，而更多的時候，他是在優化已有產品的一個部分。總之，在流水線中，產品經理需要從策劃跟進到發布，是一個非常重要的角色。

用戶研究員：用戶研究員的工作是研究用戶行為，有時候他會從宏觀的角度分析數據，有時候也從微觀的角度分解用戶場景，有時候會召集一些用戶專門來訪談，或者觀察用戶對產品的使用情況。從輸出品的角度來說，用戶研究員一般輸出用戶研究報告來交付給產品經理和交互設計師，作為產品設計的目標參考。

交互設計師：交互設計師常被簡稱為“交互”。他與視覺設計師最大的區別是，交互設計師更多著眼于如何優化用戶界面的信息分布和操作流程。交互設計師的輸出品一般是描述用戶與網站“交互”過程的流程圖，以及描述頁面信息結構的線框圖。輸出的線框圖會交付給視覺設計師。

視覺設計師：在細分交互設計師和視覺設計師的大公司，視覺設計師根據交互設計師輸出的線框圖來做一些潤色和設計，輸出最終的產品視覺稿之后將視覺稿交付給前端工程師。在一些不細分交互設計師和視覺設計師的小公司，二者被統稱為“設計師”，他們的職責就是負責整個用戶界面的設計。

前端工程師：產品視覺稿在得到產品經理和交互設計師等多方確認之后，會交給前端工程師，由前端工程師制作頁面，實現視覺稿以及交互功能。從頭銜上的變化就可以看出，這時候才真正開始編碼。前端工程師需要非常熟悉HTML、CSS和JavaScript，以及性能、語義化、多瀏覽器兼容、SEO、自動化工具等廣泛的知識。

后臺工程師：使用服務器編程語言，進行服務器功能的開發。在編程語言的選擇上，很多公司都會出于團隊已有成員的知識儲備、程序員的供給量或者語言性能方面來進行選擇。在這一方面，后臺語言的選擇是相對自由的一件事，不像前端工程師，為了頁面兼容性，必須使用HTML和CSS。如果關注各大公司招聘信息的話，您就會了解，不同公司使用不同的后臺語言，比如傳統的C#和C++、Java、PHP，或者新潮的RoR和Python。小公司的后臺工程師除了負責功能開發，可能還會負責服務器的配置和調試、數據庫的配置和管理等工作。在大公司，這些工作會分別委派給后臺工程師、運維工程師、數據庫管理員（DBA）等崗位。

運維工程師：運維工程師是跟服務器打交道的人，他會關注服務器的性能、壓力、成本和安全等信息。

測試工程師：顧名思義，測試工程師保證產品的可用性，即使在小公司，這一職位也是不可或缺的。

流水線的優勢

由于有了流水線，其中每個職位的可用工作時間都會作為“資源”來管理，因此需要一位項目經理來把控項目進度，并對人力資源進行調控。比如一個項目立項時，就要預約好這個周期版本需要實現哪些優先級較高的特性，而把優先級不那么高的特性推遲。對于確定在這一周期要實現的特性，就要安排本周進行設計、下周完成開發、下下周進行測試等。

在項目管理中，經常會用到甘特圖。甘特圖（Gantt Chart）是柱狀圖的一種，顯示項目、子項目、進度以及其他與時間相關的系統的進展情況。

流水線在大公司的任何一個嚴謹的大型項目里都是必不可少的，因為無論是Web產品還是App產品，它的復雜性都已經超出了單個工程師可以控制的程度。通過把復雜度分解到各個組件，每一個組件就可以進行很好的質量控制。

Web頁面的生成和傳遞需要經歷復雜的過程，因此容錯能力就是首當其沖要考慮的問題。數據從位于深圳某個機房里的服務器傳輸到用戶手機瀏覽器頁面上進行運算和渲染，這個過程中的每個環節都可能出錯，所以每一步都要做好容錯處理。如果服務器出現錯誤，是否能在30秒內切換到備用機？后臺數據異常時返回什么結果給前端，等等。

Web頁面可以在無數種設備上顯示。兼容性在此時成為了前端工程師需要考慮的一個重要問題。不同的用戶在不同手機上瀏覽頁面，顯示的方法會有些許不同，甚至要考慮到如果瀏覽器不支持JavaScript，則需要給出特定的提示。

模塊化的Web開發流程在很大程度上提高了服務的可靠性和可用性，讓我們對每一個環節都能單獨進行測試。這讓大型Web開發真正變得可管理、可控制、質量可評估。

流水線帶來的另外一個好處是，產品以團隊的方式來運作和生產，公司不會過于依賴某一個工程師。團隊即使失去某個工程師，其他人也可以接手他的工作，快速理解他負責的那一部分工作內容。對于有些經理來說，寧可雇用多個可管理的普通工程師，也不愿意聘請一個不可管理的天才工程師。

所以到現在，我們可以看到大部分互聯網公司都會招聘很多專門的工程師，比如前端工程師、交互設計師，還有一些具體到實現語言的工程師（比如PHP程序員），這都是為了提高可靠性、可用性和可管理性。

剛才我們說到，一個基本的Web棧由服務器、數據庫、服務器端編程語言、HTML、CSS、JavaScript構成；一個基本的App棧由服務器、數據庫、服務器端編程語言、手機客戶端編程語言等技術構成。您可能已經注意到，App棧跟Web棧在后臺技術上幾乎是完全相同的，只有在跟用戶最接近的那一端采用了不同的技術——要么使用HTML制作用戶界面，要么使用客戶端編程語言制作用戶界面。

這是因為，無論是Web還是App，本質上都是軟件，它的架構方法是類似的。服務器端接收數據和發送數據，它無需關注客戶端采取何種技術制作用戶界面。客戶端處理用戶交互以及顯示數據，它不關心服務器使用的是Java還是PHP。如果說開發一款軟件就像制造一輛汽車，那么服務器端就像動力系統，客戶端就像汽車的車身，不同的動力系統和車身可以自由組合搭配（我不太熟悉汽車的制造過程，這里只是作個比喻）。

服務器和客戶端之間通過HTTP協議傳遞信息。正是因為HTTP協議的通用性，使得服務器端和客戶端得以實現完全的技術分離。無論是開發Web服務還是手機里運行的App，一套后臺開發技術，可以為所有的前端展現方式實現軟件的商業邏輯。

HTTP協議類似于汽車組裝過程中的一個通用標準，動力系統和車身都要采用這個統一的標準來實現才可能完美對接。

用戶量的大小、服務器承受壓力的能力、軟件對服務器計算量的要求、對服務器響應速度的要求……諸多因素會影響開發者決定使用哪一種后臺技術。汽車的動力性能主要由發動機來決定，汽車廠商也會根據市場需求、消費者定位和制造成本等綜合考慮使用哪一種發動機。

而前端技術是根據產品所面向的用戶來選擇，這要看用戶是更喜歡用瀏覽器還是手機應用來使用服務。就好像汽車的造型要考慮消費者喜歡什么樣式的外觀。

如果二者功能分離得當，后臺服務跟前臺服務一般可以自由搭配，互不干涉。

“各司其職”的弊端

雖然流水線式的職業劃分和工程管理有很多優點，但是它就像一把雙刃劍，在帶來高可控性、可用性和可管理性的同時，也給工程師帶來了一些困境。

工程師職責不清導致效率低

因為分工太細，所以在不同職業的交接處往往會有一些既不屬于上游，也不屬于下游的“灰色地帶”。

這部分工作沒有明確規定由誰去做，所以有時候時間會浪費在溝通上。員工會認為自己的頭銜代表了自己的責任邊界。比如，一個前端工程師可能會不加思考地實現視覺設計稿，因為他的崗位說明里規定了自己的職責，這其中不包括質疑設計稿，所以他忽視了自己的最終目標：讓產品更好。

在一個開放平等的環境中，他實際上可以對影響可用性和性能的設計提出自己的想法。甚至如果他很熟悉這個項目的話，對設計的一致性和一些交互細節都可以說出自己的看法。

?工程師缺乏主人感導致產品質量差

流水線工作流程對專精工程師的要求是，能很好地執行動作或者執行任務，而不需要對產品的目標有很好的理解。其實在工程師的初級階段，執行任務的能力是必需的，因為他還沒有能力把握產品的目標，而且也需要更多的練習來提升專業能力。但隨著經驗的積累，如果工程師還不能對產品整體有自己的理解和貢獻，就很容易缺乏主人感，要么他會跳槽，要么產品本身缺乏亮點而導致失敗。

?工程師缺乏全局的視野影響個人成長

當工程師希望晉升到更高級的職位，如高級工程師或者管理崗位時，公司對他的大局觀會有更高的要求，這就不僅僅是做好“分內”的工作就行的。

高級工程師需要有對設計的理解、對后臺知識的了解，以及有跨團隊推動項目的能力。長期研究專精的專業知識會讓一個人視野變窄，變成“學術派”，而不是“實踐派”。

?更多角色導致項目效率低下

軟件工程項目與工業中的標準流程化項目有一個很大的區別：標準流程化項目中每一個流程所接受的輸入都是一樣的，所需要的輸出也都是完全相同的。

比如，一個汽車生產流水線，將“造汽車”這個任務分解成“造輪胎”“造方向盤”等。流程拆分得越細，每一個工人或者機器人就能做得越快，整個流水線就會運轉得越快。但是在軟件工程項目中，我們把任務拆分給多個角色，每一個角色需要同樣多的時間去理解需求，在上下游時間的安排中也往往會增加一些緩沖時間，比如周一安排設計，但是為了防止延期風險，會安排周三再制作前端頁面。每一個角色的工作時間都會變長，而且交接也增加了緩沖時間，這樣整個項目的時間就會被延長。