[[145448]]

習(xí)慣會(huì)影響一個(gè)人做事的方式，也會(huì)直接影響效率。我經(jīng)常在項(xiàng)目完成后自我總結(jié)，有哪些做得好的，有哪些做得不好的？然后把一些好的流程記錄下來(lái)，并且重新運(yùn)用回編程中。那些能夠堅(jiān)持去做的流程，就變成了我的編程習(xí)慣，這些良好的習(xí)慣就成就了我高效的編程效率!

一、輕文檔先行

什么叫輕文檔？其實(shí)輕文檔指的是不需要按照標(biāo)準(zhǔn)的軟件工程知識(shí)來(lái)編寫(xiě)需求分析，架構(gòu)設(shè)計(jì)，模塊設(shè)計(jì)，流程圖時(shí)序圖等文檔，而是采用比較自由的方式，把你要做的事情，還有做事情的步驟描述清楚的文檔。這樣的文檔不需要限制格式，甚至你可以手寫(xiě)在自己的筆記本上面，只要自己能看得懂，在開(kāi)發(fā)過(guò)程中能夠隨時(shí)查閱就可以了。

1. 為什么要寫(xiě)文檔

剛開(kāi)始工作的時(shí)候，總是一接到任務(wù)就馬上開(kāi)始寫(xiě)代碼，結(jié)果遇到了很多問(wèn)題，例如：
①. 需求本身就存在問(wèn)題，代碼寫(xiě)到一半以后才發(fā)現(xiàn)
②. 部分需求沒(méi)有表達(dá)清楚，發(fā)現(xiàn)的時(shí)候才去溝通，結(jié)果發(fā)現(xiàn)時(shí)間不夠，或者跟之前的代碼產(chǎn)生沖突
③. 代碼寫(xiě)到一半時(shí)，發(fā)現(xiàn)自己思路不對(duì)或者不清晰了
***很有可能導(dǎo)致項(xiàng)目延期。

如果在開(kāi)發(fā)前就把需求分解好，把問(wèn)題溝通清楚，把要做的點(diǎn)一個(gè)個(gè)列下來(lái)，就能大大地避免這些問(wèn)題。

2. 文檔寫(xiě)什么

①. 準(zhǔn)備工作

在開(kāi)始之前需要準(zhǔn)備什么？例如做一個(gè)發(fā)送消息的界面，需要有以下的準(zhǔn)備：
a. 接口協(xié)議
b. 測(cè)試環(huán)境
c. 測(cè)試賬號(hào)

準(zhǔn)備工作提前做好，往往會(huì)加快效率。為什么要把這些內(nèi)容記錄下來(lái)，是為了在開(kāi)發(fā)過(guò)程中可以快速檢索。如果等到開(kāi)始開(kāi)發(fā)以后再去查聊天記錄，或者是找相關(guān)人員詢問(wèn)，那就慢了。

②. 羅列需要做的小功能點(diǎn)

例如做一個(gè)發(fā)送消息的界面，就有很多小功能點(diǎn)：
a. 發(fā)送界面
b. 發(fā)送的數(shù)據(jù)接口
c. 文本字?jǐn)?shù)限制

如果你仔細(xì)一想，可能還會(huì)出現(xiàn)以下問(wèn)題：
a. 是否需要登錄？如果未登錄，是否要引導(dǎo)登錄
b. 對(duì)于發(fā)送失敗的情況，要如何處理？
c. 字?jǐn)?shù)超出限制時(shí)，如何交互？
d. 用戶重復(fù)發(fā)相同的文本，是否要過(guò)濾？
e. 如何處理數(shù)據(jù)接口的錯(cuò)誤碼？

當(dāng)你記錄下這些小功能，并且跟產(chǎn)品經(jīng)理溝通清楚以后，你的開(kāi)發(fā)周期已經(jīng)可以初步評(píng)估了，并且這時(shí)候也已經(jīng)弄清楚這個(gè)需求有多少小功能，需要怎么劃分模塊，怎么構(gòu)建內(nèi)部流程。

