最近晚間的加班暫時暫停了，大概已經整整一個月每天焦頭爛額的寫著業(yè)務代碼，被各種邏輯搞的整個人都不大好了，好在是寫的差不多了。

每當寫了很多業(yè)務代碼之后，我都會停下來反思一個問題，你的代碼寫的干凈么，有需要重構的地方么。而這一次，因為一些臨時性的需求變更，我自認為我寫了一部分臟代碼，這部分代碼恰恰是bug的高發(fā)地段，而且也可能會帶來后期維護的困難。那么如何來重構這部分代碼呢？

在我寫下這部分臟代碼之前，我自認為也是用了一些能夠用上的設計模式，但是隨著臨時性的需求變更不斷增加，有時候貪圖省事直接在原有代碼的基礎上修改了事，很明顯這違反了開放閉合原則。

回到正題上來，回顧《clean code》這本書，正是幫助自己在反思的同時做好知識的回顧梳理，并且能夠在重構中把學到的知識學以致用。雖然現在我還沒有全部看完，但是也是可以從已經完成閱讀的部分總結一點心得。

第一次看這本書是在幾年前，可以說這本書對我編寫代碼的風格形成了很深的影響，而初讀此書時也有種醍醐灌頂的感覺，哦，原來代碼還可以這么寫。

從命名談起

當我們在寫代碼時，面臨的第一個問題大概就是命名，你想創(chuàng)建一個類，需要命名；寫函數，需要命名；甚至初始化一個變量，也需要給變量命名。但是一個好的命名和差的命名，可是有著天差地別的區(qū)別的。好的命名，讓人掃一眼，就大概知道這個函數的作用是什么，甚至連大體會輸出什么都知道，提升了代碼的可讀性。而差的命名會極大降低代碼的可讀性，讓下一個閱讀你代碼的人，花費大量的時間。舉個栗子：

privite func syncDataWhenConnect() {
    //doSomething
}

privite func syncData() {
    //doSomething
}

上下兩個函數，很明顯你看完第一個，會更明白這個函數的目的是什么，所以建議在書寫函數的時候，盡量的使用動詞，來準確的秒數函數的目的。

而給類命名則正好相反，再舉個栗子：

AddressManager.php
MacAddress.php

上下兩個類名，這里我寫的有點爭議，其實在不同的語境里兩個似乎都可以完成可讀性的使命，但是假設一個程序，有存儲用戶地址的類，也有外接設備mac地址的類，哪個更易懂？所以類名的命名，盡量使用名詞，并且要求簡單直接，是什么就是什么，盡量少用動詞，動詞的活，讓我們所在的文件夾，讓命名空間們去闡述吧。

雖然我上面反復提及了名字簡短，但是只有很少比例的命名能又短又明確的闡述命名意義，所以如果是為了增加可讀性，長命名也不是完全不可取，雖然很多人黑Objective-C命名是又臭又長，但是這種命名帶來的便利就是你掃一眼便知道函數要完成的目的，以及需要的參數。長短之別，自己把握吧。

從簡短代碼談起

編程界的那幫金字塔尖的大牛們一致認為，函數是越短越好，如果實在控制不住，請不要超過20行，如果不小心超過了，那么你可以考慮拆分你的函數了。

其實每次我去反思這點的時候，我覺得可有意思了，講道理的說，我有可能做不到，為什么呢，因為水平不夠，對語言的理解不夠透徹，有很多更深層的語言特性，還不能熟練應用。所以只能在能夠考慮到的范圍內，盡量縮短自己的函數長度，向大牛們看齊。

這次的手環(huán)模塊，因為有很多藍牙的連接狀態(tài)判斷，寫了很多Swich ifelse等判斷，而ifelse因為業(yè)務邏輯復雜，還在初次編寫的時候夾雜了很多嵌套，所以需要重構的地方還是很多的。

我們寫代碼，開發(fā)時間算20%，那么剩下的80%就是維護時間，什么樣的函數易于修改，當然是短的函數，每次改動都能做到心中有數。

而提到了維護，那么測試又不能不提，很可惜，我還沒有看全測試，平時的工作中因為很多是移動端的編碼，view層占的比重很大，有時候疏于測試，好好理解，好好實踐，再來寫下一篇心得吧。