我的iOS高效程式設計祕訣-堅持程式設計習慣

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

一、輕文件先行

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

1. 為什麼要寫文件

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

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

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

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

最後很有可能導致專案延期。

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

2. 文件寫什麼

①. 準備工作

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

a. 介面協議

b. 測試環境

c. 測試賬號

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

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

例如做一個傳送訊息的介面，就有很多小功能點：

a. 傳送介面

b. 傳送的資料介面

c. 文字字數限制

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

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

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

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

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

e. 如何處理資料介面的錯誤碼？

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

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

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

如果這是一個新需求，並且跟以前的版本沒有任何關係，則可以忽略這部分如果是這個需求會影響以前的程式碼，則需要將改動部分記錄下來，因為專案中的 bug 有很多是改出來的，列出改動點後會讓自己更清楚新功能帶來的影響，減少很多低階bug

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

④. 羅列自測試內容

編碼完成以後，一定要進行自測試，自測試越仔細，越能提前發現 bug 並修復。如果是測試人員發現了 bug ，然後再提交給你，你這時候再去解決，效率往往會比較低。

以傳送訊息為例，自測內容也有很多：

a. 正常傳送訊息

b. 未登入時點選傳送

c. 字數超出限制

d. 沒有網路時點傳送

e. 網路很差時不斷點傳送

等等.......

二、開始編碼

1. 是重寫還是保持不變

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

①. 以前的模組寫得太爛了，很想重新寫

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

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

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

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

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

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

②. 不會出現新問題

考慮好以後，是重寫還是保持現狀，基本已經有答案了不過保持現狀並不意味著是放棄追求，你可以用業餘的時間來證明你的方案，當它已經穩定了，可行了，那你隨時都可以重寫了。

原文連結：http://toutiao.com/i5382334337/?tt_from=mobile_qq&utm_campaign=client_share&app=news_article&utm_source=mobile_qq&iid=2940446160&utm_medium=toutiao_ios

github主頁：https://github.com/chenyufeng1991  。歡迎大家訪問！