大牛架構師珍藏的10條編程原則

来源:https://www.cnblogs.com/88223100/archive/2023/01/14/principles-of-programming.html
-Advertisement-
Play Games

程式員擁有一個較好的編程原則能使他的編程能力有大幅的提升,可以使其開發出維護性高、缺陷更少的代碼。以下內容梳理自StactOverflow的一個問題:編程時你最先考慮的準則是什麼? ...


程式員擁有一個較好的編程原則能使他的編程能力有大幅的提升,可以使其開發出維護性高、缺陷更少的代碼。以下內容梳理自StactOverflow的一個問題:編程時你最先考慮的準則是什麼?

 

目錄

 

  • KISS(Keep It Simple Stupid)

  • DRY(Don’t Repeat Yourself)

  • YAGNI – You ain’t gonna need it

  • Code For The Maintainer

  • Be as lazy as possible.

  • Programming is only the road, not the way.

  • If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.

  • Know your path, Neo.

  • If it wasn’t tested, it is broken.

  • 與程式溝通時分辨原因和結果,與人交流時要分辨事實和觀點

 

KISS(Keep It Simple Stupid)

 

KISS原則是英語 Keep It Simple, Stupid 的首字母縮略字,是一種歸納過的經驗原則。KISS 原則是指在設計當中應當註重簡約的原則。總結工程專業人員在設計過程中的經驗,大多數系統的設計應保持簡潔和單純,而不摻入非必要的複雜性,這樣的系統運作成效會取得最優;因此簡單性應該是設計中的關鍵目標,儘量迴避免不必要的複雜性。

 

圖片

 

這個首字母縮略詞根據報導,是由洛克希德公司的首席工程師凱利·約翰遜(U-2 、SR-71等的設計者)所創造的。雖然長久以來,它一直是被寫為 “Keep it simple, stupid”,但約翰遜將其轉化成 “Keep it simple stupid”(無逗號),而且這種寫法仍然被許多作者使用。詞句中最後的 S並沒有任何隱涵工程師是愚蠢的含義,而是恰好相反的要求設計是易使人理解的。

 

說明這個原則最好的實例,是約翰遜向一群設計噴射引擎飛機工程師提供了一些工具,他們所設計的機具,必須可由一名普通機械師只用這些工具修理。因此,“愚蠢”是指被設計的物品在損壞與修複的關聯之間,它們的難易程度。這個縮寫詞已被美國軍方,以及軟體開發領域的許多人所使用。

 

另外相類似的概念也可作 KISS原則的起源。例如“奧卡姆剃刀”,愛因斯坦的“一切儘可能簡單”、達芬奇的“簡單是最終的複雜性” 、安德魯·聖艾修伯里的“完美不是當它不能再添加時,它似乎是在它不能被進一步刮除時實現的”。

 

有兩種軟體設計方法,一種是儘可能的簡單並保證沒有什麼缺陷。另外一種方式是儘可能的複雜並保障沒有什麼缺陷。而第一種方式相比第二種更加困難。

 

保持簡單(避免複雜)永遠是你應該做的第一件事,簡單的代碼不僅寫起來簡單、不容易出Bug,還易於維護。簡單規則下,還包括:

 

  • Don’t Make Me Think:如果一段程式對於閱讀者來說需要花費太多的努力才能理解,那它很可能需要進一步簡化。

 

  • 最少意外原則:程式代碼應儘可能的不要讓閱讀者感到意外。也就是說應該遵循編碼規範和常見習慣,按照公認的習慣方式進行組織和命名,不符常規的編程動作應該儘可能的避免。

 

如何把Kiss原則應用到工作中?

 

  • 謙虛,不要認為自己是個天才,這是你第一個誤解。只有謙虛了,你才能真正達到超級天才的水平,即使不行,who cares!你的代碼那麼stupid simple,所以你不需要是個天才!

 

  • 將你的任務分解為4-12小時的子任務。

 

  • 把你的問題拆分成多個小問題。每個問題用一個或者很少的幾個類來解決掉。

 

  • 保持你的方法足夠小,每個方法永遠不要超過30-40行代碼。每個方法都應該只處理一個小小的問題,不要搞太多uses case進去。如果你的方法中有多個分支,嘗試把他們拆分成多個小的方法。這樣不僅容易閱讀和維護,找bug也更快。慢慢的你將學會愛。

 

  • 讓你的類也小點,原則和上面的方法是一樣的。

 

  • 先解決問題,然後開始編碼。不要一邊編碼,一邊解決問題。這樣做也沒什麼錯,但你有能力提前把事情切分成多個小的塊,然後開始編碼可能是比較好的。但也請你不要害怕一遍遍重構你的代碼。另外行數還不是為了衡量質量的標準,只是有個基本的尺子而已。

 

  • 不要害怕幹掉代碼。重構和重做是兩個非常重要的方面。如果你遵循上面的建議,重寫代碼的數量將會最小化,如果你不遵循,那麼代碼很可能會被重寫。

 

  • 其他的任何場景,都請你嘗試儘可能的簡單,simple,這也是最難的一步,但一旦你擁有了它,你再回頭看,就會說,之前的事情就是一坨屎。

 

