Web 前端項目開發過程導論

你們好，我是tfan，在開發過若干個不一樣類型和規模的 Web 前端項目以後，我發現即便在 2019 年前端開發仍是有不少痛點的。正是由於這些痛點的存在，前端領域纔不斷涌現一些新的框架和工具、觀念和方法來解決這些痛點，也就是不斷造輪子。

這篇文章不討論重複造輪子的問題，我以爲持續的改進和不斷的完善比創新更重要，我但願的是從前端項目的開發過程入手，理清一個典型 Web 前端項目開發過程當中都有哪些參與者、各個參與者在開發過程不一樣階段的關鍵任務是什麼、這些任務之間的上下游依賴和流轉是怎樣的，以及它們是在何時、以何種方式對前端開發產生影響的，從而探索一種標準化的 Web 前端項目開發流程。

一種典型的 Web 前端項目開發過程

下圖是我根據本身的項目開發經驗繪製的一副典型的 Web 前端項目開發過程，

關注開發過程是由於過程相對穩定，穩定決定了咱們有機會發現一些廣泛問題，而解決這些問題則是改進流程的關鍵。

分析影響是但願找到前端開發過程當中的關鍵任務，並思考採起什麼措施來應對影響和完善這些任務。

這種典型的 Web 前端項目的開發流程包括了產品經理、設計師、前端、後端、QA 這幾種角色，也列出了在項目不一樣階段這些角色的主要任務以及和其餘任務的上下文關係。

從這張圖裏能夠看到項目開發過程大體分紅了立項啓動、準備、需求、計劃、設計、開發、測試/發佈幾個階段。下面咱們分別分析一下前端開發在這幾個階段的關鍵任務。

立項啓動

首先要找到合適的人

項目啓動的時候通常會組織一個項目啓動會，一般是召集各個小組的 leader或者沒有 title 的 leader 參加，內容一般是產品部門作下項目背景的簡單介紹，給參與項目的各方同步一下關於客戶、項目目標、大體時間的一些基本信息，讓你們對項目自己有一些共同的認識。

這個階段首要考慮的是人手安排，即須要哪些人、什麼時間來參與到這個項目中來。雖然需求還沒有細化，可是根據已有的信息咱們也大體也能夠估計一下項目的規模，究竟是一個小型、中型仍是大型項目，還須要考慮一下項目的交付時間要求，是寬鬆、緊張、仍是很是緊張。

若是是一個小型項目的話，咱們可能只投 0.5 我的進去，一般會選派手頭現有項目已經進入維護階段或者二期開發的同窗，能夠把主要時間、精力放在新項目上了。

也就是說一個前端開發可能同時參與多個項目，他可能須要一天以內在幾個項目之間進行切換，典型的一種工做狀態是在新項目需求討論、開發聯調的間歇須要快速地處理另外一個項目的一些 issue。

另外一種狀況是項目規模比較大、優先級比較高、時間又很緊張的狀況，這個時候咱們能夠採起 all in突擊的方式，即首先指定一個項目的前端負責人，前期的需求分析、評審、計劃、排期階段只須要他一我的參加，進入設計、開發階段之後再拉更多的前端同窗加入項目，每人分一些已經安排排期的功能點，並行向前推動進度，這種臨時的集中突擊一般不會超過兩週的時間，不會對其餘項目形成什麼大的影響。突擊完成以後，又能夠把項目單獨交給最初的項目前端負責人主要負責跟進，好比跟進需求的變動、接口的更新等，其餘人力就能夠暫時釋放出來了。在 QA 測試階段，若是 issue 比較多的話，還能夠再來一次全軍突擊，集中處理 bug 和 issue。

可以搞得起全軍突擊的一個前提是前端是一個大的資源池能夠統一調度，另外一個要求就是統一技術棧，也便是成員之間的能力是能夠互換的，這就要求咱們在一個組內不要搞多個技術棧，框架、預處理工具、構建工具、UI組件庫、狀態管理、路由管理、異步數據請求、代碼風格和規範這些都要統一，最好是標準化、都是基於同一個腳手架構造的，這樣新同窗參與到項目中的時候能夠快速啓動。

準備階段

凡事豫則立，不豫則廢

項目啓動以後，產品同窗就去寫具體的產品需求文檔了，咱們通常叫 PRD（Product Requirements Docuemnt）。同時前端也要進行需求理解和需求分析，咱們須要分析使用場景、如何知足客戶和項目的要求、分工界面和協做方是誰、會有哪些風險以及如何預防和採起哪些措施等。

用戶是誰？

首先要進行用戶分析，不光是產品和設計師，前端也要了解用戶，由於前端是跟用戶直接交互的，一切產品策劃、UI 設計、後臺能力最終都是經過前端對用戶進行展現。

