作者|張海英

研發過程中，開發同學在接到一個需求後，必須要回答兩個問題：做什麼（WHAT）、怎麼做（HOW）。本文就開發與測試在拆解需求時面臨的共性問題，結合自己過往的經驗，總結的一個實用的方法。本文不討論技術選型，僅從思考邏輯上總結應該如何拆解與實現一個給定的需求。歡迎討論。

理解需求拆解的關注點

以帶UI的需求為示例，來看拆解需求過程中的關注點。看下圖，停留20秒，思考兩個問題：（1）從無到有實現以下需求對應的功能頁面，需要做什麼？（2）以下頁面中只修改指定區域的元素，又需要做什麼？

上文兩個問題代表兩種需求型別：第一個問題對應新功能的實現，第二個問題對應已有功能的修改與維護。無論是新功能，還是歷史功能，都需要關注如下點：

需要多少UI（UI元件、功能頁面）（UI=User Interface）

資料從哪裡來？

資料與UI如何關聯？（資料到哪裡去、怎麼去）

使用者行為響應

使用者行為採集

釋出後，如何運維與監控（出現問題的時候，可以有哪些方法幫助問題的排查）

將上文提及的關注點進行抽象與分層後，會得到如下一張圖：

抽象後的架構層次圖可以幫助我們理解實現的層次劃分與結構設計。但是，一般來說，抽象意味著抹平細節。對於一個新手開發或者新手測試來說，需求實現或者測試過程，不僅要關注抽象層面的架構設計，更需要關注實現過程中的細節。接下來對於上文提及到的關注點，下文會展開說明。（在一個多角色的團隊中，實現一個需求，不僅有自己，還有其他角色的開發、測試、PD、運營、資料等，理解關注細節才能保障交付質量）。

透過關注點看實現需求要做些什麼

關注點1：需要多少UI

要繪製多少UI元件、要增加多少UI頁面，首先取決於“需求文件（PRD）”、“視覺互動設計稿”。對於開發來說，請重視需求評審、視覺互動評審。對於質量良好的需求文件或者視覺設計稿，文件中給出的UI元件/頁面範圍一般就是開發要實現的UI範圍；對於質量差的需求甚至是一句話的需求，UI範圍則需要研發“梳理確定”。無論需求文件或視覺設計稿質量如何，研發人員在需求評審、視覺互動評審、技術設計、編碼實現過程中都需重點關注“異常邏輯”。什麼是異常邏輯？比如，一個查詢類的需求，“查詢結果為空”“查詢時無網路”這類場景就屬於“異常邏輯”。很多時候，新手容易出問題或者遺漏的地方就是異常邏輯的處理與顯示。

需求拆解階段，關注UI如何實現的同時，也請務必關注UI的展示物件，包括：圖片與多媒體內容（CDN圖片、OSS圖片檔案、base64編碼後的圖片）、文案（文案的長度、多語言翻譯的來源）、RTL（Right to Left）適配。已一個支援17種語言甚至是更多語言的海外APP開發為示例，這些內容雖不影響開發進度，但是會影響需求在交付時的質量、或者是到了需求實現後期補作業。

實操方法：需求拆解的時，對於UI範圍，可以拆解出如下內容用於輔助後續研發實現：

UI範圍：功能頁面範圍、頁面狀態及狀態的變化邏輯、介面的異常邏輯態等等

頁面元素的拆解：列表元素、卡片元素、動畫元素、UI特效等（這個也是沉澱通用元件的依據）

UI展示的物件：文案的範圍、多語言翻譯的來源、RTL適配的範圍、圖片、短影片等。

關注點2：資料從哪裡來？

這裡的資料是包括使用者直接感知的資料與富媒體內容流，也包括使用者不感知但是用於支撐功能的研發型別的資料。資料的來源包括：網路資料、本地儲存的資料、記憶體資料。不同的資料型別，需求實現的處理有差異，例如：

網路資料：需求拆解時候重點關注介面文件、介面名稱、介面返回的資料欄位（包括欄位型別、範圍、欄位名稱等等）、介面對應的團隊或具體的開發、介面的上下游鏈路（示例：搜尋的介面會涉及廣告、演算法等）、介面測試與聯調方式等。對於新手，需求拆解的時候還需要確認：資料閘道器型別（MTOP閘道器、Node編排後的資料、Web網站對應的資料閘道器等），明確網路資料排程所用的域名（比如，部分APP交易功能的域名與非交易功能的域名是分開的，排程方式也會有差異）。

