請注意寫程式碼的習慣與態度(Java)
阿新 • • 發佈：2019-01-07
我相信很多人都有看別人程式碼的經歷，我也相信很多人看過之後都在心裡吐槽：這是哪個SB寫的程式碼，還沒有來得及看業務邏輯就因到處充斥著各種程式碼的“壞味道”，讓你根本沒信心能看懂這些程式碼，其導致的結果就是推倒重來。那麼，不禁要問是什麼原因導致了這種程式碼讓人抓狂，無法理解；原因無非要麼是技術水平的問題，要麼是寫程式碼的習慣與態度問題。由於大部分的專案業務邏輯並不會太複雜，所以在我看來，最大的原因來自寫程式碼的習慣與態度。我也經常需要看以前別人寫過的程式碼，特別是非全新專案，需求一改，就需要更新程式碼。當我看到這些程式碼是，感覺非常凌亂，有種無從看起的感覺。因為有太多的程式碼“壞味道”，所以本人想來總結一下程式碼的各種“壞味道”：
1.類名，方法名，變數名不易理解
隨著工作時間的增長，我越來越覺得一個好的名稱是多麼的重要。一個好名稱最重要的衡量標準就是易於理解，一看名稱就知道這個類，方法大概的功能是什麼，變數代表的是什麼，可以給程式碼的閱讀與理解寫帶來極大便利。對於名稱，儘量取得準確，有意義，易於理解，如果不知道用什麼單詞，可以用詞典查一下，請不要吝嗇這取名字的時間。類名和變數一般是名詞，而方法名一般是動詞開頭，寧願名稱長一些而準確也不要隨意縮寫，因為那個名字很有可能只有當時的作者才認識。2、類，方法中包含過多程式碼
當一個類中有幾千行，一個方法有幾百行程式碼，你還看得下去嗎？估計又想罵人了。這種情況絕大部分都是不正常的象徵，除非特例。造成這種現象最主要的原因就是面向物件設計思想不過關，依舊停留在面向過程當中，導致類和方法包含了過多行為。帶來的後果是程式碼可讀性差，複用率低，擴充套件困難，這種程式碼的可維護性幾乎是零。改進方法是按照面向物件的思想，將類中的行為分散到不同的類中，儘可能做到一個類擔負專有職責，多個類共同協作完成同等工作；對於方法，應該根據功能點抽取成多個方法，提高程式碼複用率。3、缺少必要空格
有些人寫的程式碼幾乎就沒有空格，顯得非常擁擠，不利於閱讀。應該在變數與等於號之間、變數名稱與逗號之間等加上空格；雖然這是個很小的細節，但是有句話說得好：勿以惡小而為之。4、dao、controller包含過多業務邏輯
大家如果是做web開發的話，肯定都是分層開發的。各個層的職則劃分我想大家也很清楚，但我卻看到有些人把業務邏輯都寫到dao，controller中，嚴重與各層職則相悖。正確的做法應該是將業務邏輯放在service層，即使是service層也要根據業務需求，適當的將職責劃分到不同的方法或類中，切不可將程式碼千篇一律的堆在一個方法中。5、if語句太多
大家肯定看過在一個方法中有很多個連續的if else語句，如果說每個判斷中的邏輯非常簡單，比如工廠類中根據某資料生產不同的物件，僅此而已，這種情況是正常的。可怕的是每個判斷中都有一大串程式碼，造成這種情況的原因一般都是不同場景下有著不同的邏輯，卻沒有對這些邏輯抽象和封裝，最後以過程式程式碼書寫在一個方法中。這也會直接造成方法程式碼過長，複用率低，擴充套件性差。像這種情況基本上都可以通過策略模式或狀態模式來抽象這些場景，將這些不同場景相關邏輯封裝到策略或狀態物件中，這樣既可以提高擴充套件性，又可以簡化客戶端呼叫。6、標記變數濫用
標記變數是指某變數取不同值時有著不同業務邏輯。比如，有個 type欄位，值為1時代表謀型別，值為2時代表另外一種型別，以此類推…。寫程式碼時應該儘量避免這種情況，因為標記變數各種取值的意義只有你自己知曉，對別人來說很難理解，特別是不同取值取連一個有意義的名稱都沒有。而且標記變數很容易造成if else語句過多的情況。解決辦法是：
第一種：把不同取值定義成常量，並取一個有意義的名字，最好讓別人一看就知道這個值代表的意義是什麼；對這些取值進行if判斷時，
將判斷條件抽取成一個boolean值方法，併為這個方法取一個有意義的名字，使程式碼更易理解，這裡也再次說明取一個好名稱的重要作用。
第二種：將不同取值轉化成列舉，因為這種情況下不同取值的數量是有限的，確定的，很符合列舉的使用場景。
更為重要的是列舉中還可以定義方法，這樣就可以將一些與特定取值的邏輯封裝在不同的列舉元素中，這是常量所做不到的。
第三種：根據標記變數的不同取值封裝到不同的策略或狀態物件中，這樣擴充套件性好，當多出一個新的取值時，只需要新增一個策略或狀態類即可。
7、缺少必要註釋
我覺得大部分開發人員寫註釋還是比較少的，一是沒有養成寫註釋的習慣；二是嫌麻煩，覺得註釋沒什麼用；還有就是時間因素，畢竟專案中時間是有限的。我的觀點是：如果時間允許，儘量都寫註釋，特別是業務邏輯比較複雜的方法。有人可能會說，不用寫也可以，程式碼是我自己寫的，我都看得懂，能理解。當時是能理解，但是十天半個月之後就未必了，況且程式碼不僅是給自己看得，同時也是給別人看的。一個方法，別人看註釋十秒鐘就看懂了，沒有註釋可能要花十分鐘，這就是註釋的作用。一般人都不是軟體大師，寫的程式碼並不是都那麼優秀，而註釋能在一定程度上彌補我們程式碼的不足。而且大師寫出來的程式碼都有註釋，何況我們呢。8、類中包含測試main方法
造成類中有測試main方法的原因是沒有寫單元測試，而經常又有測試的需要，為了圖一時方便直接將測試程式碼寫在了類中，測試完了後又沒有刪除main方法。應該將測試放至單元測試中，條件允許的話儘可能多寫單元測試，這樣可以排除掉很多潛在異常。9、方法中包含過多的引數
如果一個方法引數太多會給客戶端呼叫帶來困難，客戶端最喜歡的方法是一個引數都沒有。不過所有方法都沒有引數這是不可能的，但我們可以把方法引數個數儘可能減少。比如寫多個過載方法，給一些引數賦預設值，以減少引數個數，過載方法最終都呼叫全引數方法。再如將多個引數封裝成一個引數物件。個人認為，當方法引數超過三個就應該動動“手術”了。10、包含e.printTrace語句
這條語句經常看見，如果程式是在本地執行，異常是有輸出的。但是程式釋出後執行在伺服器上時就不會有任何輸出。這條語句出現的原因，要麼是開發是貪方便，要麼是不知道使用log4j或其他日誌記錄工具記錄日誌(概率不大)。這會造成程式執行在伺服器上缺少日誌問題，而很多時候日誌是排查問題的首選依據，所以，請將該語句換成logger.xxx11、包含過多字面常量
現象：程式中存在很多字面常量(區域性變數)，比如：1、2、3…，字串常量等危害：給常量值修改帶來很大麻煩，尋找散落在程式各個角落是一件費時費力的體力勞動，還要擔心某些常量還未被更改；而常量值修改是再正常不過的事。
解決方法：將字面常量定義為public static final類常量，引用常量時直接引用這些靜態類常量。
12、使用了sun子孫包中的類
現象：使用了jdk中sun子孫包的類，如：BASE64Encoder危害：jdk中，java子孫包中的類是公開發布的，高版本jdk api必須相容低版本jdk api，這是jdk對廣大java開發者的重要承諾。而sun子孫包中的類不保證相容性，因為它們是jdk開發組使用的，一般比較底層。如果你使用了sun子孫包中的類：
a.編譯時會出現警告
b.升級jdk後可能編譯無法通過，需要修改程式碼
解決方法：不使用sun子孫包中的類，自己實現或採用第三方類庫
13、語句塊大括號問題
現象：for,if語句塊中只有一條語句時，省略了大括號危害：影響程式碼書寫一致性，如果程式碼塊新增一條語句，依舊需要新增大括號
解決方法：每個語句塊都新增大括號，即使語句塊中只有一條語句。省略大括號可能是受C語言的影響，java中則一般不省略。
說到這呢，Java大括號位置也是如此，Java的打括號是左半邊位於右上方，右半邊位於左下方，而C語言則都位於左側。
當然並不是說java風格的大括號就要比C風格的好，但你選擇了某語言就應當遵守該語言的相關慣例與規範。
14、過多的字串相加
現象：程式碼中過多的字串直接相加危害：本來字串相加是再正常不過的事情，但是，當用於相加的字串數量很大時，就不應該直接用加號相加。
由於String是常量，用加號相加時會不斷產生新物件，特別是字串數量很多的情況，浪費記憶體，效能也不好，而且不利於修改。
解決方法：
a.使用String.format，這適用於字串數量不是很多的情況,數量很多，特別是數量還不確定的情況則使用方法b
b.使用StringBuilder或StringBuffer物件進行字串相加。 StringBuilder是執行緒不安全的， StringBuffer是執行緒安全的，
但是很多人在方法內部進行字串相加時用的卻是 StringBuffer，在方法內部是不會出現多執行緒情況的，所以使用 StringBuilder即可。
15、保留了冗餘逗號(Javascript)
現象：在JSON陣列中，各個元素以逗號分隔，因格式書寫原因，很多人在最後一個元素後保留了逗號。危害：大部分瀏覽器相容了這種情況，並不會出錯，但也有例外(IE)。
解決方法：為了嚴謹起見，請把冗餘的逗號去掉。
16、資料庫表名，欄位名稱不規範
這裡且不論資料庫表的設計是否符合業務需要，只論表名與欄位名。現象：同一資料庫中的表與表字段名稱有大寫的，小寫的，大小寫混合的，駝峰式的，下劃線連線的，簡直亂成了一鍋粥。
危害：名稱不規範，不利於閱讀與理解，與很多開發人員的命名方式相違悖。
解決方法：表名與欄位名一般都為大寫，各個單詞之間使用下劃線("_")相連，表名與欄位名都有註釋。
綜上所述，本人深感開發一個好的軟體的不容易，不利因素太多了：人力、開發成本、時間、開發人員水來。作為一個開發人員，很多因互是我們所決定不了的，但是自身的水平卻是是自己可以把握的。一個開發人員應該在開發的過程有所收穫，努力提高自己的開發水平，寫程式碼的習慣與態度是前提，如果這一點都做不到，我想水平一般也不會高到哪去。所以請注意自己寫程式碼的水平與態度！
本人極力推薦看一本書：《重構_改善既有程式碼的設計》，相信看完之後一定會有所收穫(大神除外)。