DRY(Don’t Repeat Yourself)

 

圖片

 

DRY即Don’t repeat yourself(不要重覆你自己,簡稱DRY),或一個規則,實現一次(One rule, one place)是面向對象編程中的基本原則,程式員的行事準則。旨在軟體開發中,減少重覆的信息。DRY的原則是“系統中的每一部分,都必須有一個單一的、明確的、權威的代表”,指的是(由人編寫而非機器生成的)代碼和測試所構成的系統,必須能夠表達所應表達的內容,但是不能含有任何重覆代碼。當DRY原則被成功應用時,一個系統中任何單個元素的修改都不需要與其邏輯無關的其他元素髮生改變。此外,與之邏輯上相關的其他元素的變化均為可預見的、均勻的,並如此保持同步。

 

我對DRY的理解:

 

  • 儘可能的減少重覆,如代碼重覆、文檔重覆、數據重覆、表徵重覆、開發人員重覆(相同的功能不能的開發人員的優自己的實現)

 

  • 不重覆造輪子,能夠使用開源的解決方案的情況下沒有必要再實現一遍。

 

  • 重覆的事項,儘可能的使用自動化程式解決。

 

  • 不要過於優化,過度追求DRY,破壞了程式的內聚性。

 

相關規則有: 

代碼復用:http://en.wikipedia.org/wiki/Code_reuse

 

YAGNI – You ain’t gonna need it

 

YAGNI 是You Ain’t Gonna Need It(你不會需要它)的簡寫,是極限編程的關鍵原則。YAGNI意思非常簡單:僅在您真正需要它們時才去做,而不是在您認為或預見將來可能需要它們時就提前做了!

 

圖片

 

您可以將YAGNI視為即時製造的擁護者。在這種情況下,製造業正在編寫代碼並交付功能。只有當有人真的需求功能存在時,您才可以開始工作並創建它。否則,您將保持自己的懶惰!

 

它為什麼如此重要?沒有編寫的每一行代碼都是時間,因此可以節省金錢。但是,甚至更多!它是:

 

  • 更少的代碼維護

  • 更少的代碼測試

  • 事情發生變化時更少的代碼可重構

  • 更多時間用於更重要的功能

  • 更多時間用於文檔編製

 

而且還包括:

 

  • 節省了編譯/移植的時間

  • 節省了測試運行的時間

  • 生成時/運行時節省了資源

  • 不必以某種方式保留的知識

 

它可以防止什麼?如今,大多數軟體開發都是根據客戶的需求進行的。無論您是在產品公司,在提供開發服務的公司還是在其他地方工作。總是會在某處某人想要具有某個功能。是您的客戶要求具有某個需求的功能,還是產品經理響應客戶的反饋的功能。無論實際驅動者是誰,無論是早晚,這都是實際需求的體現。您正確預見未來功能請求的機會非常低。因此,您很有可能實現某些功能,而不是您的實際利益相關者想要的功能。過早地執行某些操作很可能會導致一切都被丟棄。這是一個沒人真正喜歡的場景!然後,有時會發生另一種情況:沒有人真正需要該功能!

 

Code For The Maintainer

 

為維護者編寫程式。比如讓代碼有自解釋的功能。在你編寫代碼的時候永遠記得將來需要維護他。

 

Be as lazy as possible.

 

圖片

 

人類因“偷懶”而進步。懶惰只是創造了需求。需求本身並不算進步。滿足需求形成了進步。

 

偷懶還包括:

 

  • 不要重覆發明輪子

  • 過度優化是萬惡之源

 

Programming is only the road, not the way.

 

編碼只是一種實現方式,而不是解決方案。編碼只是告訴電腦應該如何去做。要編寫高效、可靠的軟體需要精通演算法、最佳實踐等其他與變成相關的內容。

 

編程前需要先瞭解你要解決的問題是什麼。編程只是手段並不是目的。能實現並不代表需要實現。知道什麼時候不需要編程或沒有必須要去編程。

 

If you are in a hurry, stroll along slowly. 

If you really are in a hurry, make a detour.

 