本地儲存資料：需求拆解階段，要明確本地儲存資料還是自己負責還是使用他人的能力。如果是自己負責則需要進一步判斷資料是寫本地資料庫，還是寫本地檔案；如果是他人負責，資料的讀寫方式與介面是什麼。

記憶體資料：需求拆解重點關注記憶體資料的讀寫方式，資料使用後的釋放方式。

富媒體內容流：圖片、短影片、直播等多媒體流。需求拆解時關注這些內容儲存的形式（以圖片為示例：圖片是CDN的URL，還是OSS的檔案地址或者ID，甚至是base64處理後的編碼結果）；同時還需要判斷這些展示能力是已有的還是需要新引入等。

總結來說，“資料從哪裡來”很好記憶，但是，在真實的研發過程中，“資料從哪裡來”往往是研發過程中最容易出問題的地方。以網路資料為例，典型的問題有：聯調環境不穩定、介面返回的欄位未遵守約定、介面上下游資料鏈路不通導致無法測試等。即使需求完成並且交付上線，也還是會有各類問題，比如：引入了新CDN導致現有的圖片/短影片載入過程的最佳化策略不支援，導致線上反饋效能或者是穩定性問題等。

對於“資料從哪裡來”，在拆解需求的時候，一定要關注到每一個欄位。這麼強調，既因為這個點既影響實際投入工作量，還特別影響交付的需求的可用性與質量。

實操方法：進行需求拆解的時候，圍繞資料從哪裡來，可以拆解出以下內容：

資料邏輯的分層結構圖（根據實際需要）

功能與資料介面的對照關係、介面文件、介面的承接平臺、介面的Mock方式等

功能的資料流轉與邏輯流程圖

關注點3：資料與UI如何關聯？

“資料要到哪裡去，怎麼去”，也可以理解為資料繫結。對於有一定複雜度的需求，“資料與UI如何關聯”很大程度上會決定這個功能的實現與維護難易。需求拆解的時候，無論是選擇MVC、MVP、還是MVVM，資料繫結這個過程比較考驗開發人員的設計能力。我個人將資料繫結總結為如下幾種：

單向資料繫結：資料變化自動驅動UI重新整理，程式碼實現會體現為各種Observer或者Observable等。

雙向資料繫結：資料改變的同時使檢視重新整理，而檢視改變也可以同時改變資料。

無所謂資料繫結，資料關聯到UI是過程式的程式設計，體現為：載入資料、載入成功手工程式碼上屏等。

當然，以上總結是簡化後的總結。對於新功能，建議需求拆解的時候，反覆理解所需的資料來源、充分理解UI範圍，結合控制邏輯，仔細提取關鍵特徵後，充分設計後再進行編碼等操作。設計的時候多借鑑團隊內或行業內的最佳實踐。

對於維護型別的需求，特別是有濃重祖傳特質的功能（比如2013年功能迭代至2022年的需求），則要花點時間理解原有的關聯關係，這個很有可能是一個不大不小的難點。比如，有的歷史功能在實現的時候，資料與UI的關係是透過EventBus/訊息廣播類的事件觸發；還有的功能資料在獨立程序載入，載入完成後透過程序間通訊再透過事件通知機制繫結資料到UI。總結來說，部分歷史功能在最開始的實現，會用到各種酷爽的方案，但是到了後期維護，這類酷爽方法則會以一種超長技術鏈路或者拗口的技術鏈路呈現給維護者，變成一座需要咬牙才能翻閱的“山”。本質上來說，編碼不是人與機器的交流，而是人與人之間透過寫作的交流。對於一個維護性質的功能，掌握原有關係的一種方式就是植入各種測試性的程式碼輔助自己理解。

實操方法：拆解時，資料與UI關聯，可拆解出的內容（資料與UI的關聯，建議將“剋制”作為自己的原則）：

功能的資料流轉與邏輯流程圖

程式碼設計、資料關係流轉設計等等

資料狀態變化、UI重新整理時機等

關聯所用的繫結能力、資料變化後的通知機制等

關注點4：使用者行為響應

相對於上文提及的三個點，這一點相對容易。對於帶UI的需求，按照如下範圍拆解與實現即可：

歸納需求文件或設計文件中的使用者行動點，包括：點選、上下滑動、左右滑動、長按、開鎖屏、虛實鍵盤響應、縮放手勢等等。

