if 我是前端團隊 Leader，怎麼作好概要設計

時間 2019-11-05

標籤前端團隊 leader 怎麼作好概要設計简体版

原文原文鏈接

if 我是前端團隊 Leader，怎麼制定前端協做規範?在掘金目前已經突破740個👍了, 謝謝你們的支持，這篇文章是前者延展。繼續介紹我在前端團隊管理方面的思考和探索。html

軟件工程中有一個軟件設計階段，通俗的講就是在開工以前將能肯定的肯定下來，把該考慮的考慮了。這相比在開發階段發現問題，解決的成本要低不少。前端

若是按照教科書上的定義，軟件設計就是是一個將需求轉變爲軟件陳述（表達）的過程。通常有概要設計(或者初步設計， Preliminary design)和詳細設計(Detail design). 概要設計將需求轉換成數據和軟件框架，而詳細設計將框架逐步求精細化爲具體的數據結構和軟件的算法表達。本文講述的是前端項目的概要設計。react

相比後端開發, 對於前端，’軟件設計‘不多被說起，也有多是一直以來前端的工做都比較'簡單'，因此比較粗放。通常給了原型和接口文檔就直接開幹了。可是隨着前端開發者的工做愈來愈複雜，或者項目/團隊的規模變大，咱們愈來愈須要在編碼以前進行合理的設計。git

做爲前端入門Leader, 最近面臨了一些問題: 好比項目分工問題、項目維護缺少文檔問題, 讓我開始重視軟件設計階段. 就目前看來，作好前端概要設計，至少有如下好處:github

事前. 設計文檔是開發的藍圖，後續開發能夠按照這個文檔逐步展開。良好的設計能夠保證開發沿着正常軌道邁進。
- 咱們在設計階段會進一步梳理業務流程，加深對業務流程的理解，甚至能夠找出業務流程中的不合理的東西。
- 模塊拆分。這個階段咱們會識別各個模塊之間邊界和重疊，將重疊的(共享的)部分抽離出來。另外模塊是基本的開發工做單元，也是咱們團隊分工和時間評估的基礎。
- 考察關鍵的技術點。提出多種備選方案，充分考慮各類風險, 選擇符合實際需求的方案
過後. 設計文檔對過後的軟件維護、功能新增，有很大的幫助

下面開始介紹，前端在軟件設計階段應該考慮東西，或者說前端的概要設計文檔裏面應該包含哪些東西. 固然這些只是一些初步的想法，隨着後面深刻實踐後，本文會持續更新迭代.web

文章大綱算法

系列文章shell

這方面個人經驗實踐比較少, 也沒有在大廠待過，因此本文只是個人一些思考和嘗試, 可能不太現實。若是你或你的團隊有這方面的更好的實踐，歡迎分享給我。感激🙏數據庫

關鍵業務流程的梳理

開發任何一個產品以前，首先要確保的是對業務流程的理解，不然就會出現南轅北轍的狀況。小程序

在現實項目中發生過屢次這類狀況：項目到達測試階段，測試人員才發現應用的業務實現和產品定義不同，或者業務流程不合理。這實際上是一種很低級的失誤，改動的成本可能很高，甚至會讓你的全部工做白乾。

管理比較成熟的公司會有不少手段來規避這種失誤。

好比定義明確需求文檔，這方面能夠模仿一些標準/規範(Spec)的寫做方法，嚴格定義一些關鍵字，避免模棱兩可的描述;

另外能夠經過各類宣貫會議，將相關人員彙集在一塊兒，統一導入需求。在這些會議中能夠進行頭腦風暴，優化或細化需求的定義、發現缺陷和風險，分析可行性等等。經過不斷溝通，成員之間能夠分享交叉知識，確保對業務一致理解.

所以，我以爲前端在設計階段也應該像後端同樣，用流程圖或者時序圖這類工具，將關鍵業務流程描述清楚. 尤爲是涉及到先後端, 跨系統/跨頁面/跨終端之間的業務交互的場景.

