請不要嘗試簡化這些程式碼

請不要嘗試簡化這些程式碼！

Kubernetes 是 Google 開源的一個容器編排引擎，它支援自動化部署、大規模可伸縮、應用容器化管理。Kubernetes  簡稱 K8s，用「8」替代 K 和 s 之間的 8 個字母「ubernete」。

K8s  的 pv_controller.go 原始碼大約 1700 行（含註釋），其中包括：230+ 個 if 陳述句、30 個 else 陳述句、5 個 else if 陳述句巢狀在一起。

https://github.com/kubernetes/kubernetes/blob/ec2e767e59395376fa191d7c56a74f53936b7653/pkg/controller/volume/persistentvolume/pv_controller.go#L323

乍一看，這程式碼違背了 KISS （Keep it simple, stupid）原則。

 但是，K8s 的工程師們在註釋中用大寫英文標註：「請不要嘗試簡化這些程式碼！」並且還寫了兩遍。

為啥強調兩遍？K8s 他們在註釋中特意解釋了。大意如下：

這個控制器故意以一種非常冗長的風格編寫。你會發現：

1、每個 if 陳述句都有一個匹配的 else 陳述句（檢查客戶端 API 呼叫的簡單錯誤除外）；

2、有很多被顯式地註釋的東西；

我們把這種風格叫做“太空梭風格”。太空梭的風格意味著，要確保每個分支和條件都得到考慮和說明。NASA 為太空梭等應用程式編寫的程式碼也是如此。

最初，這個控制器的工作被分成三個控制器。控制器是努力簡化 PV 子系統的成果。在此過程中，我們要確保在程式碼中處理和解釋了每一個條件，即使這會導致無 op 程式碼分支。

因此，控制器程式碼可能看起來過於冗長、註釋過多和“分支”。但是，這裡記錄了大量的業務知識和背景關係，以便確保未來的維護者能夠正確地推斷系結行為的複雜性。因此，對這個檔案的修改，應該保留並增加太空梭的風格。

程式員們的看法

12 月 8 日，這段特別的原始碼註釋在 Hacker News 上引發程式員們的熱議。「程式員的那些事」摘譯一些幾位國外程式員的評論：

Klathmon 的觀點：

我超喜歡！它就是軟體開發的「爵士樂」。雖然它打破所有的「規則」，但它目的明確，比遵循「規則」的結果還要做的好。

我第一眼看的時候，感覺頭都要炸了。原始碼檔案太大了，有太多的分支和巢狀的 if 陳述句，有很多隻是描述一行或幾行是做什麼的毫無意義的註釋。而且註釋中還有很多「邏輯」，相比實際程式碼，這些「邏輯」這可能很快過時或出錯。

然而！它們這種方式更利於維護和管理程式碼，不需要把「邏輯」部分拆分成數十或數百個檔案。它已包含了要在該檔案中做的大量固有的複雜工作，並且註釋寫的又好又詳細，所以確保了以後有任何改動，註釋都能輕鬆地隨之更新。

nickharr 的觀點：

在用多種程式語言編寫、檢視、註釋和評審程式碼方面，我有 25 年的經驗，拋開程式設計「風格」如何如何，這都是很值得一看的東西。

退一步說，雖然我們都可以忽略程式碼註釋，但是優秀的程式碼註釋可以極大地提高生產力——對個人、團隊乃至企業都是如此。註釋可以幫助儲存庫知識（這往往是當前和以前的團隊/個人之間很容易丟失的東西），不應該將其誤認為檢視程式碼的人的智慧……

我花了太多的時間，試圖對沒有註釋或解釋的程式碼進行反向工程。有時，經驗豐富的程式員/開發人員會走一些捷徑（經驗不足的開發者無法理解）。他們會根據自身的語言/領域知識，來壓縮程式和函式，但沒有解釋……

我認為，註釋應該：告知、教育、概括和幫助他人，來理解開發者在巨大壓力下時寫出的複雜程式或函式。

有些人認為，好的程式碼不需要解釋。這個觀點，在某種程度上是對的，但並不是放之四海而皆準。程式碼有時會變得複雜、笨拙、就像義大利麵條一樣，難以理解。

我一直在努力教經驗不足的開發者如何用幽默的方式（如果可能的話）寫良好、有效的註釋。它能讓我們快速理解程式碼，欣賞前人的努力，笑對複雜挑戰。

就我個人而言，我並不真正關心程式碼/註釋比率——這完全是在轉移人們的註意力。有時，程式碼註釋可能比程式碼本身更有價值。在其他時候，註釋只是幫助你完成工作。快速、高效、沒有問題，就是優秀的程式碼。

@memories_on：if必須加個對應的else有時非常有用 在你要改動邏輯判斷的組合時就更有用了

@PreciselyPrecious：與KISS剛好相反

@柳煙堆雪：這不是什麼程式碼風格，而是當時做pv controller時 edge case實在太多，為了讓後續開發者能明白怎麼回事所以要故意往囉嗦裡寫。kubernetes 專案開發者近兩千，這種作法和修飾其實能找到不少的。

@刻板的眼睛：《程式碼之美》中有看到，在一些情況下是可以放棄一些編碼規則的，只要好處夠多

@D2942D4EADA2C788C171BC53B3A68D：這類程式設計工作的核心應該是邏輯表達清晰且程式碼量盡可能少以減少犯錯機率。這恰恰是程式碼生成器最擅長的地方，除了固定的最佳化和表達規則，不會自作聰明對邏輯進行等效裁剪。可以預見領域語言會是這類領域絕對的霸主。