高效編程的規則有哪些

這篇文章主要講解了“高效編程的規則有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“高效編程的規則有哪些”吧！

1. 童子軍規則

"一定要讓營地的清潔劑比您發現的要干凈"-這是一個很好的生活準則。 當您靠近營地時，即使不是由您自己造成的，也應使其清潔。 這是偵察兵的規則之一。  編程同樣適用。 正如羅伯特·C·馬丁(Robert C. Martin)所說："讓代碼比發現的要好"。  如果我們發現別人寫的一些難以閱讀的應用程序，并且花了一些時間來理解，那就讓它至少好一點。  如果它不在我們正在處理的任務范圍之內，則可以始終創建一個新的小型技術任務，對其進行詳細描述并將其帶入下一個沖刺。

此規則的簡約版本更像是在公共廁所中唱歌。  我們至少應該至少不惡化它所處的條件。我們必須記住，有些人有一天會接管我們開發的那部分應用程序，并嘗試對其進行修改。 讓我們不要讓生活更艱難。

2. 考慮問題，而不僅僅是解決方案

軟件開發人員確實非常擅長實施解決方案。 我們了解語言，模式，庫，框架，并了解如何使用它們。 問題在于，從業務的角度來看，我們經常做的事情沒有任何意義。  您正在開發的某些功能可能與企業所有者不知道的現有功能重復。 有些可能沒有經過深思熟慮，將永遠無法發布到下一個版本，或者根本沒有用戶會使用它們。  那是浪費時間，金錢和挫敗感的巨大浪費。 很多人都不想問開發人員他們的意見，只是假設他們的工作就是交付功能。 沒有商量。 僅技術工作。

開發人員每天都在使用該應用程序。 他們知道每個功能，即使沒有人使用它。 有時，從業務角度看似乎容易完成的任務需要花費數月的開發時間。  有些似乎幾乎不可能的工作要花幾天時間。 原因是將要實施一項功能的人員與提出該功能的人員之間缺乏溝通。 兩者之間存在巨大差異：

• 為用戶的購物車創建永久存儲

• 用戶應該能夠保存他們的購物車，并在移動和Web應用程序上使用它

第一個很簡單。 無話可問。 第二個要難一些，因為它使您思考推理，而您將成為提出給定問題的解決方案的人。  關于細節，功能要求，質量屬性和其他方面，會有很多問題。 由于您現在不僅是執行者，因此解決方案將更好地解決。

3. 考慮總擁有成本

有時會偷工減料，以后跳過測試，留下臨時解決方案并承諾稍后進行糾正，這是非常誘人的。 在大多數情況下，如果它不會破裂，您將永遠不會。  將有一個新任務，優先級，要實現的功能和要解決的問題。 您將遇到的問題是這樣的應用程序可能會損壞。 而且，將很難修復。

功能的總擁有成本是從開發開始到部署，維護再到終止所花費的金錢和精力的總和。 如果我們在開發過程中采用捷徑，那將是最便宜的部分。  您可能發布的速度更快，但是維護會很麻煩，用戶會感到不滿意，并且總的來說，所有東西都比它應該的貴。

4. 使用SOLID

在編程中，有很多很棒的規則以首字母縮略詞形式出現：DRY，KISS，YAGNI，SOLID等。  SOLID是一組規則，可以幫助使代碼更整潔并避免常見的陷阱。

在將代碼推送到存儲庫之前，這可能是一個很棒的清單。 該課程是否支持"單一責任原則"? 可以用同一層次結構中的任何其他類替代該類(是否滿足LSP)?  這將有助于過濾掉許多未來問題的來源。 理解并有意識地運用每條規則背后的原因，將使您成為一名更好的程序員，并提高代碼審查的質量。

5. 使用設計模式

在大多數情況下，您不是第一個嘗試解決您面臨的問題或實現具有類似要求的功能的人。  已經有成千上萬的CRM，CMS，銀行系統，聊天室，在線商店，市場以及人們能想到的基本上任何可能的應用程序類型。  您正在開發的系統可能是市場上最好的，或者具有其他人所沒有的某些極其先進和獨特的功能。 不過，大多數工作在某種程度上都是參考性的。  其他人可能會嘗試以多種不同的方式來做到這一點，甚至描述整個過程。 它可以為您省去很多麻煩，并為您提供更好的解決方案。

四人幫有一本很棒的書，介紹了一些可用于解決常見問題的可重復模式。 它寫于1994年，但那些仍然有效和有用。  在軟件中，那是古老的時代，但是現在我們在編寫代碼時面臨的問題并沒有太大不同。 從那以后，出現了許多新的設計模式。 了解他們可以使您的工作輕松得多。

