大牛架構師珍藏的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
  • Timer是什麼 Timer 是一種用於創建定期粒度行為的機制。 與標準的 .NET System.Threading.Timer 類相似,Orleans 的 Timer 允許在一段時間後執行特定的操作,或者在特定的時間間隔內重覆執行操作。 它在分散式系統中具有重要作用,特別是在處理需要周期性執行的 ...
  • 前言 相信很多做WPF開發的小伙伴都遇到過表格類的需求,雖然現有的Grid控制項也能實現,但是使用起來的體驗感並不好,比如要實現一個Excel中的表格效果,估計你能想到的第一個方法就是套Border控制項,用這種方法你需要控制每個Border的邊框,並且在一堆Bordr中找到Grid.Row,Grid. ...
  • .NET C#程式啟動閃退,目錄導致的問題 這是第2次踩這個坑了,很小的編程細節,容易忽略,所以寫個博客,分享給大家。 1.第一次坑:是windows 系統把程式運行成服務,找不到配置文件,原因是以服務運行它的工作目錄是在C:\Windows\System32 2.本次坑:WPF桌面程式通過註冊表設 ...
  • 在分散式系統中,數據的持久化是至關重要的一環。 Orleans 7 引入了強大的持久化功能,使得在分散式環境下管理數據變得更加輕鬆和可靠。 本文將介紹什麼是 Orleans 7 的持久化,如何設置它以及相應的代碼示例。 什麼是 Orleans 7 的持久化? Orleans 7 的持久化是指將 Or ...
  • 前言 .NET Feature Management 是一個用於管理應用程式功能的庫,它可以幫助開發人員在應用程式中輕鬆地添加、移除和管理功能。使用 Feature Management,開發人員可以根據不同用戶、環境或其他條件來動態地控制應用程式中的功能。這使得開發人員可以更靈活地管理應用程式的功 ...
  • 在 WPF 應用程式中,拖放操作是實現用戶交互的重要組成部分。通過拖放操作,用戶可以輕鬆地將數據從一個位置移動到另一個位置,或者將控制項從一個容器移動到另一個容器。然而,WPF 中預設的拖放操作可能並不是那麼好用。為瞭解決這個問題,我們可以自定義一個 Panel 來實現更簡單的拖拽操作。 自定義 Pa ...
  • 在實際使用中,由於涉及到不同編程語言之間互相調用,導致C++ 中的OpenCV與C#中的OpenCvSharp 圖像數據在不同編程語言之間難以有效傳遞。在本文中我們將結合OpenCvSharp源碼實現原理,探究兩種數據之間的通信方式。 ...
  • 一、前言 這是一篇搭建許可權管理系統的系列文章。 隨著網路的發展,信息安全對應任何企業來說都越發的重要,而本系列文章將和大家一起一步一步搭建一個全新的許可權管理系統。 說明:由於搭建一個全新的項目過於繁瑣,所有作者將挑選核心代碼和核心思路進行分享。 二、技術選擇 三、開始設計 1、自主搭建vue前端和. ...
  • Csharper中的表達式樹 這節課來瞭解一下表示式樹是什麼? 在C#中,表達式樹是一種數據結構,它可以表示一些代碼塊,如Lambda表達式或查詢表達式。表達式樹使你能夠查看和操作數據,就像你可以查看和操作代碼一樣。它們通常用於創建動態查詢和解析表達式。 一、認識表達式樹 為什麼要這樣說?它和委托有 ...
  • 在使用Django等框架來操作MySQL時,實際上底層還是通過Python來操作的,首先需要安裝一個驅動程式,在Python3中,驅動程式有多種選擇,比如有pymysql以及mysqlclient等。使用pip命令安裝mysqlclient失敗應如何解決? 安裝的python版本說明 機器同時安裝了 ...