舉個例子，好比咱們在作一個’掃碼登陸‘功能。咱們能夠將跨終端的業務梳理出來：

從上面的業務梳理中咱們能夠識別出業務對象的基本行爲和狀態. 例如二維碼的狀態轉換圖:

固然, 簡單的增刪查改花篇幅去闡述沒有意義。咱們只關注應用關鍵的業務流程.

總之，業務流程的梳理，能夠加深咱們對業務的理解，是後續設計步驟和開發的基礎.

關鍵技術點

描述應用採用的或者涉及到關鍵技術/算法, 也能夠認爲是技術選型.

好比典型的有視頻直播應用，涉及到的各類直播方案:

RTMP 協議
RTP協議
HLS 協議
flv.js
WebRTC協議
等等

在開啓一個項目以前, 咱們須要對項目涉及到的關鍵技術點進行調研和測試，最好多找幾個替代方案，橫向地比較它們的優點和劣勢。選擇符合項目或團隊本身狀況的方案. 若是時間充足, 能夠寫一些Demo，實地踩一下坑.

若是有多個備選方案，最後要甄選出推薦方案，並說明選擇的緣由和考慮。

提早作好技術的調研和選型，肯定可行性，不至於開發處於被動的境地.

關於如何進行技術選型，我在if 我是前端團隊 Leader，怎麼制定前端協做規範?進行了簡單的討論，能夠參考一下.

模塊設計

現代前端通常都使用組件化思惟進行開發，這時候咱們的應用其實就是一顆由不一樣粒度的組件複合起來的組件樹，這顆組件樹最終會體現到項目的目錄結構上。 在設計階段咱們能夠根據產品原型或UI設計稿，識別出各類頁面和組件。

正常的應用，咱們能夠分三個層級進行拆分:

入口層

稍微複雜一點的應用可能有多個入口，這些入口呈現的頁面可能差別很大. 下面是一個常見的劃分方法:

按子系統劃分: 好比前臺和後臺。
按角色劃分：好比管理員、普通用戶
按入口劃分：好比移動端、桌面端等等

頁面層

下一步就是識別各類頁面，這些頁面即對應到咱們的前端路由配置規則. 如下面簡單的應用爲例:

關於模塊的劃分，我建議使用思惟導圖進行組織。模塊劃分這個環節，你能夠召集團隊的其餘成員開個會議，一塊兒進行頭腦風暴。你們參照着產品原型，識別出各類模塊或組件的邊界和交集, 討論怎麼設計頁面的數據流、組件的接口等等, 這樣能夠利用集體智慧，讓模塊拆分更加合理，另外能夠促進團隊成員提早熟悉項目的結構。

因此說軟件設計不是架構師或設計人員一我的的事，應該鼓勵你們一塊兒參與，設計文檔是整個軟件團隊的產出, 是團隊的知識沉澱。

上面的應用經過頁面層劃分後，結果大概以下：

在這個階段咱們會肯定如下內容:

頁面以及路由設計, 肯定頁面之間的層級關係
頁面之間交互流程、數據傳遞

關於路由設計，能夠遵循一些規範，筆者比較推薦Restful URL規範, 這篇文章寫得也不錯.

路由之間的數據傳遞通常有如下幾種方式:

少許數據：能夠經過路由變量(例如/posts/:id)或者查詢字符串形式傳遞. 還有若是你使用的是基於History API的前端路由模式，可使用History的state對象來存儲一些狀態(最大640k)
大量數據：能夠經過全局變量，或者狀態管理器的機制進行存儲, 無論這種存儲在內存的方式，一旦頁面刷新就會丟失。因此也能夠考慮存儲在本地緩存中, 例如LocalStorage

組件層

