引用 軟件設計有兩種方法：一種是盡可能地簡單，這種設計明顯沒有什么缺陷；另一種是盡可能地復雜，這種設計沒有明顯的缺陷。
——C.A.R. Hoare，1980年圖靈獎講座
在開發過程中，我的口頭禪是： Your code may be elegant, by mine works。我為此而常常受到質疑，也有人反駁我“你不會使用最優方法！”“你在逃避測試！” 為了避免一次又一次地重復解釋，我決定闡述下我的觀點，仁者見仁，智者見智。

首先，我認為“項目可能會延期，但是代碼會更好或更容易維護或更簡潔”這句話是有問題的。項目延期，就是未完成，不應該用代碼質量會更高作為借口。如果客戶要在圣誕節進行推廣活動，但你在12月29號才完成項目，即使提供了史上最好的產品，也是毫無價值的。

其次，我們來談談“最優方法”這個問題，“最優”是否意味著要寫出更易于維護的代碼需要更長的時間呢？其實除了大家都知道的《101個最優方法》以外，“最優”的標準是各種各樣的。無論你對其進行怎樣的定義，“最優方法”對所有程序員來說，應該是一種自然的編程標準。舉個最簡單的例子，經驗豐富的程序員會自然地將變量命名為：$a、$b、 $c等，也能正確地縮進代碼行。說得再深入一點，有經驗的開發者知道在什么時候、如何提高效率以使得項目能如期完成。雖然 “最優方法”的標準有很多，但這些標準不會令你因此而延長項目時間。這引出我將談到的下一點——Over-engineering（過度設計，指設計出來的系統比恰到好處要復雜臃腫的多，過度的封裝、一堆繼承、接口和無用的方法，以及超復雜的xml配置文件）。

像任何經驗豐富的程序員一樣，我了解那種想為每個項目搭建最好、最靈活、最耐用的系統的心態。但我也了解每個項目都有的商業限制：時間和資金。大多數項目都有明確的截止日期和項目預算，開發者要有意識地去控制項目規模以按時達到目標。你沒有任何理由花一周時間，來為一個20行的table表上的數據庫查詢設置“恰當的”緩存層。多了解實用案例，如果只是為了實現一個頁面訪客計數器的功能而構建支持多種同時響應請求的XHR框架，是不現實的。要有眼界，這是我最強調的一點，最好的程序員不是精通如何構建最棒的系統的人，而是了解系統不需要的是哪些功能的人。

另外，在軟件開發領域，上市時間是商業驅動力，在web應用開發領域，由于其動態性，這點更為明顯。當時間成為關鍵，“最優方法”就是最簡單的解決方案。

最后，我們來討論一下技術債務（指為了匆忙實現一個功能，破壞了現有的程序庫，在實現的過程中污染了代碼庫的設計）。如果在開發過程中，你在某個地方偷工減料了，那么就會產生無法解決的長期存在的技術債務，而且在之后的開發中，任何一個決定，都會受該債務的影響。事實上，在接手商業項目時，明白何時、如何對代碼進行簡化的能力是很關鍵的，這也是區分老手和菜鳥的標準。解決技術債務的辦法有很多，但應盡量做到不產生技術債務。同樣地，過度設計也不可避免地會產生技術債務。

通常人們在談到技術債務的危險時，并沒有包含商業影響。但其實技術債務與實際投資回報率是相對的，因為在許多情況下，早日上市更具成本效益。也有種情況是技術債務與收益同時存在，那么你可以慢慢償還債務，但這會延長你的項目時間，很可能當你解決完技術債務時，你也失去了市場機會。

作為軟件開發者，我們常常認為自己的工作就是開發軟件，但其實這只是一種手段，我們的目的是令開發商達到他們的商業目標，你的代碼也許很優雅很簡潔，但如果不能達到目的，就絲毫沒有意義。

英文原文：Your Code May Be Elegant

總結

以上是生活随笔為你收集整理的你的代码可以是优雅的，但是还有更重要的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。