習慣會影響乙個人做事的方式，也會直接影響效率。我經常在專案完成後自我總結，有哪些做得好的，有哪些做得不好的？然後把一些好的流程記錄下來，並且重新運用回程式設計中。那些能夠堅持去做的流程，就變成了我的程式設計習慣，這些良好的習慣就成就了我高效的程式設計效率!
一、輕文件先行
什麼叫輕文件？其實輕文件指的是不需要按照標準的軟體工程知識來編寫需求分析，架構設計，模組設計，流程圖時序圖等文件，而是採用比較自由的方式，把你要做的事情，還有做事情的步驟描述清楚的文件。這樣的文件不需要限制格式，甚至你可以手寫在自己的筆記本上面，只要自己能看得懂，在開發過程中能夠隨時查閱就可以了。
1. 為什麼要寫文件
剛開始工作的時候，總是一接到任務就馬上開始寫**，結果遇到了很多問題，例如：
①. 需求本身就存在問題，**寫到一半以後才發現
②. 部分需求沒有表達清楚，發現的時候才去溝通，結果發現時間不夠，或者跟之前的**產生衝突
③. **寫到一半時，發現自己思路不對或者不清晰了
最後很有可能導致專案延期。
如果在開發前就把需求分解好，把問題溝通清楚，把要做的點乙個個列下來，就能大大地避免這些問題。
2. 文件寫什麼
①. 準備工作
在開始之前需要準備什麼？例如做乙個傳送訊息的介面，需要有以下的準備：
a. 介面協議
b. 測試環境
c. 測試賬號
準備工作提前做好，往往會加快效率。為什麼要把這些內容記錄下來，是為了在開發過程中可以快速檢索。如果等到開始開發以後再去查聊天記錄，或者是找相關人員詢問，那就慢了。
②. 羅列需要做的小功能點
例如做乙個傳送訊息的介面，就有很多小功能點：
a. 傳送介面
b. 傳送的資料介面
c. 文字字數限制
如果你仔細一想，可能還會出現以下問題：
a. 是否需要登入？如果未登入，是否要引導登入
b. 對於傳送失敗的情況，要如何處理？
c. 字數超出限制時，如何互動？
d. 使用者重**相同的文字，是否要過濾？
e. 如何處理資料介面的錯誤碼？
當你記錄下這些小功能，並且跟產品經理溝通清楚以後，你的開發周期已經可以初步評估了，並且這時候也已經弄清楚這個需求有多少小功能，需要怎麼劃分模組，怎麼構建內部流程。
對於部分流程複雜的功能，可以畫一下流程圖輔助理解
③. 記錄這個需求的改動點
如果這是乙個新需求，並且跟以前的版本沒有任何關係，則可以忽略這部分
如果是這個需求會影響以前的**，則需要將改動部分記錄下來，因為專案中的 bug 有很多是改出來的，列出改動點後會讓自己更清楚新功能帶來的影響，減少很多低階bug
例如新增乙個傳送的功能，這個功能會影響聊天視窗的展示，會影響鍵盤，這些改動點就要記錄下來。一來可以輔助思考有沒有漏掉的小功能點，二來在自測試的時候需要覆蓋聊天視窗的展示和鍵盤的切換。
④. 羅列自測試內容
編碼完成以後，一定要進行自測試，自測試越仔細，越能提前發現 bug 並修復。如果是測試人員發現了 bug ，然後再提交給你，你這時候再去解決，效率往往會比較低。
以傳送訊息為例，自測內容也有很多：
a. 正常傳送訊息
b. 未登入時點選傳送
c. 字數超出限制
d. 沒有網路時點傳送
e. 網路很差時不斷點傳送
等等.......
二、開始編碼
1. 是重寫還是保持不變
每做乙個新需求，都有可能會面臨這樣的問題：
①. 以前的模組寫得太爛了，很想重新寫
②. 差不多的需求，以前用了這樣的方式實現，這次想換一種方式實現
會考慮以上的問題，證明你是乙個想要不斷進步的人，但是，在做決定之前最好先考慮以下因素：
①. 重寫模組，很可能牽一髮而動全身，要想清楚改動可能帶來的影響，以及解決這些問題需要的時間
②. 使用新方案實現需求，新的方案是否已經經過仔細的驗證，如果沒有，它可能會帶來新問題
其實保持不變也有一些優勢：
①. 可以比之前做得更快，因為你熟悉了
②. 不會出現新問題
考慮好以後，是重寫還是保持現狀，基本已經有答案了
不過保持現狀並不意味著是放棄追求，你可以用業餘的時間來證明你的方案，當它已經穩定了，可行了，那你隨時都可以重寫了。
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;
一看就知道是指建立時間，但它到底是不是時間戳？如果是時間戳，那單位是秒還是毫秒？如果還要列印資料以後才能下結論，就太耗時間了。
加上注釋以後，它就一目了然了
/// 建立時間（時間戳 秒）
@property (nonatomic, assign) int64_t createtime;
三、自測
1. 先檢查後自測
完成乙個小功能以後，先檢查一下**，然後再開始自測，因為**可以告訴你很多資訊：
①. 是否有低階錯誤
②. 是否有難以發現的漏洞
③. 流程是否存在問題
如果你編碼完成以後立即自測，可能會進入被動狀態：
①. 這個介面顯示不對
②. 這個資料跟預期對不上
③. 有些不該出現的東西出現了
這時候再反過來去除錯**，一步步修改，會很慢，因為你編譯和操作都需要時間，而且有些條件不是很容易模擬，那種情況就更耗時間了
2. 自測點要全部過一遍
可能你會覺得這很煩，很浪費程式設計師的時間，但自測過程發現 bug 是最容易修復的，因為這時候**記憶最清晰，最容易找到問題所在。
四、總結
先用文件理清思路，然後開始編碼，編碼完成以後要檢查**並自測。這就是我的程式設計習慣，一直沿用至今。
其實知道乙個技巧，並不會提公升效率，只有堅持使用這個技巧，並形成習慣以後，才會真正地提高效率。
我的高效程式設計秘訣
1 提高搜尋技巧來成為一名高效的程式設計師 如果不借助搜尋技術 網路及集體智慧型，現代化高效程式設計是難以想象的。因此，搜尋技巧對高效程式設計師變得愈發重要。2 專注程式設計，盡量避免被外界所打擾 在編寫 的過程中，專注只做 一件事 關閉email 關閉聊天工具，關閉 盡量不要有 分心的事 這會讓你...
高效程式設計的秘訣
昨天我做了一些事情使我的程式設計效率提高了一倍。簡單，容易，但使我的生活發生了巨大的變化。你們中可能有些人已經知道我是怎麼做的。對於其他的人，這聽起來有些瘋狂。我不持續工作。或者，我把定時器設定成50分鐘，在此期間我只幹一件事 沒email，沒聊天工具，沒遊戲，沒分心的事。50分鐘後，我去散步。它使...
程式設計巨星的唯一秘訣
別以為是那些軟體開發定律，別以為是開發出那些特殊用途的軟體，別以為是軟體設計技術本身。只有一條真理決定了乙個軟體程式設計師的成功還是失敗。由於堅持這個真理，乙個資深的程式設計師能在一天的時間裡學會一門新的程式語言，而由於不堅持這條真理，乙個初級的程式設計師用十年時間也只能掙到乙份餬口的錢 永遠是來實...