程序員你為什麼這麼累續：編碼習慣-函數編寫建議

之前系列文章裡面完整的代碼已經上github，地址在文章最後

傻瓜都能寫出計算機可以讀懂的代碼，只有優秀的程序員才能寫出人能讀懂的代碼！

在我看來，編寫簡單的函數是一件簡單又困難的事情。簡單是因為這沒有什麼技術難點，困難是因為這是一種思維習慣，很難養成，不寫個幾年代碼，很難寫出像樣的代碼。

大部分的程序員寫的都是CRUD、一些業務邏輯的代碼，誰實現不了？對於我來說，如果業務邏輯的代碼評審，需要人來講每一個代碼做了什麼，這樣的代碼就是不合格的，合格的代碼寫出來應該像人說話那麼簡單有條理，基本上是業務怎麼樣描述需求，寫出來的代碼就是怎麼樣的。編寫出非開發人員都能看懂的代碼，才是我們追求的目標。不要以寫出了一些非常複雜的代碼而沾沾自喜。好的代碼應該是看起來平淡無奇覺得很簡單自然，而不是看得人云里霧裡的覺得很高深很有技術含量。

如果你做好了我前面幾篇文章的要求，編寫簡單的函數就容易的多，如果你覺得我之前說的去掉local，去掉用戶參數這些沒有什麼必要是小題大做，那麼我覺得你寫不出簡單的函數。從個人經驗來說，函數編寫的建議有以下幾點：

1 不要出現和業務無關的參數

參考我之前的帖子，我的編碼習慣 - 參數校驗和國際化規範，函數參數裡面不要出現local，messagesource，request，Response這些參數，第一非常干擾閱讀，一堆無關的參數把業務代碼都遮掩住了，第二導致你的函數不好測試，如你要構建一個request參數來測試，還是有一定難度的。

2 避免使用Map，Json這些複雜的數據對象作為參數和結果

這類參數看著靈活方便，但是靈活的同義詞（代價）就是複雜，最終的結果是可變數多bug多質量差。就好比刻板的同義詞就是嚴謹，最終的結果就是高質量。千萬不要為了偷懶少幾行代碼，就到處把map，json傳來傳去。其實定義一個bean也相當簡單，加上lombok之後，代碼量也沒有幾行，但代碼可讀性就不可同日而語了。做過開發的人應該很容易體會，你如果接手一個項目，到處的輸入輸出都是map的話，request從頭傳到尾，看到這樣的代碼你會哭的，我相信你會馬上崩潰很快離職的。

還有人說用bean的話後面加欄位改起來麻煩，你用map還不是一樣要加一個key，不是更加麻煩嗎？說到底就是懶！

如果一個項目的所有代碼都如下面這樣，我是會崩潰的！

3 有明確的輸入輸出和方法名

盡量有清晰的輸入輸出參數，使人一看就知道函數做了啥。舉例：

上面的函數，看函數定義你只知道更新了用戶對象，但你不知道更新了用戶的什麼信息。建議寫成下面這樣：

你就算不看方法名，只看參數就能知道這個函數只更新了nickname一個欄位。多好啊！

這點只可意會不可言傳。

4 把可能變化的地方封裝成函數

編寫函數的總體指導思想是抽象和封裝，你要把代碼的邏輯抽象出來封裝成為一個函數，以應對將來可能的變化。以後代碼邏輯有變更的時候，單獨修改和測試這個函數即可。

這一點相當重要，否則你會覺得怎麼需求老變？改代碼煩死了。

如何識別可能變的地方，多思考一下就知道了，工作久了就知道了。比如，開發初期，業務說只有管理員才可以刪除某個對象，你就應該考慮到後面可能除了管理員，其他角色也可能可以刪除，或者說對象的創建者也可以刪除，這就是將來潛在的變化，你寫代碼的時候就要埋下伏筆，把是否能刪除做成一個函數。後面需求變更的時候，你就只需要改一個函數。

舉例，刪除配置項的邏輯，判斷一下只有是自己創建的配置項才可以刪除，一開始代碼是這樣的：

這裡我會識別一下，是否可以刪除這個地方就有可能會變化，很有可能以後管理員就可以刪除任何人的，那麼這裡就抽成一個函數：

這就是簡單的抽象和封裝的藝術。看這些代碼，參數多麼的簡單，很容易理解吧。

這一點非常重要，做好了這點，大部分的小的需求變更對程序員的傷害就會降到最低了！畢竟需求變更大部分都是這些小邏輯的變更。

5 編寫能測試的函數

程序猿不招妹子們喜愛的根本原因在於追求了錯誤的目標：更短、更小、更快。

這個非常重要，當然很難實現，很多人做技術之前都覺得代碼都會做單元測試，實際上和業務相關的代碼單元測試是很難做的。

我覺得要編寫能測試的函數主要有以下幾點：

第一不要出現亂七八糟的參數，如參數裡面有request，response就不好測試，

第二你要把函數寫小一點。如果一個功能你service代碼只有一個函數，那麼你想做單元測試是很難做到的。我的習慣是盡量寫小一點，力求每一個函數都可以單獨測試（用junit測試或者main函數測試都沒有關係）。這樣會節約大量的時間，尤其是代碼頻繁改動的時候。我們應用重啟一次需要15分鐘以上。新手可以寫一個功能可能需要重啟10幾次，我可能只需要重啟幾次，節約的時候的很可觀的。

第三你要有單獨測試每一個函數的習慣。不要一上來就測試整個功能，應該一行一行代碼、一個一個函數測試，有了這個習慣，自然就會寫出能測試的小函數。所以說，只有喜歡編碼的人才能寫出好代碼。

如我的編碼習慣 - 配置規範這篇文章了，我的配置相關代碼，都是可以單獨測試的，所以配置項的改動不需要測試業務功能，應用都不需要重啟。

總結

一句話總結，使用簡單參數，不要出現和業務無關的參數，把可能變化的地方都寫出獨立的函數，力求每一個函數都可以單獨測試。

GITHUB地址

所有的代碼細節都在已經上了github了，地址 xwjie/PLMCodeTemplate**，歡迎加星。有問題歡迎提出。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！