負責的項目發布了一段時間，在這期間，發現了不少邏輯流程上欠考慮的地方。這個項目當初開發的時間比較緊，相對來說也不是部門核心業務，因此流程相對來說不是很正規。基本就是產品經理將交互圖丟過來，幾個重要的點文字標下，然后口頭溝通下需求，就開始開發了。在發布后，陸陸續續發現了一些當初考慮不嚴謹的地方，因此希望能在新版本進行改正。在我看來，成熟有序的開發流程，某種程度上也代表著更加具有邏輯性的思考方式。最近查了些資料，也和前輩們溝通了下，現在來淺談下心得。
明確需求
一個功能，如果能明確其輸入是什么、輸出是什么、在什么情況下期望發生的行為是什么，那么開發起來會清晰許多。產品經理給出的需求，并不一定就細致到足以支持開發。比如我在開發wifi相關的功能，產品經理可能只會說要一個wifi列表，點擊列表中的wifi會開始連接，然后頂部展示wifi連接狀態。那么如果wifi開關關閉了的表現應該是什么？wifi連接失敗的表現是什么？可能這些細節都沒有明確。如果在沒有明確的情況下去進行開發，可能就是想到哪里寫到哪里，想到哪個細節就處理哪個細節，對整體架構沒有掌控，導致代碼凌亂難以維護。更糟糕的是干脆遺漏細節，缺少對部分情況的處理，直接影響用戶體驗。我不太清楚是否這些是產品經理負責，但不管怎樣，如果線上出了問題，作為開發肯定脫不了干系，所以還是自己要把握好。如果發現不明確的問題，可以再和產品討論，把問題拋出來讓他們去想解決方案，但不可以不考慮這些細節問題。
那么怎么細化需求呢？據說開發是要需求文檔的，但我這個項目僅有簡單的交互圖。去查需求文檔寫法，發現也沒有統一的標準，只要明確功能的形態即可。而咨詢一些開發前輩，他們提議簡單使用excel表格，將功能細分剝離，寫明每個功能的行為，并且多想一些使用場景的case，明確在這些場景下功能的行為。因此我使用這個思路來細化我這個項目的需求。
細分功能
模塊
劃分功能的第一步是劃分模塊，而不是直接劃分成最小的原子feature。這個一是分類清晰，二是為了之后考慮場景用例方便。事實上實踐發現，很多用例是可以以模塊為單位來考量的，可以在不遺漏case的情況下，盡量減少需要說明的內容。還是拿wifi列表的功能舉例，頁面上部是展示wifi狀態的狀態欄，下部是wifi列表，狀態欄還有斷開wifi等按鈕，就是那種最普通的wifi連接界面。那么很明顯的，上部狀態欄和下部wifi列表可以分成兩個模塊，因為做的是完全不同的事。如果需要還可以繼續劃分子模塊。依據就是場景、行為有一定的一致性的一些功能。feature
模塊劃分到最后，一些無法或無需再劃分的功能，作為一個個feature存在。到了feature這步，就需要明確此功能非常具體的一些行為了。比如wifi連接欄中會展示當前wifi的ssid，這個功能可以明確為“展示當前處理的wifi的ssid，不可為空，不帶有雙引號，不可有<unknown ssid>、0x等非法ssid”。這樣細化后，就很明確每個功能點究竟要做些什么了。舉例
對于上述wifi列表的頁面，細化后可能的樣子如下：
使用場景
在每個功能定義清楚后，還需要考慮使用場景才能使得功能及邏輯嚴謹。這里的使用場景，其實類似于測試用例，但不需要那么詳細。也就是考慮用戶可能有哪些操作，進行這些操作后，期望我們的feature對其的響應是什么。只有全面考慮了使用場景，才不會致使在開發過程中遺漏某些情況，導致成為用戶眼中的bug。舉例如下：
這里，我直接在上述細分功能的表格后，直接寫case，這樣feature和case聯系較緊密，比較直觀。同時這樣可以靈活地區分針對整個模塊的case和需要區分feature的case。這邊的使用場景的羅列基本就靠干想，當然也可以參考黑盒測試的一些方法，不過不用像寫測試用例那樣一步一步寫的那么細，基本場景表達清楚即可。
了解相關技術
這一步和上一步，私以為其實很難分先后。如果沒有明確的需求，怎么知道要去了解什么技術？但如果有些技術點不清楚，功能行為也很難定義。比如之前舉例的，定義ssid的展示，包括“不帶有雙引號、不可有<unknown ssid>、0x”，如果不是在開發中發現系統提供的廣播信息中會包含這些內容，行為定義也不可能說的這么明確。另一個例子，測試反饋表明，在部分機型上，必須要開啟GPS才能獲得wifi列表。對于這個情況，在大規模機型測試前也是不知道的，自然也沒法明確對這種情況的處理。所以現實中，可能難免還要摸著石頭過河。
但從理論上說，還是需要充分了解相關技術。所謂充分了解，并不是需求里說要有“連接wifi”功能，就去google下，然后復制搜出的代碼，雖然對于新人以及在時間緊的情況下，可能很多人都是這么做的。這么做永遠只是在使用二手貨，搜出來的代碼可能已經過時，或者并非最優。如果有時間，還是需要去看一手資料。像android開發，最主要的可能就是api文檔。比如要確定網絡是否真正可連，如果直接google搜索，那么搜出來的基本是使用ping的方法，但如果仔細閱讀文檔，會發現在6.0以后，是直接有api支持這個判斷的。如果項目僅支持6.0以上，那么就可以直接調用api，寫出即可靠又優雅的代碼了（詳見之前博文）。
相反，如果只是根據需求搜索技術，獲得的可能是過時而片面的代碼。因此感覺如果有時間，相關技術的一手資料要好好了解下。
其他重要步驟
今天先詳細講兩方面比較有體會的部分的心得。以下是一些目前認為比較重要的，但還沒實際操作的步驟。等之后涉及到了再細講。
- 流程圖
- 設計模式
- 提高效率的技術與庫
- 單測
- 線上測試用例補充