Ok，再往下拆分，不過要量力而行。對於一個很是複雜的項目來講，可能有成千上百個組件，並且這些組件在將來可能會不斷變化，在設計階段考慮這些拆分可能須要花費不少時間，並且收益並不明顯。

那麼須要怎麼把握粒度呢？其實組件層設計階段的主要目的是找出重複的、或者結構相似的組件，將它們抽取出來統一的設計，在多個頁面進行復用. 並非把全部的組件都列舉出來。

我在React組件設計實踐總結02 - 組件的組織這篇文章中，專門介紹React組件如何進行組織和拆分。其中提出瞭如下集中模式:

容器組件和展現組件分離。或者說分離視圖和邏輯, 業務組件和傻瓜組件. 純邏輯的東西放在Hooks中，使用起來會更加方便
純組件和非純組件. 能夠認爲純組件徹底依賴外部輸入
有狀態組件和無狀態組件
佈局組件和內容組件
統一設計同一類型組件的接口. 好比表單組件應該保持接口統一

仍是上面的示例應用，申報頁面有很是多的表單項，並且常常變更，另外你會發現它和預覽頁面的結構是差很少的，並且後面可能會有桌面端頁面。

通過討論，咱們決定採用配置文件的方式來動態渲染表單頁和預覽頁。實現一套配置控制移動端申請表單、桌面端申請表單、移動端預覽、桌面端預覽頁面。

相似上面這種應用場景，前期的組件層設計就頗有必要了。

分工

將模塊拆分清楚後，咱們就能夠針對這些模塊進行合理的分工和時間評估。基本上有三個步驟：

經過上面的步驟，咱們識別出來了各類模塊，接着咱們要肯定下來這些模塊之間的依賴關係，這些依賴關係影響它們是否要做爲一個總體進行實現。最後再根據業務的優先級或依賴關係決定這些模塊簇的實現優先級。

Ok, 如今能夠將這些模塊簇按照優先級排序, 加上評估時間(人天)，整理成一個清單。若是大家使用看板來進行項目管理, 能夠將它們做爲一個任務單元，貼到看板中.

1. Foo 功能
  - c 2d
  - d 1d
  - f 3d
2. Bar 功能
  - e 1d
  - h 0.5d
3. Baz 功能
  - g 1d
4. Fu 功能
  - a 4d
  - b 1d

總計人天: 13.5
複製代碼

任務的分工有不少策略, 例如：

橫向劃分
- 公共組件 vs 業務組件(對接業務)
- 自上而下 vs 自下而上(指的是組件樹)
垂直劃分: 按照獨立的垂直模塊分工

狀態設計

前端組件化伴隨而來的是各類數據驅動或數據流驅動的開發模式。這種模式下，前端應用能夠總結爲這樣一個等式:

view = f(state)
複製代碼

也就是說視圖是數據或者數據流的映射. 可見狀態管理對現代前端開發的重要性。

狀態的設計和後端對象模型設計差很少。你須要根據業務和頁面渲染要求抽象出各類對象模型，以及縷清對象模型之間的關係。這個階段可能須要和後端緊密結合，才能肯定出合理的對象結構。

固然狀態的設計還跟你選擇的狀態管理方案也有關係, 不一樣狀態管理器方案體現的思想差別較大：若是你選擇Redux，那麼應用的狀態就是一顆對象樹；若是你選擇Mobx，應用的狀態可能由多個模型對象組成，更接近傳統的OOP模式。

若是採用OOP設計方法，能夠繪製UML圖，可視化表現對象的結構和關係:

(圖片來源: zongren.me/2016/12/30/…)

我在React組件設計實踐總結05 - 狀態管理這篇文章花了不少篇幅來介紹各類狀態管理器的思想和開發模式, 因此這裏就不展開了:

Redux 狀態設計:

Mobx 狀態設計:

接口設計

若是前端團隊在接口設計方面有主導權, 或者使用BFF架構(服務於前端的後端)，在設計階段咱們須要對各種接口進行設計。

