程式設計師技術開發手冊（程式設計師日常開發的八榮八恥）

2023-08-07 03:02:59

今天來講講程式設計師日常開發的八榮八恥。

以接口兼容為榮，怎麼理解呢？

很多 bug 都是因為修改了對外舊接口，但是卻不做兼容導致的。關鍵這個問題多數是比較嚴重的，可能直接導致系統發版失敗的。新手程式設計師很容易犯這個錯誤。所以我們修改老接口的時候，一般要做好兼容。

如果需求是在原來接口上修改，尤其這個接口是對外提供服務的話，一定要考慮接口兼容。舉個例子吧，比如dubbo接口，原本是只接收A，B參數，現在加了一個參數C，就可以考慮這樣處理：

//老接口void oldService(A,B){ //兼容新接口，傳個null代替C newService(A,B,null);}//新接口，暫時不能刪掉老接口，需要做兼容。void newService(A,B,C){ ...}

我們還要以接口裸奔為恥。為了保證接口報文的安全性，拒絕接口報文裸奔。因此，我們可以使用 https 協議，還建議對接口加籤驗籤處理，數據加密等。

接口籤名很簡單，就是把接口請求相關信息（請求報文，包括請求時間戳、版本號、appid 等），客戶端私鑰加籤，然後服務端用公鑰驗籤，驗證通過才認為是合法的、沒有被中間人篡改過的請求。

我們的業務邏輯代碼需要日誌保駕護航。比如：你實現轉帳業務，轉個幾百萬，然後轉失敗了，接著客戶投訴，然後你還沒有列印到日誌，想想那種水深火熱的困境下，你卻毫無辦法。。。

因此大家要打好日誌，比如日誌級別使用恰當、日誌格式、在哪些地方打日誌、參數列印哪個等等。

請牢記，不能亂打日誌，要以規範日誌為榮，亂打日誌為恥。

修改完代碼，要自測一下，這個是每個程序必備的素養，即使你只是修改了一個變量或者一個欄位。

要杜絕過度自信，尤其不要抱有這種僥倖心理：我只是改了一個變量或者我只改了一行配置的代碼，不用自測了，怎麼可能有問題。

因此，我們要以代碼自測為榮，以過度自信為恥。

我們要以參數校驗為榮。

參數校驗是每個程式設計師必備的基本素養。方法處理，必須先校驗參數。比如入參是否允許為空，入參長度是否符合預期長度。

比如你的資料庫表欄位設置為varchar(16)，對方傳了一個32位的字符串過來，如果你不校驗參數，插入資料庫直接異常了。

我們要以運行時異常為恥。

比如沒有做好一些非空校驗、數組邊界校驗等等，導致的空指針異常、數組邊界異常，尤其這些運行時異常還發生在生產環境的話，在有經驗的程式設計師看來，這些錯誤行為會顯得特別低級。

5. 以設計模式為榮，以代碼重複為恥

日常工作中，我們要以設計模式為榮。

比如策略模式、工廠模式、模板方法模式、觀察者模式、單例模式、責任鏈模式等等，都是很常用的。在恰當的業務場景，我們還是把設計模式用上吧。設計模式可以讓我們的代碼更優雅、更具有擴展性。但是切記，不要過度設計，不要硬套設計模式。

我們還要以重複代碼為恥。

重複代碼，相信每個程式設計師都討厭的，尤其有時候開發工具還會給提示出來。我們可以抽取公共方法、抽取公用變量、擴展繼承類等方式去消除重複代碼。

6. 以優化代碼為榮，以複製粘貼為恥

日常開發中，很多程式設計師在實現某個功能時，如果看到老代碼有類似的功能，他們很喜歡複製粘貼過來，這樣很容易產生重複代碼。

一般建議加自己的思考，怎麼優化這部分代碼，怎麼抽取公用方法，用什麼設計模式等等。

個人覺得，優化代碼的過程，可以讓自己取得更大的進步。

7. 以定義常量為榮，以魔法數字為恥

大家平時工作中，是不是經常看到魔法數字。魔法數字（Magic Number）是指擁有特殊意義、卻又不能明確表現出這種意義的數字。程序裡面存在魔法數字，易讀性很差，且非常難以維護。

如下：

if(type==1){ System.out.println("第一個");}else if(type==2){ System.out.println("第二個");}else{ System.out.println("其他");}

代碼中的1、2就表示魔法數字，我們可以用常量取代魔法數，或者定義枚舉去代替魔法數字。

8. 以總結思考為榮，以渾水摸魚為恥。

我們要以總結思考為榮。

比如平常看完技術文章，可以總結思考一下，或者做做筆記，或者放到收藏夾，茶餘飯後再看看。再比如日常工作中，看到一段不錯的代碼，也可以思考一下亮點在哪裡，如果換成自己來寫的話，怎麼寫出更好的代碼。反正就是要多總結，多思考，多複習，溫故而知新。

我們要以渾水摸魚為恥。

比如工作中，一些小夥伴喜歡渾水摸魚，當一天和尚敲一天鐘，代碼多是複製粘貼，做完需求就摸魚。實際上這個不可取的。

我們要在工作中成長，通過認真工作，使自己學到更多，將來換工作也可以拿到更高的薪水，加油吧！

,