瞭解用戶須要要考慮咱們服務的的是 C 端用戶仍是 B 端用戶？若是是 C 端用戶的話，它們的畫像是怎樣的？若是是 B 端用戶的話，用戶屬於哪一個行業嗎？它們的特色和習慣是什麼？toC 仍是 toB 決定了對前端的要求以及前端應該關注的重點是不一樣的。 若是是 toC項目的話，可能重點考慮前端性能、多運營商機房部署、CDN 服務、轉化留存等運營的對接支持、數據上報和監控以及 UI 是否夠炫、作一些個性化交互等；若是是 toB 的話可能首要考慮的是 UI 和交互的一致性、交互簡單反饋直觀明顯、幫助信息是否到位、是否會有私有化部署的要求（好比是否要去除對內部系統的依賴）、項目的靈活配置和定製化支持、是否須要準備相應的文檔等；若是是二者都有的話，可能意味着咱們除了提供一套前臺系統以外，可能還須要提供一個後臺管理系統，那麼後臺管理系統和用戶前臺有哪些模塊能夠複用，複用會引入複雜性帶來某些挑戰麼，可能都須要歸入考慮範圍。toB or toC 是一個比較大的話題，可能須要一整篇的長文才能講清楚。

PC、Mobile、小程序？

也就是前端的形態是怎樣的，開發一個面向PC、移動端的 Web 仍是小程序對前端來講多是徹底不一樣的項目。

面向 PC 的不少是 toB 的項目，特色是使用桌面瀏覽器，通常不會有性能問題，可是要考慮多種瀏覽器內核以及對低版本 IE 的支持的狀況。

也有可能能夠經過對用戶作出要求而僅支持有限的現代瀏覽器，也有可能由於行業用戶的特色必需要支持較低版本的 IE 瀏覽器，好比銀行，這可能要跟業務方坦誠溝通，一方面是由於如今客戶對這方面的要求不那麼死板，好比銀行內網也有不少的 chrome，看他們 IT 的狀況，另外一方面對低版本 IE 的支持成本實在過高了。PC 項目在準備階段重點要明確對瀏覽器支持的要求和最小屏幕尺寸等，不然後面可能會出各類幺蛾子。

Mobile 項目的特色是瀏覽器基本都是基於 webkit 內核的，相比瀏覽器的兼容性問題可能更多須要考慮的是交互和性能。

不光是處理器的性能，還包括網絡、延遲、緩存各類狀況。準備好測試機、代理、證書這些移動端Web開發須要的東西，不光要在瀏覽器裏面經過 Mobile Mode 進行開發，必定要在真機上測試運行。

技術選型和調研

用戶和平臺搞清楚以後前端的技術規格要求就基本明確了，還須要對項目中須要用到的新的、難的技術點開始作調研，並開發一些簡單的原型進行驗證，也能夠在組內或者給產品作一些演示，看看是否知足項目要求。

這些都是在準備階段須要作的。這些重點難點的東西不在項目準備階段或者開發初期解決的話，越往項目後期進度壓力越大，越沒有完整時間系統處理，可能會帶來技術上的風險。

項目準備

新建 Git 倉庫、立項申請、要集成的內部服務的申請、項目腳手架搭建、協同系統的賬號設置...

合做方都有哪些？

我作項目的時候通常會列一個清單，把所有的項目成員、職責都列出來。能夠方便地對接是一方面，另外一方面是作項目比較多的時候，有些人多是第一次合做，甚至是跨部門合做，這時候可能就須要作一些標註、記錄一些信息、時間點等，能夠及時地作一些提醒、交接，特別是咱們依賴的上游的合做方。

需求階段

項目啓動以後，各方也都開始從各自關注的角度開始理解需求。需求階段是產品的重頭戲之一，另外一個是產品上線以後的運營分析和策劃階段。在這個階段，產品會集中作一些用戶調研、競品分析的工做，而後開始寫需求；UI 同窗也會經過理解需求和競品分析來肯定總體的設計風格。

需求文檔應當清晰、規範，要講清楚需求的背景、解決的問題、爲何要這麼解決、有沒有更好的方式、競品是怎麼處理的以及爲何。

在產品需求文檔完成之後，項目經理一般會組織你們進行需求評審，通常產品、UI、前端、後端同窗都會參加，一塊兒對需求進行分析。需求評審很重要，一方面是不多有這種機會把項目組的人都彙集在一塊兒進行討論，另外一方面是若是在這個階段各方對需求討論不充分、理解不一致、認識不統一後面的開發、測試階段必定會出差錯。所以，評審前必定要認真閱讀需求文檔並對其進行標註，有問題的地方必定要記下來，評審的時候若是產品經理的陳述還不能解答這些疑問就能夠提問。