所有設計都是重新設計。 向他人學習

6. 最小化復雜度

從本質上講，軟件開發是一項復雜的任務。 不要使其變得不必要的復雜。 有時通過在函數中引入一些額外的" if"或"循環"來實現一些業務規則非常誘人。  開發將更快，但是代碼將變得更暗，添加新功能只會使其變得更加復雜。 如果出現問題，將更難找出原因。

有一個偉大而又非常簡單的度量標準，其秘密名稱為" Cyclomatic Complexity"。 它是在70年代推出的，但仍然非常有用。  此度量標準衡量代碼執行的多種方式。 每個條件語句和循環都將得分加+1。 分數越小越好。 當我們分析一種方法時，分數在范圍內：

• 0-10：代碼結構合理，不應引起意外問題

• 10–20：代碼非常復雜，并且有很多潛在的執行路徑可供測試。 重構候選人

• 20–50：代碼非常復雜，應進行重構

• 50歲以上：必須進行重構

可讀性比性能更重要。 該聲明有一些限制，但從長遠來看，可讀性基本上是有回報的。 您可以使用更少的錯誤來更改代碼。  微觀優化可能很容易使您的代碼變得一團糟，并且不會給用戶帶來太多價值。

7. 不要一個人做

聽起來可能違反直覺，但是編程是一種社交活動。 隱藏在地下室黑暗中的程序員時代已經結束。 分享專業知識和經驗變得越來越重要。  在最壞的情況下，您要與之交談的人將成為您的橡皮鴨，但很可能您會收到一些有價值的反饋。 有人可能會發現您根本沒有考慮的解決方案中的問題。  從不同的角度看待是一個很好的工具，并且非常容易獲得。

任何人都不應對已部署的代碼負責。 提供新功能是團隊而非個人的工作。  代碼審查，配對編程，拉取請求是一種工具，可以承擔一個人的責任，并將其移交給具有最佳跨職能技能的一群人。  對于可能影響整個公司業績的重要功能，開發人員的責任實在太大了。 這種情況非常不健康，絕不應該發生。

8. 測試是必須的

盡早發現錯誤非常重要，可以節省大量的工作量和客戶的憤怒電話。 盡早發現問題使他們更容易解決。 在開發特定應用程序時，我們能夠最好地記住所有細節和邏輯。  我們記得做出特定決定的所有理由以及如何調試每個應用程序。 修復錯誤的成本會隨著時間呈指數增長。

9. 學習英語

共享知識一直是軟件社區的基礎之一。 大多數信息是用英語編寫的，并且易于訪問。 目前，它是軟件世界中最流行的語言。  如果您不會用英語讀寫，您將會遇到很多困難，并失去很多機會。 而且，幾乎每種語言的語法默認情況下都是用英語書寫的。

用英語寫注釋和名稱也是一個好習慣。 它使代碼更整潔，并且與語法更加一致。  如果我們要與他人(尤其是來自不同國家/地區的人)共享代碼，那么基本上沒有比英語更好的方法了。

10. 多任務使你變得愚蠢

人們根本無法一次做好多件事情。 軟件開發需要使用抽象概念，并且通常需要構建非常復雜的思維模型。  如果您分心或開始從事其他工作，那么您將失去一切，必須從頭開始。 此外，有多項研究證明多任務處理對性能，生產率和智商有負面影響。

我曾經在軟件公司參加過一次培訓，介紹了一種非常有用的實踐。 如果您沒有任何預定的會議或電話，則可以自由播放"西紅柿"。 規則非常簡單-您無需與任何人交談。  如果有人問您任何問題，您將用一個單詞回答："西紅柿"。 因此，您表明自己正在工作之中，不想被打擾。 人們處于"西紅柿模式"時，他們還會在日歷中顯示選定的時間。  完全"蕃茄"化并不總是一件好事，但這是一種改善性能的有趣方式。

11. 少做多好

更少的代碼和更好的維護基礎架構。 有很多人喜歡在他們的應用程序，模塊，服務器，節點，pod，微服務或任何其他東西中吹噓大量的代碼行。  應用程序中的每一行代碼都有可能具有最高的質量，并且恰好位于正確的位置。 但這是非常罕見的情況。 如果您可以使用較少的資源來完成相同的工作，則應該這樣做。  質量是目標，而不是數量。

感謝各位的閱讀，以上就是“高效編程的規則有哪些”的內容了，經過本文的學習后，相信大家對高效編程的規則有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！