對(duì)于部分流程復(fù)雜的功能，可以畫(huà)一下流程圖輔助理解

③. 記錄這個(gè)需求的改動(dòng)點(diǎn)

如果這是一個(gè)新需求，并且跟以前的版本沒(méi)有任何關(guān)系，則可以忽略這部分
如果是這個(gè)需求會(huì)影響以前的代碼，則需要將改動(dòng)部分記錄下來(lái)，因?yàn)轫?xiàng)目中的 bug 有很多是改出來(lái)的，列出改動(dòng)點(diǎn)后會(huì)讓自己更清楚新功能帶來(lái)的影響，減少很多低級(jí)bug

例如新增一個(gè)發(fā)送圖片的功能，這個(gè)功能會(huì)影響聊天窗口的展示，會(huì)影響鍵盤(pán)，這些改動(dòng)點(diǎn)就要記錄下來(lái)。一來(lái)可以輔助思考有沒(méi)有漏掉的小功能點(diǎn)，二來(lái)在自測(cè)試的時(shí)候需要覆蓋聊天窗口的展示和鍵盤(pán)的切換。

④. 羅列自測(cè)試內(nèi)容

編碼完成以后，一定要進(jìn)行自測(cè)試，自測(cè)試越仔細(xì)，越能提前發(fā)現(xiàn) bug 并修復(fù)。如果是測(cè)試人員發(fā)現(xiàn)了 bug ，然后再提交給你，你這時(shí)候再去解決，效率往往會(huì)比較低。

以發(fā)送消息為例，自測(cè)內(nèi)容也有很多：
a. 正常發(fā)送消息
b. 未登錄時(shí)點(diǎn)擊發(fā)送
c. 字?jǐn)?shù)超出限制
d. 沒(méi)有網(wǎng)絡(luò)時(shí)點(diǎn)發(fā)送
e. 網(wǎng)絡(luò)很差時(shí)不斷點(diǎn)發(fā)送
等等.......

二、開(kāi)始編碼

1. 是重寫(xiě)還是保持不變

每做一個(gè)新需求，都有可能會(huì)面臨這樣的問(wèn)題：
①. 以前的模塊寫(xiě)得太爛了，很想重新寫(xiě)
②. 差不多的需求，以前用了這樣的方式實(shí)現(xiàn)，這次想換一種方式實(shí)現(xiàn)

會(huì)考慮以上的問(wèn)題，證明你是一個(gè)想要不斷進(jìn)步的人，但是，在做決定之前***先考慮以下因素：
①. 重寫(xiě)模塊，很可能牽一發(fā)而動(dòng)全身，要想清楚改動(dòng)可能帶來(lái)的影響，以及解決這些問(wèn)題需要的時(shí)間
②. 使用新方案實(shí)現(xiàn)需求，新的方案是否已經(jīng)經(jīng)過(guò)仔細(xì)的驗(yàn)證，如果沒(méi)有，它可能會(huì)帶來(lái)新問(wèn)題

其實(shí)保持不變也有一些優(yōu)勢(shì)：
①. 可以比之前做得更快，因?yàn)槟闶煜ち?br /> ②. 不會(huì)出現(xiàn)新問(wèn)題

考慮好以后，是重寫(xiě)還是保持現(xiàn)狀，基本已經(jīng)有答案了
不過(guò)保持現(xiàn)狀并不意味著是放棄追求，你可以用業(yè)余的時(shí)間來(lái)證明你的方案，當(dāng)它已經(jīng)穩(wěn)定了，可行了，那你隨時(shí)都可以重寫(xiě)了。

2. 實(shí)現(xiàn)需求，Demo 先行

用 Demo 來(lái)實(shí)現(xiàn)一個(gè)需求是最快的，因?yàn)樗\(yùn)行快，可以隨意修改，而且代碼量少，如果實(shí)現(xiàn)過(guò)程出現(xiàn)問(wèn)題，很容易就可以定位到原因。

先建立一個(gè) Demo，然后把需要的資源移植過(guò)來(lái)，把功能實(shí)現(xiàn)以后，再移植到項(xiàng)目中，這樣可以節(jié)省不少開(kāi)發(fā)時(shí)間