對前端而言，需求最終是要落地成實際的操做過程和頁面的，所以在需求分析的時候就已經要考慮前端的模塊劃分、功能點提取和技術實現了。前端在閱讀需求的時候首先要提煉出其中的前端工做（若是 PM 沒有把前端需求單列出來的話），對需求評審能夠有一個本身的 checklist：

• 這個需求若是按照功能點的話能夠劃分爲哪些子需求？
• 是否能夠把該需求歸類成一個個標準的前端模板/模式？好比標準登陸頁、列表頁、表單頁、監控頁、儀表盤、工做臺、標籤頁、分步表單等
• 是否有原型圖？需求描述和原型圖是否一致？
• 是否有流程圖？流程是否有邏輯缺失？
• 功能是否有冗餘？
• 操做路徑是否過深？該突出的重點有沒有突出？
• 是否有不符合 Web 用戶操做習慣的地方？
• 邏輯複雜的地方是否有文案說明？
• 文字、圖片、按鈕排版是否合理？
• 整個產品的用戶交互方式是否一致？
• 能夠提煉出哪些標準化的頁面、可複用的組件？
• 技術實現是否有難度？有沒有哪一個環節會爭議在前端仍是後端實現？
• 要確認需求的實現細節。好比搜索，是支持對哪些關鍵字進行搜索、> 是精確匹配仍是模糊匹配、默認按照什麼進行排序？
• 要確認需求的具體實現方式。好比分頁，是上下翻頁仍是下拉無限加載的方式？
• 須要用戶輸入的數據校驗規則、提示信息和文案是否完整？

有經驗的前端開發人員還應該根據以往的項目經驗和技術積累，在產品經理對功能點也不是特別明確的時候，給出適當的建議。

計劃階段

需求明確之後，先後端、UI、QA 就能夠分別制定開發計劃了。開發計劃能夠按照先把系統劃分爲不一樣的模塊，而後把每一個模塊再劃分爲不一樣的功能點，能夠按照 MECE 法則進行劃分，再估算每一個功能點的工時，最後參照上游 UI 和後臺接口的排期肯定前端每一個功能點的開始和結束時間，而後獲得整個前端開發的功能列表和排期，也就是開發計劃。

計劃的時候要注意前端功能的開發須要頁面+接口聯調纔算完成一個具體的功能，這裏面的頁面開發須要依賴 UI 設計完成的時間，接口聯調則須要依賴後端同窗的開發計劃，所以制定前端計劃的時候要跟後端和 UI 溝通好，功能點的前後順序最好要對齊。還有就是要卡住時間點，由於下游還有 QA 測試同窗，也要給測試留出足夠的時間，因此必要的時候也須要對設計稿和接口完成的時間有所要求。

設計階段

在設計階段，前端主要作的是協助上游的工做。

一方面要跟設計師協做，若是有統一的 UI 規範還好，基本上 UI 組件可能也標準化了。麻煩的是 toC 類的項目，每一個設計師可能會搞一套新的風格、甚至是很是不一樣的組件樣式和交互出來，這就須要對前端組件進行大改或者徹底重寫，這個成本是很高的。

不光是新開發的成本，新東西可能也不夠穩定。這時候就須要跟設計師進行溝通，在保證設計效果的前提下，已有的設計沒什麼毛病的話不要搞一個全新的設計出來，儘可能跟已有的統一，實在要搞評估一下時間是否容許，或者一次不要實現太多的效果，在測試和完善階段能夠繼續改進。像我之前作的一個手機上的日曆組件，開始只提供點擊箭頭切換月份的功能，後來逐步加上了滑動切換、支持展開按月瀏覽收起按周瀏覽、支持按周按月滑動、優化滑動的順滑度、支持無限滑動等，最終作的比較完美，而若是一開始就追求完美，可能項目就不能按時交付了。

另外一方面須要跟後端同窗對齊接口，從 PRD 裏面咱們整理出接口需求，雙方一塊兒討論具體須要哪些接口、參數是放到 URL 裏面仍是請求體內、是否須要分頁、接口文檔以什麼形式提供，這個應該是有一個規範的，可是不一樣的後端團隊規範可能還不同，有些直接用的是第三方的、或者開源的實現，讓他統一規範也不可能。可是咱們能夠有一個最小的要求，就是接口要用 OpenAPI 的形式來描述。

這個對咱們前端後面的開發不管是作 Mock，仍是經過文檔自動生成頁面和測試代碼都相當重要。還要注意的是接口的一致性，好比同屬分頁查詢接口，那麼表示分頁信息的頁碼、頁面大小、總條數這些表示都要一致，由於前端的接口請求方法每每會統一封裝。另外，對接口的時候針對每一個接口必定要事無鉅細，每一個字段的類型、有效值、必選仍是可選、數據校驗規則都要落實下來，由於這些在前端也都是須要落地的，不要怕討論的時間過長，不然後面會花更多的時間。 對於複雜的功能和模塊，在這個階段也能夠繪製一些圖表梳理一下模塊之間的交互和關係，好比數據流圖、流程圖、實體關係圖、UML 的類圖、時序圖等。

