進行軟體開發，整天敲程式碼、好不容易除錯成功，但是程式碼的質量堪憂，可讀性不是很高，反過頭來還得對程式碼進行完善。也許這不是你的編碼能力問題，很有可能在你進行程式碼編寫時，一些看似不重要的編碼注意事項沒有遵守。這有一份高階開發人員經常遵循的 19 條原則，其中很多與實際編碼無關，而是與流程以及如何處理任務有關，可能對你有幫助。

1. Rule Of Three 原則

這是一條程式碼重構的經驗法則，用於決定何時將複製的程式碼段替換為新的程式碼 / 過程 / 方法。

它的含義是，第一次用到某個功能時，你寫一個特定的解決方法;第二次又用到的時候，你拷貝上一次的程式碼;第三次出現的時候，你要著手「抽象化」，寫出通用的解決方法。

該原則的主要思想是使程式碼 / 過程 / 方法更加通用，從而保證在其他地方可以重複使用。

2. 應用程式結構與編碼方式保持一致

應用程式結構與編碼方式保持一致有助於提高其可讀性和可維護性。

嘗試制定編碼標準，這有助於保持編碼一致性。編碼標準應該與變數的命名規則一樣少。另一大問題是應用程式的結構，開發人員進行更改或新增新內容的地方應該很明顯。

3. 減少程式巢狀

if 裡面巢狀 if 會使得程式很混亂，程式碼很難讀。在編寫程式碼時可能無法繞開這些問題，但你需要經常檢視程式碼結構。

else if 同樣如此，因此需要儘量避免巢狀。

一種有效的解決方法是衛語句：衛語句把複雜的條件表示式拆分成多個條件表示式。

不使用衛語句的編碼方式：

使用衛語句的編碼方式：

4. 瞭解全域性很重要

瞭解全域性有助處理較小的細節。一旦瞭解了全域性，你就不會花很長的時間在小細節上。

5. 程式中的命名

在程式設計中進行命名是最困難的事情之一，包括為一個類、一個方法命名，甚至是為變數命名。優秀的開發人員會花時間考慮相關的命名方式，這樣會增加程式的可讀性。

6. 減少技術負債

技術負債指開發人員為了加速軟體開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟體開發的方案，從而在未來給自己帶來的額外開發負擔。這種技術上的選擇就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。軟體工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用，或是進行重構，把架構改善為最佳實現方式。

對於技術負債問題，提高預估時間有助於解決這類問題。儘自己最大的努力寫好程式碼，否則你將不斷地進行程式碼完善。

7. 提高預估時間

你會看到，高階開發人員總是給任務預留更多的時間，因為他們知道完成任務所需的時間總是高於預期，而且在評估階段增加一個緩衝時間可以真正幫助你把事情做好。

這確實有助於解決技術負債問題。如果你低估了任務完成時間，你就可能會因為時間不夠而寫出僅僅可以執行的程式碼，簡潔性、可維護性就顧不上了。

8. 文件和程式碼註釋

文件和程式碼註釋有助於儲存上下文和共享知識。你會聽到有經驗的人一直在說，我們是否可以記錄這個過程，或者程式碼審查失敗，因為對介面之類的內容沒有任何註釋。

9. 刪除不需要的程式碼

許多缺乏自信的開發人員會註釋掉大量的程式碼塊，而不是選擇刪除。但是程式碼版本控制是有目的的!優秀的開發人員會刪除應用程式中不好的程式碼。

10. 花時間進行程式碼評審

優秀的開發人員會花更多的時間在程式碼評審上，程式碼評審的重要性包括：

• 更早地發現錯誤;
• 提高開發人員的技能，並讓團隊的其他成員參與到良好的實踐中;
• 共享知識;
• 一致的設計和實現。

最好的程式碼評審過程是：

對於一個風險較小的任務，1 名開發人員評審就可以;中型 / 大型更改或者是有風險的更改，應由 3 名開發人員進行評審，其中須有一位是高階開發人員;風險極高的更改或者是正在開發的應用程式的新部分，應該安排一次會議，3 名開發人員中至少有一位是首席開發人員，他們一起完成每條線並提出觀點。

11. 編寫好的測試

你會注意到經驗豐富、能力更強的開發人員花更多的時間編寫好的測試。擁有好的測試可以幫助你更有信心地擴充套件應用程式，並減少錯誤。

12. 花時間設計程式

在真正投入寫程式碼之前，開發者會經過一番思考並將程式碼分解成小塊。這有助於他們更好地將所有內容組合在一起並建立更清晰的程式碼。

13. 關注基礎原理，而不是語法

更多地關注基礎原理，而不是語法，有助於開發者更快地發現問題，也能更好地理解問題並在搜尋引擎上搜索解決方案。

14. 讓搜尋引擎成為你最好的朋友

高階開發者都是用搜索引擎來解決問題的專家。從上一條也可以看出，他們關注基礎原理而不是語法，因此知道要搜尋的關鍵詞。如果你一直專注於語法，這將很難做到。

15. 首先確保程式能執行，然後再完善

你經常會看到一些相對較弱的開發人員，他們一開始花費大量的時間讓程式看起來漂亮，但之後發現，程式不能執行。

優秀的開發人員會在更早的階段找到愉快的工作方式。在他們把事情做好之前，儘早發現問題。這可以幫助專案進行得更加順利。

16. 風險管理和問題解決

高階開發人員可以定義風險，能夠通過應用設計模式提煉出複雜的問題，並且能夠根據以往的經驗獨立解決不同的問題。

17. 多提問

高階開發人員什麼都想知道。他們不介意問問題，包括技術問題和業務問題，儘管這些問題聽起來非常簡單。理解業務需求有助於開發者編寫更好的程式碼!他們不害怕問問題，因為他們對自己的能力有信心。

18. 儘可能將邏輯排除在資料庫之外

這一點可以歸結為你正在構建的應用程式的型別，並且僅當它不會影響效能時才適用。

高階開發人員知道將資料庫查詢保留為簡單的 CRUD 操作。CRUD 是指在做計算處理時的增加 (Create)、檢索(Retrieve)、更新(Update) 和刪除(Delete)。

接下來，業務邏輯層應將 CRUD 操作整合在一起。這有助於開發人員瞭解在哪裡尋找業務邏輯。如果你在資料庫查詢和程式碼中有邏輯，這會很快變得混亂!

19. 保持程式碼簡潔

保持程式碼簡潔是最好的做法。即使這意味著要編寫更多行程式碼。下面是相對較弱的開發人員編寫的單行程式碼：

returndir.Keys.Any(k=>k>=limit)?dir.First(x=>x.Key>=limit).Value:dir[dir.Keys.Max()];

這樣的程式碼雖然可以執行，但可讀性很低。

看完三件事❤️

如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

1. 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
2. 關注公眾號 『 Java鬥帝 』，不定期分享原創知識。
3. 同時公眾號內回覆“666”即可免費領取1000道網際網路面試題