負(fù)責(zé)的項(xiàng)目發(fā)布了一段時間，在這期間，發(fā)現(xiàn)了不少邏輯流程上欠考慮的地方。這個項(xiàng)目當(dāng)初開發(fā)的時間比較緊，相對來說也不是部門核心業(yè)務(wù)，因此流程相對來說不是很正規(guī)?；揪褪钱a(chǎn)品經(jīng)理將交互圖丟過來，幾個重要的點(diǎn)文字標(biāo)下，然后口頭溝通下需求，就開始開發(fā)了。在發(fā)布后，陸陸續(xù)續(xù)發(fā)現(xiàn)了一些當(dāng)初考慮不嚴(yán)謹(jǐn)?shù)牡胤?，因此希望能在新版本進(jìn)行改正。在我看來，成熟有序的開發(fā)流程，某種程度上也代表著更加具有邏輯性的思考方式。最近查了些資料，也和前輩們溝通了下，現(xiàn)在來淺談下心得。

明確需求

一個功能，如果能明確其輸入是什么、輸出是什么、在什么情況下期望發(fā)生的行為是什么，那么開發(fā)起來會清晰許多。產(chǎn)品經(jīng)理給出的需求，并不一定就細(xì)致到足以支持開發(fā)。比如我在開發(fā)wifi相關(guān)的功能，產(chǎn)品經(jīng)理可能只會說要一個wifi列表，點(diǎn)擊列表中的wifi會開始連接，然后頂部展示wifi連接狀態(tài)。那么如果wifi開關(guān)關(guān)閉了的表現(xiàn)應(yīng)該是什么？wifi連接失敗的表現(xiàn)是什么？可能這些細(xì)節(jié)都沒有明確。如果在沒有明確的情況下去進(jìn)行開發(fā)，可能就是想到哪里寫到哪里，想到哪個細(xì)節(jié)就處理哪個細(xì)節(jié)，對整體架構(gòu)沒有掌控，導(dǎo)致代碼凌亂難以維護(hù)。更糟糕的是干脆遺漏細(xì)節(jié)，缺少對部分情況的處理，直接影響用戶體驗(yàn)。我不太清楚是否這些是產(chǎn)品經(jīng)理負(fù)責(zé)，但不管怎樣，如果線上出了問題，作為開發(fā)肯定脫不了干系，所以還是自己要把握好。如果發(fā)現(xiàn)不明確的問題，可以再和產(chǎn)品討論，把問題拋出來讓他們?nèi)ハ虢鉀Q方案，但不可以不考慮這些細(xì)節(jié)問題。

那么怎么細(xì)化需求呢？據(jù)說開發(fā)是要需求文檔的，但我這個項(xiàng)目僅有簡單的交互圖。去查需求文檔寫法，發(fā)現(xiàn)也沒有統(tǒng)一的標(biāo)準(zhǔn)，只要明確功能的形態(tài)即可。而咨詢一些開發(fā)前輩，他們提議簡單使用excel表格，將功能細(xì)分剝離，寫明每個功能的行為，并且多想一些使用場景的case，明確在這些場景下功能的行為。因此我使用這個思路來細(xì)化我這個項(xiàng)目的需求。

細(xì)分功能

• 模塊
  劃分功能的第一步是劃分模塊，而不是直接劃分成最小的原子feature。這個一是分類清晰，二是為了之后考慮場景用例方便。事實(shí)上實(shí)踐發(fā)現(xiàn)，很多用例是可以以模塊為單位來考量的，可以在不遺漏case的情況下，盡量減少需要說明的內(nèi)容。還是拿wifi列表的功能舉例，頁面上部是展示wifi狀態(tài)的狀態(tài)欄，下部是wifi列表，狀態(tài)欄還有斷開wifi等按鈕，就是那種最普通的wifi連接界面。那么很明顯的，上部狀態(tài)欄和下部wifi列表可以分成兩個模塊，因?yàn)樽龅氖峭耆煌氖隆Ｈ绻枰€可以繼續(xù)劃分子模塊。依據(jù)就是場景、行為有一定的一致性的一些功能。