行動點的常見處理：頁面跳轉、tips/toast/彈窗等展示、動畫處理、介面縮放、介面關閉等

需約定的介面或規範：頁面跳轉的schema/傳參、二三方能力喚起的方式等

關注點5：使用者行為採集

也就是收集使用者行為的資料，簡稱“資料埋點”。比如，使用者點選按鈕、進入頁面、在某區域停留一定時長之類的行為資料。這些行為資料是產品、資料、BI等角色關心並用於分析使用者特徵的資料。使用者行為採集與使用者行為響應密切相關。

資料埋點作為獨立的關注點強調，是因為即使研發在每個需求都會與“頁面點”“點選點”“曝光點”“自定義事件點”打交道，同時也是最容易出問題的地方，問題示例：：

資料漏採集：有可能是產品/資料同學無明確的資料要求，也有可能是開發漏寫資料埋點程式碼等。

資料點錯誤：包括事件型別錯誤、資料點名稱錯誤，採集時機錯誤、多采集、少採集、資料引數錯誤（資料引數錯誤包括欄位名稱不對、欄位實際傳遞的值不對）等等。

實操方法：研發人員在拆解需求的時候，針對使用者行為採集，check以下點：

需求是否需要採集埋點資料

點的名稱是否符合產品/資料等消費方的要求

引數範圍與引數值是否有要求

需求完成後，資料採集誰驗證？

關注點6：釋出後，如何運維與監控

線上一旦出問題，開發或測試可以用什麼工具或者方法進行排查分析。這就涉及到：需求如何釋出、交付後的功能如何監控、開發過程中是否要提前布點以支撐排查分析工具的使用。

功能釋出形式有多種，例如：灰度、Beta、A/B測試形式釋出、動態配置下發、直接全量等。不同釋出形式對於功能釋出之初的觀測有差異，要支撐不同的釋出形式，具體的實現也有差異：比如，透過Google Play進行APP灰度測試不需要開發人員針對功能做額外處理；以A/B測試形式上線的功能則需要在編碼之初就要考慮透過什麼平臺能力進行，同時還需要編寫對應程式碼。

關於如何監控：需要區分是技術指標監控，還是業務類指標的監控。不同的監控範圍，在需求拆解的時候就要決定哪個平臺進行，比如：業務類的指標可以在xflush平臺上進行（需求拆解時要考慮資料迴流xflush是已有的能力，還是需要新建能力）；效能類指標可以在魔兔/iTrace上觀測；研發問題的排查可以透過SLS進行，還可以自建排查能力。監控雖可以跟隨功能的交付逐步補充完善，考慮需求的完整性，建議是在需求拆解的時候明確監控範圍與形式。畢竟，實現監控也是需要工作量的。

上線後有哪些工具可以用於排查分析問題，在需求實現的時候就需要將能力預置好的。例如，對於“使用者下單”這類容錯較低的需求，研發在需求實現過程中如果沒有寫入足夠的日誌，一旦線上使用者反饋“同一個產品在同一個時間下兩個訂單”，大機率這個問題就是無頭無解問題。

總結來說：需求釋出到線上後如何運維與監控，研發人員在拆解需求的時候需要思考明白：需求釋出形式、上線後期望的監控方式、出問題時可用的排查方式與與排查資料。這些明確後，具體的實現，很容易通過歷史功能、諮詢、查資料等方式學習到。

總結

無論是開發還是測試，對於新手來說，都可以嘗試基於“需要多少UI”、“資料從哪裡來”、“資料與UI如何關聯”、“使用者行為響應”、“使用者行為採集”、“釋出後，如何運維與監控”六個方面進行需求拆解，並且根據拆解後的內容進行需求實現或者是需求測試。這個方法也適用於去分析其他功能的實現。

這個方法是基於有UI的需求進行的總結，還有更多的需求是無UI的：比如，從某個位置同步資料到指定位置並且提供給到其他場景使用；再比如，研發需要一套新的路由框架或需要一套新的資源排程框架。這類需求的拆解與本文總結的方法有相同點，也有不同點，避免本文冗長，不鋪開陳述。

以上方法，是我個人在工作過程中，在接手需求的時候，用來判斷需求影響範圍、評估合作方、評估工作量的方法。歡迎實踐、歡迎討論，歡迎補充與更正。

開啟App看更多精彩內容