大牛架構師珍藏的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
  • 一:背景 1. 講故事 年前遇到了好幾例托管堆被損壞的案例,有些運氣好一些,從被破壞的托管堆記憶體現場能觀測出大概是什麼問題,但更多的情況下是無法做出準確判斷的,原因就在於生成的dump是第二現場,借用之前文章的一張圖,大家可以理解一下。 為了幫助更多受此問題困擾的朋友,這篇來整理一下如何 快狠準 的 ...
  • 前言 .NET6 開始,.NET Croe API 項目取消了 Startup.cs 文件,在 Program.cs 文件的 Main 函數中完成服務的註冊和中間件管道的管理。但當我們項目引入更多包的時候,Program.cs 文件也會看起來很臃腫。 而且,我們不只會有一個後端項目,為了方便快速創建 ...
  • 目錄 背景 get 與 post 的區別 所有介面都用 post 請求? 背景 最近在逛知乎的時候發現一個有趣的問題:公司規定所有介面都用 post 請求,這是為什麼? 看到這個問題的時候其實我也挺有感觸的,因為我也曾經這樣問過我自己。在上上一家公司的時候接到一個項目是從零開始搭建一個微服務,當時就 ...
  • *以下內容為本人的學習筆記,如需要轉載,請聲明原文鏈接 微信公眾號「englyf」https://mp.weixin.qq.com/s/2GFLTstDC7w6u3fTJxflNA 本文大概 1685 個字,閱讀需花 6 分鐘內容不多, 但也花了一些精力如要交流, 歡迎關註我然後評論區留言 謝謝你的 ...
  • 在新版本的pandas中,上述代碼會引起警告,建議改成SQLAlchemy connectable(engine/connection),後續代碼將引入這種升級的連接方式。 ...
  • 幾乎所有的高級編程語言都有自己的垃圾回收機制,開發者不需要關註記憶體的申請與釋放,Python 也不例外。Python 官方團隊的文章 https://devguide.python.org/internals/garbage-collector 詳細介紹了 Python 中的垃圾回收演算法,本文是這篇 ...
  • 如果您想查找高於或低於平均值的數字,可以不必計算該平均值,就能查看更高或更低的值。通過Java應用程式,可以自動突出顯示這些數字。除了快速突出顯示高於或低於平均值的值外,您還可以查看高於或低於的值的個數。現在讓我們看看如何在 Java應用程式中實現此操作。 引入jar包 導入方法1: 手動引入。將  ...
  • 第一種方式:使用{} firstDict = {"name": "wang yuan wai ", "age" : 25} 說明:{}為創建一個空的字典對象 第二種方式:使用fromkeys()方法 second_dict = dict.fromkeys(("name", "age")) #valu ...
  • 在golang中可以使用a := b這種方式將b賦值給a,只有當b能進行深拷貝時a與b才不會互相影響,否則就需要進行更為複雜的深拷貝。 下麵就是Go賦值操作的一個說明: Go語言中所有賦值操作都是值傳遞,如果結構中不含指針,則直接賦值就是深度拷貝;如果結構中含有指針(包括自定義指針,以及切片,map ...
  • 本文結合京東監控埋點場景,對解決樣板代碼的技術選型方案進行分析,給出最終解決方案後,結合理論和實踐進一步展開。通過關註文中的技術分析過程和技術場景,讀者可收穫一種樣板代碼思想過程和解決思路,並對Java編譯器底層有初步瞭解。 ...