基於iOS的軟體工程工作流

• 我是一名iOS開發者，專業為軟體工程，以下主要是一些基於iOS的軟體工程工作流總結和感悟，不僅限於iOS，在使用Mac做開發或做其他開發的都可以一起來討論，總結出最高效的方法。以下全部為手打原創，歡迎大家和我一起討論，共同進步。

在傳統的軟體專案開發中，通常使用瀑布模型進行開發，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品釋出和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段並進行適當的修改，專案開發程式從一個階段“流動”到下一個階段。
但在現如今移動應用盛行的時代，若將瀑布模型應用於移動應用的開發，就會稍顯尷尬，以下將從軟體專案週期的各個階段進行分析和論述,包括在我看來一些實用的技術和軟體建議。

可行性分析

• 在傳統的軟體專案中，可行性分析是首當其衝的，當然在現在的敏捷開發、極限程式設計中也不可或缺。首先最容易被忽略的問題便是做出來的軟體是否會有人用，現如今創業就等於做APP，大多數客戶都是想通過做APP來創業，都想搞個平臺或者商城，希望很多人來使用這個平臺。但大多客戶並不會推廣和運營，只是有一個創業的想法，大多數軟體公司不會說客戶的想法哪裡不好，畢竟軟體公司都需要存活，那麼客戶的任何需求也就都順理成章的成為了可行。

• 除開軟體業務的可行性，客戶最關心的便是軟體製作的價格、工期以及軟體公司是否有能力做出軟體。客戶往往會毫無依據的開始壓工資和壓價格。公司本該需要對專案的工作範圍、時間、質量、成本進行全方位的評估，但根據客戶的要求軟體公司就只有被動的考慮技術上是否能實現，在技術能實現的情況下能否滿足客戶的時間和價格需求。只要以上的都滿足，以做出來為原則，就會認為是可行，公司便會立馬和客戶籤合同。往往這就會忽略掉其他因素，這類軟體做出來過後的可行性就大打折扣，客戶往往也是走一步看一步，最後走向失敗。

• 對一個專案來說當然最理想的情況就是“多、快、好、省”。“多”指工作範圍大，“快”指時間短、“好”指質量高，“省”指成本低。但是，這4者之間是相互關聯的，提高一個指標的同時會降低另一個指標，所以實際上這種理想的情況很難達到。

需求分析

• 在與客戶溝通的過程中要把確定的和需要做的事情都記錄下來形成文件。可以用圖溝通就不要用文字，可以用文件溝通就不要用口。需求獲取可以用OmniOutliner或者Excel來記錄，到最終確定需求的時候便就是需求文件或專案報表，需求獲取到過後可以用Xmind構建出專案基本模組和架構並輸出產品原型，整個過程採用敏捷開發模型，迅速迭代，整個過程所有人都可以檢視和提出建議，最終由產品經理（需求工程師）修訂產品原型和文件，專案經理（技術大牛）根據需求原型和需求文件整理出專案報表和工期表。

• 如果客戶也懂得軟體方面的知識，那麼肯定是嚴格按照標準走是最好的。但現在大多數客戶並不懂得軟體，甚至連自己也不知道自己真正的需求是什麼，他們只說出一個大概，比如要一個直播或者一個商場，然後便讓開發商報價和估計工期，然後便毫無依據的開始壓價格和工期。這就好比客戶說要修一棟別墅，也沒說這棟別墅需要多大，多少層，每層多少個房間。所以通常只有通過製作原型來直觀地體現客戶的想法，傳統的需求文件過於抽象，並沒有介面原型來的直觀。如果需求分析再規範一些的話，還需要通過UML建模，然後再製作介面原型。但是因為客戶的需求時刻都在變化，用UML建模跟不上時刻變化的需求。所以就直接用原型將需求體現出來，讓客戶也能更直觀地看到介面及功能上的變化。在原型設計方面比較流行的是Axure，但是Axure對APP原型的製作不太友好，相比較而言Justinmind就是專門針對移動設計的，線上的原型設計網站墨刀也很不錯，還能實時分享檢視，還有就是Flinto，它還有可供Sketch用的外掛，Balsamiq Mockups也不錯，但僅僅只是草圖，沒有互動設計,特點就是快速。還有Facebook最近開源的御用原型工具Origami Stdio，也能在手機上實時檢視，潛力無窮，具體如何選擇，可以根據具體的需求來。介面尺寸和顏色的標註也可以使用Mark Man，使用起來非常方便,缺點是隻能基於px進行標註，而iOS更希望是pt。

設計

• 當原型確定過後就要進行介面具體設計了，說到介面設計，當然首推Sketch，它不僅是基於向量的，而且操作簡便，上手也非常快，還有非常豐富的外掛，可以和flinto、framer、principle等互動設計軟體無縫銜接，能夠一鍵匯出SVG、Png、PDF等常用格式，也有可供標註的外掛使用，非常方便，是移動設計的不二之選。當互動設計完成後可以使用Kap來錄製Gif圖進行分享。

