iOS高效程式設計秘訣—堅持程式設計習慣

資料源于網絡

習慣會影響一個人做事的方式，也會直接影響效率。我經常在項目完成後自我總結，有哪些做得好的，有哪些做得不好的？然後把一些好的流程記錄下來，并且重新運用回程式設計中。那些能夠堅持去做的流程，就變成了我的程式設計習慣，這些良好的習慣就成就了我高效的程式設計效率!

一、輕文檔先行

什麼叫輕文檔？其實輕文檔指的是不需要按照标準的軟體工程知識來編寫需求分析，架構設計，子產品設計，流程圖時序圖等文檔，而是采用比較自由的方式，把你要做的事情，還有做事情的步驟描述清楚的文檔。這樣的文檔不需要限制格式，甚至你可以手寫在自己的筆記本上面，隻要自己能看得懂，在開發過程中能夠随時查閱就可以了。

1.

為什麼要寫文檔

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

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

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

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

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

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

2.

文檔寫什麼

①. 準備工作

在開始之前需要準備什麼？例如做一個發送消息的界面，需要有以下的準備：

a. 接口協定

b. 測試環境

c. 測試賬号

準備工作提前做好，往往會加快效率。為什麼要把這些内容記錄下來，是為了在開發過程中可以快速檢索。如果等到開始開發以後再去查聊天記錄，或者是找相關人員詢問，那就慢了。

②. 羅列需要做的小功能點

例如做一個發送消息的界面，就有很多小功能點：

a. 發送界面

b. 發送的資料接口

c. 文本字數限制

如果你仔細一想，可能還會出現以下問題：

a. 是否需要登入？如果未登入，是否要引導登入

b. 對于發送失敗的情況，要如何處理？

c. 字數超出限制時，如何互動？

d. 使用者重複發相同的文本，是否要過濾？

e. 如何處理資料接口的錯誤碼？

當你記錄下這些小功能，并且跟産品經理溝通清楚以後，你的開發周期已經可以初步評估了，并且這時候也已經弄清楚這個需求有多少小功能，需要怎麼劃分子產品，怎麼建構内部流程。

對于部分流程複雜的功能，可以畫一下流程圖輔助了解

③. 記錄這個需求的改動點

如果這是一個新需求，并且跟以前的版本沒有任何關系，則可以忽略這部分

如果是這個需求會影響以前的代碼，則需要将改動部分記錄下來，因為項目中的 bug

有很多是改出來的，列出改動點後會讓自己更清楚新功能帶來的影響，減少很多低級bug

例如新增一個發送圖檔的功能，這個功能會影響聊天視窗的展示，會影響鍵盤，這些改動點就要記錄下來。一來可以輔助思考有沒有漏掉的小功能點，二來在自測試的時候需要覆寫聊天視窗的展示和鍵盤的切換。

④. 羅列自測試内容

編碼完成以後，一定要進行自測試，自測試越仔細，越能提前發現 bug 并修複。如果是測試人員發現了 bug

，然後再送出給你，你這時候再去解決，效率往往會比較低。

以發送消息為例，自測内容也有很多：

a. 正常發送消息

b. 未登入時點選發送

c. 字數超出限制

d. 沒有網絡時點發送

e. 網絡很差時不斷點發送

等等.......

二、開始編碼

是重寫還是保持不變

每做一個新需求，都有可能會面臨這樣的問題：

①. 以前的子產品寫得太爛了，很想重新寫

②. 差不多的需求，以前用了這樣的方式實作，這次想換一種方式實作

會考慮以上的問題，證明你是一個想要不斷進步的人，但是，在做決定之前最好先考慮以下因素：

①. 重寫子產品，很可能牽一發而動全身，要想清楚改動可能帶來的影響，以及解決這些問題需要的時間

②. 使用新方案實作需求，新的方案是否已經經過仔細的驗證，如果沒有，它可能會帶來新問題

其實保持不變也有一些優勢：

①. 可以比之前做得更快，因為你熟悉了

②. 不會出現新問題

考慮好以後，是重寫還是保持現狀，基本已經有答案了

不過保持現狀并不意味着是放棄追求，你可以用業餘的時間來證明你的方案，當它已經穩定了，可行了，那你随時都可以重寫了。

2. 實作需求，Demo

先行

用 Demo 來實作一個需求是最快的，因為它運作快，可以随意修改，而且代碼量少，如果實作過程出現問題，很容易就可以定位到原因。

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

3.

借助工具

①. 代碼模闆（File Template）

我們建立一個視圖，控制器，或者一個 Model，可能會有一些固定不變的函數、屬性需要被定義或者重寫，使用 Xcode

可以建立代碼模闆，在建立類檔案的時候一鍵生成這些代碼，提高效率。

②. 代碼片段（Code Snippet）

一般可重用的代碼，我們會封裝成類或者函數，以便其他地方使用，但有一些代碼是不适合封裝的，例如：

a. 聲明一個屬性

b. 建立一個線程

像這類的代碼，我會做成代碼片段，然後通過 Xcode 的 Code Snippet 自動補充功能來快速完成，一個代碼片段例子：

這裡寫圖檔描述

隻要輸入 @OperateThread 就可以直接完成建立一個操作隊列的代碼，大幅度減少編碼時間。

③. 自動注釋工具（VVDocumenter）

一個可以一鍵建立注釋模闆的工具，減少寫注釋所需的時間

4.

适當添加注釋

如果像官方的 API

那樣，所有地方都添加注釋，那工作量就太大了，需要額外的開發時間，如果隻是針對一些語義不明、有歧義的代碼添加注釋，反而會減少開發時間。

例如一個屬性：

@property (nonatomic, assign) int64_t createTime;

一看就知道是指建立時間，但它到底是不是時間戳？如果是時間戳，那機關是秒還是毫秒？如果還要列印資料以後才能下結論，就太耗時間了。

加上注釋以後，它就一目了然了

/// 建立時間（時間戳 秒）

三、自測

先檢查後自測

完成一個小功能以後，先檢查一下代碼，然後再開始自測，因為代碼可以告訴你很多資訊：

①. 是否有低級錯誤

②. 是否有難以發現的漏洞

③. 流程是否存在問題

如果你編碼完成以後立即自測，可能會進入被動狀态：

①. 這個界面顯示不對

②. 這個資料跟預期對不上

③. 有些不該出現的東西出現了

這時候再反過來去調試代碼，一步步修改，會很慢，因為你編譯和操作都需要時間，而且有些條件不是很容易模拟，那種情況就更耗時間了

自測點要全部過一遍

可能你會覺得這很煩，很浪費程式員的時間，但自測過程發現 bug 是最容易修複的，因為這時候代碼記憶最清晰，最容易找到問題所在。

四、總結

先用文檔理清思路，然後開始編碼，編碼完成以後要檢查代碼并自測。這就是我的程式設計習慣，一直沿用至今。

其實知道一個技巧，并不會提升效率，隻有堅持使用這個技巧，并形成習慣以後，才會真正地提高效率。

歡迎學習本文，轉載請注明出處！