• feature
  模塊劃分到最后，一些無法或無需再劃分的功能，作為一個個feature存在。到了feature這步，就需要明確此功能非常具體的一些行為了。比如wifi連接欄中會展示當(dāng)前wifi的ssid，這個功能可以明確為“展示當(dāng)前處理的wifi的ssid，不可為空，不帶有雙引號，不可有<unknown ssid>、0x等非法ssid”。這樣細(xì)化后，就很明確每個功能點(diǎn)究竟要做些什么了。

• 舉例
  對于上述wifi列表的頁面，細(xì)化后可能的樣子如下：

細(xì)分功能

使用場景

在每個功能定義清楚后，還需要考慮使用場景才能使得功能及邏輯嚴(yán)謹(jǐn)。這里的使用場景，其實(shí)類似于測試用例，但不需要那么詳細(xì)。也就是考慮用戶可能有哪些操作，進(jìn)行這些操作后，期望我們的feature對其的響應(yīng)是什么。只有全面考慮了使用場景，才不會致使在開發(fā)過程中遺漏某些情況，導(dǎo)致成為用戶眼中的bug。舉例如下：

使用場景

這里，我直接在上述細(xì)分功能的表格后，直接寫case，這樣feature和case聯(lián)系較緊密，比較直觀。同時這樣可以靈活地區(qū)分針對整個模塊的case和需要區(qū)分feature的case。這邊的使用場景的羅列基本就靠干想，當(dāng)然也可以參考黑盒測試的一些方法，不過不用像寫測試用例那樣一步一步寫的那么細(xì)，基本場景表達(dá)清楚即可。

了解相關(guān)技術(shù)

這一步和上一步，私以為其實(shí)很難分先后。如果沒有明確的需求，怎么知道要去了解什么技術(shù)？但如果有些技術(shù)點(diǎn)不清楚，功能行為也很難定義。比如之前舉例的，定義ssid的展示，包括“不帶有雙引號、不可有<unknown ssid>、0x”，如果不是在開發(fā)中發(fā)現(xiàn)系統(tǒng)提供的廣播信息中會包含這些內(nèi)容，行為定義也不可能說的這么明確。另一個例子，測試反饋表明，在部分機(jī)型上，必須要開啟GPS才能獲得wifi列表。對于這個情況，在大規(guī)模機(jī)型測試前也是不知道的，自然也沒法明確對這種情況的處理。所以現(xiàn)實(shí)中，可能難免還要摸著石頭過河。

但從理論上說，還是需要充分了解相關(guān)技術(shù)。所謂充分了解，并不是需求里說要有“連接wifi”功能，就去google下，然后復(fù)制搜出的代碼，雖然對于新人以及在時間緊的情況下，可能很多人都是這么做的。這么做永遠(yuǎn)只是在使用二手貨，搜出來的代碼可能已經(jīng)過時，或者并非最優(yōu)。如果有時間，還是需要去看一手資料。像android開發(fā)，最主要的可能就是api文檔。比如要確定網(wǎng)絡(luò)是否真正可連，如果直接google搜索，那么搜出來的基本是使用ping的方法，但如果仔細(xì)閱讀文檔，會發(fā)現(xiàn)在6.0以后，是直接有api支持這個判斷的。如果項(xiàng)目僅支持6.0以上，那么就可以直接調(diào)用api，寫出即可靠又優(yōu)雅的代碼了（詳見之前博文）。

相反，如果只是根據(jù)需求搜索技術(shù)，獲得的可能是過時而片面的代碼。因此感覺如果有時間，相關(guān)技術(shù)的一手資料要好好了解下。

其他重要步驟

今天先詳細(xì)講兩方面比較有體會的部分的心得。以下是一些目前認(rèn)為比較重要的，但還沒實(shí)際操作的步驟。等之后涉及到了再細(xì)講。

• 流程圖
• 設(shè)計模式
• 提高效率的技術(shù)與庫
• 單測
• 線上測試用例補(bǔ)充