不過通常主導權都掌握在後端手裏，由於前端對業務的關心程度較低，後端通常會綜合考慮各端的接口需求、數據庫存儲效率、可維護性等多個方面來設計接口, 這時候前端就是接口的用戶，咱們有責任來驗證後端接口是否符合需求.

我在if 我是前端團隊 Leader，怎麼制定前端協做規範?已經說起了各類接口規範. 這裏不予贅述。

版本規劃

經過上面的步驟，咱們基本已經瞭解咱們須要作什麼、須要花多久。接下來，

應該制定一個版本計劃，對於一個大項目能夠拆分爲多個里程碑, 估計版本發佈的時間. 加不加班就看你了，做爲Leader要綜合考慮各類影響因素，實事求是合理地安排版本發佈計劃。

這個發佈計劃可能還須要通過PM和項目經理審覈, 做爲前端項目，開發計劃一般還依賴於後端團隊.

這個版本計劃中會包含這些內容:

版本號
發佈時間
包含的主要模塊

驗證

驗證，或者稱爲’測試指導‘。除了測試團隊提供的測試用例，從開發(白盒)的角度還須要注意哪些東西?

產品或者測試可能只會從業務的層次考慮應用的運行，咱們須要從研發的角度，充分考慮各類異常狀況、性能瓶頸、進行風險評估. 闡明風險的應對方案等待.

這些狀況也能夠反饋給測試團隊，以完善測試的用例.

項目要求和目標

一些需求是要提早肯定下來的，對於前端來講，比較典型的就是瀏覽器兼容性要求。你可不要等到項目上線後，纔跟我提用戶要求兼容IE6!

這些項目要求可能會影響咱們的開發成本、選型、測試和其餘因素的評估。基本上，對於一個前端項目來講，這些要求是要提早問清楚的:

瀏覽器兼容性
運行環境. 例如操做系統、小程序等等
時間點
性能指標要求. 例如首屏指標、數據量指標

文檔索引

前端項目開發可能會關聯不少文檔，這些文檔是分散的，在設計文檔中最好把它們聚合起來，方便查閱和引用. 例如:

需求文檔
DEMO, UI設計稿
測試用例
接口文檔
UI設計規範文檔
前端規範文檔
...

構建說明

若是你的項目須要設計構建流程，也能夠在設計文檔中簡單說起。

例如如何編譯和運行? 如何測試和調試? 如何部署或發佈？ 代碼如何組織？開發工做流、編碼約定等等

新成員經過這些說明能夠快速上手開發.

持續迭代

設計文檔不是一次性的，它應該跟隨項目不斷的迭代，否則就失去了文檔的意義。

模板

最後，規範一些設計文檔的格式和內容

# XXX 概要設計文檔

## 背景

填寫項目的背景, 或者開發或重構的目的/出發點.

## 關鍵業務流程

能夠放置關鍵的業務流程圖、狀態圖、對象圖等等. 梳理關鍵的業務流程

## 關鍵技術描述

可選, 描述項目中使用到的關鍵技術、算法、選型結論等等

## 模塊拆分

- 入口
- 頁面路由
- 組件設計

可使用思惟導圖描述

## 狀態設計

描述應用涉及的關鍵領域對象, 好比外形、行爲和關係. 若是是OOP方式，可使用UML描述

## 接口設計

可選，如題

## 項目要求和目標

項目目標、運行環境、兼容性要求、性能指標等等

## 驗證

可選, 風險評估、異常狀況考慮、特殊測試規則、測試指導等等

## 分工和版本計劃

可選, 能夠在單獨文檔或者看板中維護

## 構建說明

可選, 項目組織、構建、測試說明

## 文檔索引

相關文檔的索引和連接

## 參考資料

文檔中索引頁的外部參考資料

## CHANGELOG

列出本文檔修改的歷史紀錄。必須指明修改的內容、日期以及修改人

複製代碼