KISS 原則程式碼與人生斷捨離開發哲學 實踐簡約開發減法藝術提升效率與高品質維修

me
林彥成
2023-09-16 | 3 min.
文章目錄
  1. 1. 什麼是 KISS 原則與簡約開發?
  2. 2. KISS 原則:軟體開發的減法藝術
  3. 3. 有無相生:創造程式與生活的空間
  4. 4. 斷捨離實戰:從祖產程式碼到全域搜尋
  5. 5. 結語:為了更快下班而重構
  6. 6. FAQ:KISS 原則常見問題
    1. 6.1. Q1:簡單 (Simple) 與 簡陋 (Easy) 有什麼不同?
    2. 6.2. Q2:如何判斷我正在進行「過度工程化」?
    3. 6.3. Q3:捨不得刪掉舊程式碼怎麼辦?

什麼是 KISS 原則與簡約開發?

KISS 原則 (Keep It Simple, Stupid) 是一種強調系統設計應以「簡約」為核心目標的哲學。在軟體開發中,這意味著優先選擇最直觀、最容易理解的解決方案,而非炫技式的複雜架構或過度工程化(Over-engineering)。簡約開發的本質是「減法」的藝術:透過定期重構、無情刪除冗餘邏輯、以及精準定位元件功能,來降低系統的認知負擔與維護成本。一個簡單的系統不僅出錯率更低,且更具備應對未來需求變動的靈活性。無論是程式碼還是人生,能用一行解決的事,絕不寫兩行,這就是高效開發者最推崇的斷捨離魔法。


開始之前,先來談談工程師的日常:

  • 程式碼因為需求一直亂加,本來的水果刀被改成瑞士刀,導致系統臃腫難行。
  • 傳承的「祖產」程式碼難以更動,導致疊床架屋、違建加蓋,一個判斷不夠就補兩個湊一對。
  • 「這個需求很簡單,明天可以給一版嗎?」一天有一天的品質,一週也有一週的品質。

不知道大家有沒有一個體會,總是覺得為什麼再怎麼整理都整理不好?不論是程式碼、房間或是人生。這正是因為我們缺乏了 KISS 原則 的核心思維。

KISS 原則:軟體開發的減法藝術

回到實際一點的例子,時間有限且空間就是這麼大,但東西卻越來越多,越是追求收納反而越容易堆滿東西。在 程式開發流程 中,過於追求完美或過度工程化往往會導致浪費時間與資源。我們應該關注實際的商業需求,學習在追求效率與 程式碼品質 之間取得平衡。

在寫程式的世界中,最該拋棄的是不必要的複雜結構。資本主義社會中,我們常在有限資源中追求無限可能,但握緊拳頭時沒有任何空間,自然也就無法拿起新東西。於是我們開始學會放手,哀悼和告別舊的自己與冗餘的邏輯。

如同萬物,有開始,也會結束。


有無相生:創造程式與生活的空間

「有無相生」是道教哲學的一個重要概念,要先有空間,才會有機會存在與擁有。在軟體架構中,這體現為良好的 去耦合 設計。

有與無是相對的,一個概念需要存在,才能有相對的概念,就像是有光也才能有影子。當現在期待著不同的未來,那我們就要學會捨棄一些東西,先讓現在成為「無」的狀態,在未來也才會存在「有」。

在網路業中,當明確的商業目標和好的規格文件出現後才會有程式碼,但沒有程式碼也沒有辦法達成商業目標,這就是有無相生的體現。它鼓勵我們追求平衡與和諧,過分強調某一方面就像握緊的雙手,可能最後什麼都抓不到。

優化程式開發流程時,過度工程化可能會導致浪費,我們該關注實際商業需求並學習在追求效率和品質之間取得平衡。在生活中,則是放下無謂的擔憂與煩惱,追求快樂和內心的平靜。追求完美,但卻時常忘記了生活的美好。


斷捨離實戰:從祖產程式碼到全域搜尋

為什麼我們需要一種魔法,一種「斷捨離」的魔法?這在 軟體重構 中至關重要。斷捨離的過程中,最關鍵的判斷是:這些東西是不是真的需要?程式碼也是一樣,那些傳承的「祖產」是否該留著?

實踐步驟如下:

  1. 全域搜尋: 先確定原本到底有多少類似的情境。
  2. 定位與整理: 決定物品(或函數/元件)的定位,才會整齊且方便尋找。
  3. 無情刪除: 只留下真的有需要的,剩下通通刪掉。

有人可以說出什麼是無瑕的程式碼嗎? 對我來說那就是一行程式都沒有寫的程式碼,沒有寫 Code 也就不會有 Bug。


結語:為了更快下班而重構

在程式碼與生活中的斷捨離,讓我們學會不陷入無休止的深思熟慮,不被工作壓垮。我們追求 開發效率 的提升、維護混亂的減少、以及更好的生活品質。

這 30 天,我期許自己每天花三分鐘的時間練習斷捨離。目標是透過優良的架構、設計模式與重構的方法論,達到更高效率的開發體驗。掌握「簡化」的魔法,其實就是學會更快下班的方法,讓我們有更多時間去探索這個精彩的世界。


FAQ:KISS 原則常見問題

Q1:簡單 (Simple) 與 簡陋 (Easy) 有什麼不同?

A:簡單 是指結構清晰、邏輯透明,背後通常需要深度的思考來隱藏複雜度;而 簡陋 往往只是為了快而省略必要的判斷或錯誤處理。KISS 原則追求的是「智慧的簡化」,確保程式碼在精簡的同時依然健壯。

Q2:如何判斷我正在進行「過度工程化」?

A:觀察您是否在為「未來可能發生(但現在還沒發生)」的需求寫過多抽象化程式碼。例如,明明現在只有一個資料源,卻寫了五個介面與一個複雜的工廠模式。這就是違反 KISS 原則的警訊。

Q3:捨不得刪掉舊程式碼怎麼辦?

A:記住 Git 是您最好的後盾。只要您的版本管理習慣良好,所有的「刪除」都是可逆的。勇敢地全域搜尋並移除那些「預防萬一」留下的註解或無效函數,這能顯著降低接手開發者的理解負擔。



喜歡這篇文章,請幫忙拍拍手喔 🤣