今天來講講程序員日常開發的八榮八恥。

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

很多 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. 以總結思考為榮，以渾水摸魚為恥。

我們要以總結思考為榮。

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

我們要以渾水摸魚為恥。

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

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部