iOS 如何寫出更加嚴謹的應用

標籤：需求   衝突   文檔   需要   develop   傳遞   src   枚舉   任務   

本文旨在介紹一些能夠協助大家避開一些開發誤區的經驗。

 

一: 在開發中，經常能夠遇到共用同一個介面的情況,一般情況下，我們會根據傳入的model去做資料處理和儲存。

 

 當然如果不存在複用的情況下,根本不需要有太多的考慮，這裡不考慮小應用的情況。

 

 在追求介面複用的情況下，一個應用出現一個介面複用兩次，三次都是很常見的吧！那麼我們還是根據傳入的model去處理，這樣對後來閱讀代碼的人來說，是一件很難受的事情。如何處理，才能少出錯或者不出錯，應該是我們的追求。

 

 對於複雜的邏輯，拆分往往能起到清晰明了的作用。這裡是用枚舉和swith case 去處理，每一個不通過介面傳遞過來的處理和回調問題。

 

這樣下次不論誰讀代碼，都有一種清晰明了的感覺，不會出現調用的越多，傳入的參數越多，邏輯越混亂的情況。

 

2:測試環境和正式環境一定要標註，保證自己不會忘。也算是給自己提醒。

最後在獲得資料時候，需要將每個參數都看一遍。保證上傳參數沒有問題。當下意識去提前寫某些東西的時候，其實你也就對可能發生的問題，有了提前的預估，在這之前就提前標記。

 

最近在開發App Extension，手動擼請求的時候，一定要標記根請求地址，防止本地請求和線上請求混淆，避免在開發過程中一直出現找不到服務地址的問題。

3:在開發迭代過程中，UI永遠都是廉價的。每個版本都要刪除一些不必要的控制器Controller去替換，或者當我們需要修改一些特定邏輯的時候，全域搜尋，別忘記用。如果你覺得工程中的命名不符合Apple的開發規範，那麼也別忘了一鍵替換所有類名。

 

4.冗餘的介面需要統一的回調，統一的處理，統一返回給伺服器。類似這樣的介面總共19列，那麼為了減少處理邏輯，統一處理，必不可少。先不說，這有多少人用，先看看如何處理的。

 

5: 編碼記得先寫文檔

 

採用比較自由的方式，把你要做的事情，還有做事情的步驟描述清楚的文檔。這樣的文檔不需要限制格式，甚至你可以手寫在自己的筆記本上面，只要自己能看得懂，在開發過程中能夠隨時查閱就可以了。

 

剛開始工作的時候，總是一接到任務就馬上開始寫代碼，結果可能遇到了很多問題，例如：

1. 需求本身就存在問題，代碼寫到一半以後才發現

2. 部分需求沒有表達清楚，發現的時候才去溝通，結果發現時間不夠，或者跟之前的代碼產生衝突

3. 代碼寫到一半時，發現自己思路不對或者不清晰了

 

最後很有可能導致項目延期。

如果在開發前就把需求分解好，把問題溝通清楚，把要做的點一個個列下來，就能大大地避免這些問題。

 

再比如，我們做App Extension，之前沒做過，那麼最開始的時候應該是收到通知任務 －－－－》 尋找開源項目（這一步需要多做功課，看的越多，熟悉的就多）－－－－－－》根據開源項目，查看AppDeveloper 開發人員文檔 (盡量去讀一遍，保證有個印象)－－－－－－－》確定開發時間－－－－－－完成工作。

 

6.實現需求，最好先寫Demo.

用 Demo 來實現一個需求是最快的，因為它運行快，可以隨意修改，而且代碼量少，如果實現過程出現問題，很容易就可以定位到原因,保證問題能夠快速的被找到。也就是隔離法。

先建立一個 Demo，然後把需要的資源移植過來，把功能實現以後，再移植到項目中，這樣可以節省不少開發時間.

我的備忘錄中，每天都有備忘的代碼，確保自己不會忘。

 

iOS 如何寫出更加嚴謹的應用