• 當介面設計完成後便將完全設計好的介面釋出，讓前端可以開始搭建專案架構和介面，後臺人員則開始設計資料庫和資料介面，並形成API文件。

• 整個過程可以使用Git進行版本管理，Github很不錯，不過需要收費，git.oschina是免費的，不是特別重要的專案可以使用，有時候可能會漏掉一些更改，不是很穩定，coding.net也很不錯，正在發展中，潛力很大推薦使用。

編碼

• 在設計完成後，開發人員便可根據介面圖和介面文件開始進行編碼，在編碼之前需要制定一個時間週期表，可以使用OmniPlan來管理專案的進度，coding.net在近期也推出了專案進度管理的功能，團隊協作產品Tower.im也非常值得使用。在編碼時因為會進行團隊多人開發，所以需要使用Git或SVN等版本管理工具，Sourcetree是個非常好用的Git管理客戶端，可以不用使用命令列。在iOS端編碼的時候，可以使用Reveal介面分析工具實時分析介面，可以節省大量的時間，減少出現BUG的機率。在團隊開發中，需要規定好規範並嚴格遵守，包括專案字首和程式碼註釋。在Xcode 8之後，VVDocumenter被繼承在了Xcode中，只需要在需要註釋的程式碼上方按(⌥ Option + ⌘ Command + /)便可快速生成固定格式的註釋。

• 在專案中經常會使用到第三方庫如AFN，Masonry之類的，CocoaPods提供了方便的第三方庫管理功能，只需要編輯Podfile便可隨意管理第三方庫，CocoaPods會直接建立和修改專案的workspace配置，一切都是為了便捷，我們只需要修改pod檔案並不需要過多的關心其他事情，CocoaPods建立的是高度整合的專案。相對於CocoaPods，另一款第三方庫管理工具Carthage的特點是靈活，耦合度不高，整合時不需要整合相應的project，不需要建立workspace,而僅僅需要依賴打包好的framework檔案即可。兩者也可配合使用。

• 在多人開發時最好把自己寫好的東西封裝起來，進行元件化開發，要測試的時候只需要取消註釋掉封裝的那一行程式碼便可以進行測試。

• Charles是Mac上的抓包神器，Charles可以擷取 Http 和 Https 網路封包。支援重發網路請求，方便後端除錯。支援修改網路請求引數。支援網路請求的截獲並動態修改。支援模擬慢速網路。在進行網路程式設計、測試和除錯的時候非常有用。

• 每天最常見的動作就是檢視各種API文件，Dash是一個API文件瀏覽器，可以查詢不同語言和不同框架的API，使用起來非常方便，並且反應迅速。它還具有程式碼片段管理功能，

• 利用Dash的程式碼片段管理功能，我們可以把日常使用頻繁（也就是你經常需要複製貼上）的程式碼儲存起來，然後為其設定一個獨一無二的縮寫，這樣一來原本需要一遍又一遍的敲擊鍵盤重複錄入的繁瑣工作，就可以交給Dash來幫你搞定。

測試

• Instruments是Xcode自帶的強大的測試工具，可以好好利用。

• 蒲公英可以很好的進行應用託管，並進行App應用眾測分發，關鍵還是免費的，還能生成Crash報告和資料統計，非常好用。

• 騰訊 Bugly，是騰訊公司為移動開發者開放的服務之一，面向移動開發者提供專業的 Crash 監控、崩潰分析等質量跟蹤服務。Bugly 能幫助移動網際網路開發者更及時地發現掌控異常，更全面的瞭解定位異常，更高效的修復解決異常。針對移動應用，騰訊 Bugly 提供了專業的 Crash、Android ANR ( application not response)、iOS 卡頓監控和解決方案。移動開發者 ( Android / iOS ) 可以通過監控，快速發現使用者在使用過程中出現的 Crash (崩潰)、Android ANR 和 iOS 卡頓，並根據上報的資訊快速定位和解決問題。

• iOS單元測試，OCUnit（即用XCTest進行測試）其實就是蘋果自帶的測試框架，我們主要講的就是這個。GHUnit是一個視覺化的測試框架。（有了它，你可以點選APP來決定測試哪個方法，並且可以點選檢視測試結果等。）OCMock就是模擬某個方法或者屬性的返回值，你可能會疑惑為什麼要這樣做?使用用模型生成的模型物件，再傳進去不就可以了？答案是可以的，但是有特殊的情況。比如你測試的是方法A，方法A裡面呼叫到了方法B，而且方法B是有引數傳入，但又不是方法A所提供。這時候，你可以使用OCMock來模擬方法B返回的值。（在不影響測試的情況下，就可以這樣去模擬。）除了這些，在沒有網路的情況下，也可以通過OCMock模擬返回的資料。UITests就是通過程式碼化來實現自動點選介面，輸入文字等功能。靠人工操作的方式來覆蓋所有測試用例是非常困難的，尤其是加入新功能以後，舊的功能也要重新測試一遍，這導致了測試需要花非常多的時間來進行迴歸測試，這裡產生了大量重複的工作，而這些重複的工作有些是可以自動完成的，這時候UITests就可以幫助解決這個問題了。