如果你很忙,那就放慢速度。如果你真的很忙,那就先放一放。這聽起來很愚蠢,但是千萬不要讓自己陷入會導致後期問題的妥協。如果你正在編寫程式的核心部分,儘可能保證精確。如果你在編寫離核心代碼較遠的方法,可以儘可能的加快速度。

 

Know your path, Neo.

 

圖片

 

知道你的實現路徑,你需要瞭解你每天使用的環境、工具及其他依賴的內容,並且把它調試到適合自己的配置。如果你的編程環境真的很好,那麼你編程中的基本不需要關心他。如果你需要完成一項任務,最好的方式是不要引進“新的內容”,只有當你完全掌握“新的內容”的時候再去考慮引入。

 

If it wasn’t tested, it is broken.

 

如果沒有經過測試的代碼都是不能運行的。

 

與程式溝通時分辨原因和結果,與人交流時要分辨事實和觀點

 

相關的準則,包括:

 

  • 最小化耦合關係:代碼片段(代碼塊,函數,類等)應該最小化它對其它代碼的依賴。這個目標通過儘可能少的使用共用變數來實現。

 

  • 最大化內聚性:具有相似功能的代碼應該放在同一個代碼組件里。

 

  • 開放/封閉原則:程式里的實體項(類,模塊,函數等)應該對擴展行為開放,對修改行為關閉。換句話說,不要寫允許別人修改的類,應該寫能讓人們擴展的類。

 

  • 單一職責原則:一個代碼組件(例如類或函數)應該只執行單一的預設的任務。

 

  • 隱藏實現細節:隱藏實現細節能最小化你在修改程式組件時產生的對那些使用這個組件的其它程式模塊的影響。

 

  • 笛米特法則(Law of Demeter) —— 程式組件應該只跟它的直系親屬有關係(例如繼承類,內包含的對象,通過參數入口傳入的對象等。)

     

原文及鏈接:What do you consider the 1st principle(s) of programming?

http://programmers.stackexchange.com/questions/91527/what-do-you-consider-the-1st-principles-of-programming

 

>>>>

參考資料

 

 

作者丨錢魏Way

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/principles-of-programming.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • public class SerializeHelper { #region 二進位格式 /// <summary> /// Binary 序列化使用前需要標記類可序列化 /// </summary> /// <param name="fileName">序列化到指定的文件</param> /// ...
  • Helix 解碼庫提供了MP3內容的MPEG相容解碼, 支持可變比特率, 恆定比特率以及立體聲和單聲道音頻格式. Helix 的定點解碼庫專門針對ARM處理器進行了優化. Helix 解碼庫是以幀為解碼單位的, 一次解碼一幀, 運行需要占用的資源很少, 可以在任何能夠執行長整數乘法運算(兩個32位輸... ...
  • 以下介紹PY32F0系列在Ubuntu下如何使用GCC Arm Embedded Toolchain環境進行開發和燒錄. GitHub 倉庫地址: https://github.com/IOsetting/py32f0-template ...
  • PY32F0 屬於 32位 M0 內核的MCU, 配置上有 16KF+2KR, 20KF+3KR, 32KF+4KR, 64KF+8KR 這些組合, 根據外設的豐富程度分成了 PY32F002, PY32F003, PY32F030, PY32F072 這四個系列, 另外還有一家芯嶺科技貼牌的 XL... ...
  • 本文主要目的是在拿到一個藍牙模塊後,將其作為從機來對一些基本的軟體功能進行測試,用以快速驗證是否滿足基本的使用需求和功能指標。 ...
  • GreatSQL社區原創內容未經授權不得隨意使用,轉載請聯繫小編並註明來源。 GreatSQL是MySQL的國產分支版本,使用上與MySQL一致。 作者: KAiTO 文章來源:GreatSQL社區原創 什麼是中繼日誌(relay log) 中繼日誌(relay log)只在主從伺服器架構的從伺服器 ...
  • 網頁DOM編程 Node、Document和Element三者關係 Node:各種類型的 DOM API 對象會從這個介面繼承。 Document:表示在任何在瀏覽器中載入的網頁(DOM樹)。 Element:描述所有相同種類的元素所普遍具有的方法和屬性。 完整的繼承關係如下圖: 說明:圖中的子類可 ...
  • 前言 這篇博文續接的是 UML建模、設計原則、創建型設計模式、行為型設計模式,有興趣的可以看一下 3.3、結構型 這些設計模式關註類和對象的組合。將類和對象組合在一起,從而形成更大的結構 * 3.3.1、proxy 代理模式 定義:為某對象提供一種代理以控制對該對象的訪問。即:客戶端通過代理間接地訪 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...