3. 借助工具

①. 代碼模板（File Template）

我們創(chuàng)建一個(gè)視圖，控制器，或者一個(gè) Model，可能會(huì)有一些固定不變的函數(shù)、屬性需要被定義或者重寫(xiě)，使用 Xcode 可以創(chuàng)建代碼模板，在創(chuàng)建類(lèi)文件的時(shí)候一鍵生成這些代碼，提高效率。

②. 代碼片段（Code Snippet）

一般可重用的代碼，我們會(huì)封裝成類(lèi)或者函數(shù)，以便其他地方使用，但有一些代碼是不適合封裝的，例如：
a. 聲明一個(gè)屬性
b. 創(chuàng)建一個(gè)線程

像這類(lèi)的代碼，我會(huì)做成代碼片段，然后通過(guò) Xcode 的 Code Snippet 自動(dòng)補(bǔ)充功能來(lái)快速完成，一個(gè)代碼片段例子：

只要輸入 @OperateThread 就可以直接完成創(chuàng)建一個(gè)操作隊(duì)列的代碼，大幅度減少編碼時(shí)間。

③. 自動(dòng)注釋工具（VVDocumenter）

一個(gè)可以一鍵創(chuàng)建注釋模板的工具，減少寫(xiě)注釋所需的時(shí)間

4. 適當(dāng)添加注釋

如果像官方的 API 那樣，所有地方都添加注釋?zhuān)枪ぷ髁烤吞罅?，需要額外的開(kāi)發(fā)時(shí)間，如果只是針對(duì)一些語(yǔ)義不明、有歧義的代碼添加注釋?zhuān)炊鴷?huì)減少開(kāi)發(fā)時(shí)間。

例如一個(gè)屬性：

@property (nonatomic, assign) int64_t createTime; 

一看就知道是指創(chuàng)建時(shí)間，但它到底是不是時(shí)間戳？如果是時(shí)間戳，那單位是秒還是毫秒？如果還要打印數(shù)據(jù)以后才能下結(jié)論，就太耗時(shí)間了。

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

/// 創(chuàng)建時(shí)間（時(shí)間戳 秒） 
@property (nonatomic, assign) int64_t createTime; 

三、自測(cè)

1. 先檢查后自測(cè)

完成一個(gè)小功能以后，先檢查一下代碼，然后再開(kāi)始自測(cè)，因?yàn)榇a可以告訴你很多信息：
①. 是否有低級(jí)錯(cuò)誤
②. 是否有難以發(fā)現(xiàn)的漏洞
③. 流程是否存在問(wèn)題

如果你編碼完成以后立即自測(cè)，可能會(huì)進(jìn)入被動(dòng)狀態(tài)：
①. 這個(gè)界面顯示不對(duì)
②. 這個(gè)數(shù)據(jù)跟預(yù)期對(duì)不上
③. 有些不該出現(xiàn)的東西出現(xiàn)了

這時(shí)候再反過(guò)來(lái)去調(diào)試代碼，一步步修改，會(huì)很慢，因?yàn)槟憔幾g和操作都需要時(shí)間，而且有些條件不是很容易模擬，那種情況就更耗時(shí)間了

2. 自測(cè)點(diǎn)要全部過(guò)一遍

可能你會(huì)覺(jué)得這很煩，很浪費(fèi)程序員的時(shí)間，但自測(cè)過(guò)程發(fā)現(xiàn) bug 是最容易修復(fù)的，因?yàn)檫@時(shí)候代碼記憶最清晰，最容易找到問(wèn)題所在。

四、總結(jié)

先用文檔理清思路，然后開(kāi)始編碼，編碼完成以后要檢查代碼并自測(cè)。這就是我的編程習(xí)慣，一直沿用至今。

其實(shí)知道一個(gè)技巧，并不會(huì)提升效率，只有堅(jiān)持使用這個(gè)技巧，并形成習(xí)慣以后，才會(huì)真正地提高效率。