開發階段

開發階段前端的窘境是須要並行開發，一方面要作頁面重構，同時還要跟後臺聯調接口，須要兩條線同時工做，也是手工工做最多的時候。但其實能夠做爲一個總體來處理，並且要認清數據模型在裏面的關鍵做用，以一個實體相關的典型操做爲例，以下圖：

這是一個獲取信息進行展現，編輯之後再經過接口寫回後端的典型過程。在這個過程當中前端須要編寫詳情獲取和新建/編輯的接口，須要一個用於展現信息的頁面，和一個用於編輯信息的表單，頁面和表單可能還須要專門的狀態進行管理。

你會發如今這個過程當中全部的步驟都是圍繞着實體在工做的，這個實體最先是在 API 文檔中定義的，經過接口獲取以後可能被加上了一些標識信息，在前端組件裏面可能又混入了完成交互須要的一些信息，好比是否正在被編輯這種狀態，可是不要緊，全部這些流程都是能夠被標準化和固化下來的，而後就能夠經過代碼自動化生成的方式生成基本可用的功能點，或者在此基礎上再進行微調。這會減小大量的手工工做，說實話，有時間前端開發效率高不高跟鍵盤的響應速度有很大關係，大部分時間你可能都是在一遍遍地輸入各類一樣的字段名、格式化、校驗、檢查、異常捕捉。 實現標準化自動生成要有兩個前提，一個是標準模板從哪裏來？也就是你至少要先手動實現一個你認爲是標準的符合最佳實踐的模塊，好比一個支持增刪改查列的模塊，也就是具備完整的列表頁、編輯頁、支持表格操做區、查詢區等，而後把它抽象成模板；若是你還想支持圖表的自動化生成，那就得先抽象一個圖表的標準模板，得先有:chicken:才能下蛋；第二個前提是UI、接口要統1、前端技術棧要穩定，不能前一個項目是 React，後一個項目就要 Vue，再來一個項目用 Angular，複用不了，這種簡單的抽象仍是依賴於具體的框架、組件庫以及封裝的一個幫助類的，好比接口請求庫。UI 和接口總變也不行，對於像雲控制檯這樣有統一的 UI 和接口規範的項目其實滿試用的，或者是內部的管理系統。我曾經開發過一個連業務代碼和測試代碼一塊兒生成的 generator，原先須要0.5 天開發完的模塊後來只須要十分鐘連聯調都一塊兒作完了。 聯調和自測我都是提倡自動化的，能夠看我關於「JavaScript 測試指南」的系列文章。

測試階段

測試階段主要想說一下關於前端 issue 的處理，前端 Issue 不少時候問題的根源不在前端，只是表如今前端。

一種狀況是接口異常，這個時候多是前端請求參數的問題，也有多是後端接口不工做，前端能夠幫助定位問題，而後分配給後端。固然最好的狀況是 QA 同窗能直接發現這是後端接口引發的，因此我之前會給 QA 同窗作分享，分享 chrome 瀏覽器的開發者工具如何使用，有經驗的 QA 同窗碰到問題時通常也會看 console 有沒有異常，若是還能同時看一下 Network 面板下的接口請求和應答就更好了。

另外一種狀況是設計如此，多是 QA 同窗以爲這個地方還能夠改進，或者是開發過程當中產品設計變動了，可是隻同步給了開發而沒有同步測試。

個人經驗就是有 issue 提醒了第一時間查看，快速定位問題而後回覆，若是須要別人來處理更要第一時間把狀況描述清楚，及時評論和流轉。

須要本身處理的話，須要把作過的變動，如何修改的，修改完的效果一併更新的敏捷開發項目管理系統上，有個完整的記錄能夠回溯，最好和 git commit 記錄可以進行關聯。

總結

本文系統地介紹了前端項目開發的關鍵流程，目的是探索出一種標準化操做流程，在這個流程中各個角色能夠各司其職，發揮協同做用，實現卓越研發。

同時，經過對流程的分析，咱們能夠發現前端的瓶頸在於開發階段要處理產品 -> UI -> 前端，產品 -> 後端 -> 前端兩條線，這裏面有大量的手動、重複工做，特別是對於中後臺 Web 項目，咱們能夠經過組件化、標準化、工程化的方式實現部分的自動化和智能化。

關於如何以數據實體爲中心、如何經過 API 文檔自動生成 Mock、頁面和測試代碼，如何設計一種智能組件提升這種自動化生成代碼的適用範圍後面但願寫一篇專門文章集中介紹。

有問題歡迎跟我聯繫 tom@tfan.org。