建站
咨詢
售后
建站咨詢
新聞中心
進行軟件開發(fā)，整天敲代碼、好不容易調(diào)試成功，但是代碼的質(zhì)量堪憂，可讀性不是很高，反過頭來還得對代碼進行完善。也許這不是你的編碼能力問題，很有可能在你進行代碼編寫時，一些看似不重要的編碼注意事項沒有遵守。這有一份高級開發(fā)人員經(jīng)常遵循的 19 條原則，其中很多與實際編碼無關(guān)，而是與流程以及如何處理任務(wù)有關(guān)，可能對你有幫助。
[[348021]]
1. Rule Of Three 原則
這是一條代碼重構(gòu)的經(jīng)驗法則，用于決定何時將復制的代碼段替換為新的代碼 / 過程 / 方法。
它的含義是，第一次用到某個功能時，你寫一個特定的解決方法;第二次又用到的時候，你拷貝上一次的代碼;第三次出現(xiàn)的時候，你要著手「抽象化」，寫出通用的解決方法。
該原則的主要思想是使代碼 / 過程 / 方法更加通用，從而保證在其他地方可以重復使用。
2. 應(yīng)用程序結(jié)構(gòu)與編碼方式保持一致
應(yīng)用程序結(jié)構(gòu)與編碼方式保持一致有助于提高其可讀性和可維護性。
嘗試制定編碼標準，這有助于保持編碼一致性。編碼標準應(yīng)該與變量的命名規(guī)則一樣少。另一大問題是應(yīng)用程序的結(jié)構(gòu)，開發(fā)人員進行更改或添加新內(nèi)容的地方應(yīng)該很明顯。
3. 減少程序嵌套
if 里面嵌套 if 會使得程序很混亂，代碼很難讀。在編寫代碼時可能無法繞開這些問題，但你需要經(jīng)常查看代碼結(jié)構(gòu)。
else if 同樣如此，因此需要盡量避免嵌套。
一種有效的解決方法是衛(wèi)語句：衛(wèi)語句把復雜的條件表達式拆分成多個條件表達式。
不使用衛(wèi)語句的編碼方式：
- if (account != null)
- {
- if (order != null)
- {
- if (order.term == Term.Annually)
- {
- // term annually
- }
- else if (order.term == Term.Monthly)
- {
- // term monthly
- }
- else
- {
- throw new InvalidEnumArgumentException(nameof(term));
- }
- }
- else
- {
- throw new ArgumentNullException(nameof(subscription));
- }
- }
使用衛(wèi)語句的編碼方式：
- if (account == null)
- {
- throw new ArgumentNullException(nameof(account));
- }
- if (order == null)
- {
- throw new ArgumentNullException(nameof(order));
- }
- if (order.term == Term.Annually)
- {
- // term annually (return here)
- }
- if (order.term == Term.Monthly)
- {
- // term monthly (return here)
- }
- throw new InvalidEnumArgumentException(nameof(order.term));
4. 了解全局很重要
了解全局有助處理較小的細節(jié)。一旦了解了全局，你就不會花很長的時間在小細節(jié)上。
5. 程序中的命名
在編程中進行命名是最困難的事情之一，包括為一個類、一個方法命名，甚至是為變量命名。優(yōu)秀的開發(fā)人員會花時間考慮相關(guān)的命名方式，這樣會增加程序的可讀性。
6. 減少技術(shù)負債
技術(shù)負債指開發(fā)人員為了加速軟件開發(fā)，在應(yīng)該采用最佳方案時進行了妥協(xié)，改用了短期內(nèi)能加速軟件開發(fā)的方案，從而在未來給自己帶來的額外開發(fā)負擔。這種技術(shù)上的選擇就像一筆債務(wù)一樣，雖然眼前看起來可以得到好處，但必須在未來償還。軟件工程師必須付出額外的時間和精力持續(xù)修復之前的妥協(xié)所造成的問題及副作用，或是進行重構(gòu)，把架構(gòu)改善為最佳實現(xiàn)方式。
對于技術(shù)負債問題，提高預估時間有助于解決這類問題。盡自己最大的努力寫好代碼，否則你將不斷地進行代碼完善。
7. 提高預估時間
你會看到，高級開發(fā)人員總是給任務(wù)預留更多的時間，因為他們知道完成任務(wù)所需的時間總是高于預期，而且在評估階段增加一個緩沖時間可以真正幫助你把事情做好。
這確實有助于解決技術(shù)負債問題。如果你低估了任務(wù)完成時間，你就可能會因為時間不夠而寫出僅僅可以運行的代碼，簡潔性、可維護性就顧不上了。
8. 文檔和代碼注釋
文檔和代碼注釋有助于保存上下文和共享知識。你會聽到有經(jīng)驗的人一直在說，我們是否可以記錄這個過程，或者代碼審查失敗，因為對接口之類的內(nèi)容沒有任何注釋。
9. 刪除不需要的代碼
許多缺乏自信的開發(fā)人員會注釋掉大量的代碼塊，而不是選擇刪除。但是代碼版本控制是有目的的!優(yōu)秀的開發(fā)人員會刪除應(yīng)用程序中不好的代碼。
10. 花時間進行代碼評審
優(yōu)秀的開發(fā)人員會花更多的時間在代碼評審上，代碼評審的重要性包括：
- 更早地發(fā)現(xiàn)錯誤;
- 提高開發(fā)人員的技能，并讓團隊的其他成員參與到良好的實踐中;
- 共享知識;
- 一致的設(shè)計和實現(xiàn)。
最好的代碼評審過程是：
對于一個風險較小的任務(wù)，1 名開發(fā)人員評審就可以;中型 / 大型更改或者是有風險的更改，應(yīng)由 3 名開發(fā)人員進行評審，其中須有一位是高級開發(fā)人員;風險極高的更改或者是正在開發(fā)的應(yīng)用程序的新部分，應(yīng)該安排一次會議，3 名開發(fā)人員中至少有一位是首席開發(fā)人員，他們一起完成每條線并提出觀點。
11. 編寫好的測試
你會注意到經(jīng)驗豐富、能力更強的開發(fā)人員花更多的時間編寫好的測試。擁有好的測試可以幫助你更有信心地擴展應(yīng)用程序，并減少錯誤。
12. 花時間設(shè)計程序
在真正投入寫代碼之前，開發(fā)者會經(jīng)過一番思考并將代碼分解成小塊。這有助于他們更好地將所有內(nèi)容組合在一起并創(chuàng)建更清晰的代碼。
13. 關(guān)注基礎(chǔ)原理，而不是語法
更多地關(guān)注基礎(chǔ)原理，而不是語法，有助于開發(fā)者更快地發(fā)現(xiàn)問題，也能更好地理解問題并在搜索引擎上搜索解決方案。
14. 讓搜索引擎成為你最好的朋友
高級開發(fā)者都是用搜索引擎來解決問題的專家。從上一條也可以看出，他們關(guān)注基礎(chǔ)原理而不是語法，因此知道要搜索的關(guān)鍵詞。如果你一直專注于語法，這將很難做到。
15. 首先確保程序能運行，然后再完善
你經(jīng)常會看到一些相對較弱的開發(fā)人員，他們一開始花費大量的時間讓程序看起來漂亮，但之后發(fā)現(xiàn)，程序不能運行。
優(yōu)秀的開發(fā)人員會在更早的階段找到愉快的工作方式。在他們把事情做好之前，盡早發(fā)現(xiàn)問題。這可以幫助項目進行得更加順利。
16. 風險管理和問題解決
高級開發(fā)人員可以定義風險，能夠通過應(yīng)用設(shè)計模式提煉出復雜的問題，并且能夠根據(jù)以往的經(jīng)驗獨立解決不同的問題。
17. 多提問
高級開發(fā)人員什么都想知道。他們不介意問問題，包括技術(shù)問題和業(yè)務(wù)問題，盡管這些問題聽起來非常簡單。理解業(yè)務(wù)需求有助于開發(fā)者編寫更好的代碼!他們不害怕問問題，因為他們對自己的能力有信心。
18. 盡可能將邏輯排除在數(shù)據(jù)庫之外
這一點可以歸結(jié)為你正在構(gòu)建的應(yīng)用程序的類型，并且僅當它不會影響性能時才適用。
高級開發(fā)人員知道將數(shù)據(jù)庫查詢保留為簡單的 CRUD 操作。CRUD 是指在做計算處理時的增加 (Create)、檢索(Retrieve)、更新(Update) 和刪除(Delete)。
接下來，業(yè)務(wù)邏輯層應(yīng)將 CRUD 操作整合在一起。這有助于開發(fā)人員了解在哪里尋找業(yè)務(wù)邏輯。如果你在數(shù)據(jù)庫查詢和代碼中有邏輯，這會很快變得混亂!
19. 保持代碼簡潔
保持代碼簡潔是最好的做法。即使這意味著要編寫更多行代碼。下面是相對較弱的開發(fā)人員編寫的單行代碼：
- return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];
這樣的代碼雖然可以運行，但可讀性很低。
文章名稱：我從高級開發(fā)者身上學到的19條編碼原則
本文路徑：http://www.5511xx.com/article/coosepi.html
