習(xí)慣會影響一個人做事的方式，也會直接影響效率。我經(jīng)常在項(xiàng)目完成后自我總結(jié)狐胎，有哪些做得好的在验，有哪些做得不好的？然后把一些好的流程記錄下來快骗，并且重新運(yùn)用回編程中。那些能夠堅持去做的流程，就變成了我的編程習(xí)慣唁影，這些良好的習(xí)慣就成就了我高效的編程效率!
一、輕文檔先行
什么叫輕文檔掂名？其實(shí)輕文檔指的是不需要按照標(biāo)準(zhǔn)的軟件工程知識來編寫需求分析据沈，架構(gòu)設(shè)計，模塊設(shè)計饺蔑，流程圖時序圖等文檔锌介，而是采用比較自由的方式，把你要做的事情膀钠，還有做事情的步驟描述清楚的文檔掏湾。這樣的文檔不需要限制格式，甚至你可以手寫在自己的筆記本上面肿嘲，只要自己能看得懂融击，在開發(fā)過程中能夠隨時查閱就可以了。
1. 為什么要寫文檔
剛開始工作的時候雳窟，總是一接到任務(wù)就馬上開始寫代碼尊浪，結(jié)果遇到了很多問題匣屡，例如：
①. 需求本身就存在問題，代碼寫到一半以后才發(fā)現(xiàn)
②. 部分需求沒有表達(dá)清楚拇涤，發(fā)現(xiàn)的時候才去溝通捣作，結(jié)果發(fā)現(xiàn)時間不夠，或者跟之前的代碼產(chǎn)生沖突
③. 代碼寫到一半時鹅士，發(fā)現(xiàn)自己思路不對或者不清晰了
最后很有可能導(dǎo)致項(xiàng)目延期券躁。
如果在開發(fā)前就把需求分解好，把問題溝通清楚掉盅，把要做的點(diǎn)一個個列下來也拜，就能大大地避免這些問題。
2. 文檔寫什么
①. 準(zhǔn)備工作
在開始之前需要準(zhǔn)備什么趾痘？例如做一個發(fā)送消息的界面慢哈，需要有以下的準(zhǔn)備：
a. 接口協(xié)議
b. 測試環(huán)境
c. 測試賬號
準(zhǔn)備工作提前做好，往往會加快效率永票。為什么要把這些內(nèi)容記錄下來卵贱，是為了在開發(fā)過程中可以快速檢索。如果等到開始開發(fā)以后再去查聊天記錄侣集，或者是找相關(guān)人員詢問键俱，那就慢了。
②. 羅列需要做的小功能點(diǎn)
例如做一個發(fā)送消息的界面肚吏，就有很多小功能點(diǎn)：
a. 發(fā)送界面
b. 發(fā)送的數(shù)據(jù)接口
c. 文本字?jǐn)?shù)限制
如果你仔細(xì)一想方妖，可能還會出現(xiàn)以下問題：
a. 是否需要登錄？如果未登錄罚攀，是否要引導(dǎo)登錄
b. 對于發(fā)送失敗的情況党觅，要如何處理？
c. 字?jǐn)?shù)超出限制時斋泄，如何交互杯瞻？
d. 用戶重復(fù)發(fā)相同的文本，是否要過濾炫掐？
e. 如何處理數(shù)據(jù)接口的錯誤碼魁莉？
當(dāng)你記錄下這些小功能，并且跟產(chǎn)品經(jīng)理溝通清楚以后募胃，你的開發(fā)周期已經(jīng)可以初步評估了旗唁，并且這時候也已經(jīng)弄清楚這個需求有多少小功能，需要怎么劃分模塊痹束，怎么構(gòu)建內(nèi)部流程检疫。
對于部分流程復(fù)雜的功能，可以畫一下流程圖輔助理解
③. 記錄這個需求的改動點(diǎn)
如果這是一個新需求祷嘶，并且跟以前的版本沒有任何關(guān)系屎媳，則可以忽略這部分
如果是這個需求會影響以前的代碼夺溢，則需要將改動部分記錄下來，因?yàn)轫?xiàng)目中的 bug 有很多是改出來的烛谊，列出改動點(diǎn)后會讓自己更清楚新功能帶來的影響风响，減少很多低級bug
例如新增一個發(fā)送圖片的功能，這個功能會影響聊天窗口的展示丹禀，會影響鍵盤状勤，這些改動點(diǎn)就要記錄下來。一來可以輔助思考有沒有漏掉的小功能點(diǎn)湃崩，二來在自測試的時候需要覆蓋聊天窗口的展示和鍵盤的切換荧降。
④. 羅列自測試內(nèi)容
編碼完成以后，一定要進(jìn)行自測試攒读，自測試越仔細(xì)，越能提前發(fā)現(xiàn) bug 并修復(fù)辛友。如果是測試人員發(fā)現(xiàn)了 bug 薄扁，然后再提交給你，你這時候再去解決废累，效率往往會比較低邓梅。
以發(fā)送消息為例，自測內(nèi)容也有很多：
a. 正常發(fā)送消息
b. 未登錄時點(diǎn)擊發(fā)送
c. 字?jǐn)?shù)超出限制
d. 沒有網(wǎng)絡(luò)時點(diǎn)發(fā)送
e. 網(wǎng)絡(luò)很差時不斷點(diǎn)發(fā)送
等等.......
二邑滨、開始編碼
1. 是重寫還是保持不變
每做一個新需求日缨，都有可能會面臨這樣的問題：
①. 以前的模塊寫得太爛了，很想重新寫
②. 差不多的需求掖看，以前用了這樣的方式實(shí)現(xiàn)匣距，這次想換一種方式實(shí)現(xiàn)
會考慮以上的問題，證明你是一個想要不斷進(jìn)步的人哎壳，但是毅待，在做決定之前最好先考慮以下因素：
①. 重寫模塊，很可能牽一發(fā)而動全身归榕，要想清楚改動可能帶來的影響尸红，以及解決這些問題需要的時間
②. 使用新方案實(shí)現(xiàn)需求，新的方案是否已經(jīng)經(jīng)過仔細(xì)的驗(yàn)證刹泄，如果沒有外里，它可能會帶來新問題
其實(shí)保持不變也有一些優(yōu)勢：
①. 可以比之前做得更快，因?yàn)槟闶煜ち?br>
②. 不會出現(xiàn)新問題
考慮好以后特石，是重寫還是保持現(xiàn)狀盅蝗，基本已經(jīng)有答案了
不過保持現(xiàn)狀并不意味著是放棄追求，你可以用業(yè)余的時間來證明你的方案县匠，當(dāng)它已經(jīng)穩(wěn)定了风科，可行了撒轮，那你隨時都可以重寫了。
2. 實(shí)現(xiàn)需求贼穆，Demo 先行
用 Demo 來實(shí)現(xiàn)一個需求是最快的题山，因?yàn)樗\(yùn)行快，可以隨意修改故痊，而且代碼量少顶瞳，如果實(shí)現(xiàn)過程出現(xiàn)問題，很容易就可以定位到原因愕秫。
先建立一個 Demo慨菱，然后把需要的資源移植過來，把功能實(shí)現(xiàn)以后戴甩，再移植到項(xiàng)目中符喝，這樣可以節(jié)省不少開發(fā)時間
3. 借助工具
①. 代碼模板（File Template）
我們創(chuàng)建一個視圖，控制器甜孤，或者一個 Model协饲，可能會有一些固定不變的函數(shù)、屬性需要被定義或者重寫缴川，使用 Xcode 可以創(chuàng)建代碼模板茉稠，在創(chuàng)建類文件的時候一鍵生成這些代碼，提高效率把夸。
②. 代碼片段（Code Snippet）
一般可重用的代碼而线，我們會封裝成類或者函數(shù)，以便其他地方使用恋日，但有一些代碼是不適合封裝的膀篮，例如：
a. 聲明一個屬性
b. 創(chuàng)建一個線程
像這類的代碼，我會做成代碼片段谚鄙，然后通過 Xcode 的 Code Snippet 自動補(bǔ)充功能來快速完成各拷，一個代碼片段例子：
只要輸入 @OperateThread 就可以直接完成創(chuàng)建一個操作隊(duì)列的代碼，大幅度減少編碼時間闷营。
③. 自動注釋工具（VVDocumenter）
一個可以一鍵創(chuàng)建注釋模板的工具烤黍，減少寫注釋所需的時間
4. 適當(dāng)添加注釋
如果像官方的 API 那樣，所有地方都添加注釋傻盟，那工作量就太大了速蕊，需要額外的開發(fā)時間，如果只是針對一些語義不明娘赴、有歧義的代碼添加注釋规哲，反而會減少開發(fā)時間。
例如一個屬性：
@property (nonatomic, assign) int64_t createTime;
一看就知道是指創(chuàng)建時間诽表，但它到底是不是時間戳唉锌？如果是時間戳隅肥，那單位是秒還是毫秒？如果還要打印數(shù)據(jù)以后才能下結(jié)論袄简，就太耗時間了腥放。
加上注釋以后，它就一目了然了
/// 創(chuàng)建時間（時間戳 秒）
@property (nonatomic, assign) int64_t createTime;
三绿语、自測
1. 先檢查后自測
完成一個小功能以后秃症，先檢查一下代碼，然后再開始自測吕粹，因?yàn)榇a可以告訴你很多信息：
①. 是否有低級錯誤
②. 是否有難以發(fā)現(xiàn)的漏洞
③. 流程是否存在問題
如果你編碼完成以后立即自測种柑，可能會進(jìn)入被動狀態(tài)：
①. 這個界面顯示不對
②. 這個數(shù)據(jù)跟預(yù)期對不上
③. 有些不該出現(xiàn)的東西出現(xiàn)了
這時候再反過來去調(diào)試代碼，一步步修改匹耕，會很慢聚请，因?yàn)槟憔幾g和操作都需要時間，而且有些條件不是很容易模擬泌神，那種情況就更耗時間了
2. 自測點(diǎn)要全部過一遍
可能你會覺得這很煩良漱，很浪費(fèi)程序員的時間，但自測過程發(fā)現(xiàn) bug 是最容易修復(fù)的欢际，因?yàn)檫@時候代碼記憶最清晰，最容易找到問題所在矾兜。
四损趋、總結(jié)
先用文檔理清思路，然后開始編碼椅寺，編碼完成以后要檢查代碼并自測浑槽。這就是我的編程習(xí)慣，一直沿用至今返帕。
其實(shí)知道一個技巧桐玻，并不會提升效率，只有堅持使用這個技巧荆萤，并形成習(xí)慣以后镊靴，才會真正地提高效率。
