英文原文：Your Code May Be Elegant，翻譯：iteye
設計軟體有兩種方法：一種是簡單到明顯沒有缺陷，另一種複雜到缺陷不那麼明顯。 —— 託尼·霍爾（1980年圖靈獎獲得者）
在開發過程中，我的口頭禪是： Your code may be elegant, by mine f**king works。（你的程式碼或許很漂亮，但我的程式碼能執行！）我為此而常常受到質疑，也有人反駁我“你不會使用最優方法！”“你在逃避測試！” 為了避免一次又一次地重複解釋，我決定闡述下我的觀點，仁者見仁，智者見智。
首先，我認為“專案可能會延期，但是程式碼會更好或更容易維護或更簡潔”這句話是有問題的。專案延期，就是未完成，不應該用程式碼質量會更高作為藉口。如果客戶要在聖誕節進行推廣活動，但你在 12 月 29 號才完成專案，即使提供了史上最好的產品，也是毫無價值的。
其次，我們來談談“最優方法”這個問題，“最優”是否意味著要寫出更易於維護的程式碼需要更長的時間呢？其實除了大家都知道的《101個最優方 法》以外，“最優”的標準是各種各樣的。無論你對其進行怎樣的定義，“最優方法”對所有程式設計師來說，應該是一種自然的程式設計標準。舉個最簡單的例子，經驗豐 富的程式設計師會自然地將變數命名為：$a、$b、 $c等，也能正確地縮排程式碼行。說得再深入一點，有經驗的開發者知道在什麼時候、如何提高效率以使得專案能如期完成。雖然 “最優方法”的標準有很多，但這些標準不會令你因此而延長專案時間。這引出我將談到的下一點——Over-engineering（過度設計，指設計出來 的系統比恰到好處要複雜臃腫的多，過度的封裝、一堆繼承、介面和無用的方法，以及超複雜的 xml 配置檔案）。
像任何經驗豐富的程式設計師一樣，我瞭解那種想為每個專案搭建最好、最靈活、最耐用的系統的心態。但我也瞭解每個專案都有的商業限制：時間和資金。 大多數專案都有明確的截止日期和專案預算，開發者要有意識地去控制專案規模以按時達到目標。你沒有任何理由花一週時間，來為一個 20 行的 table 表上的資料庫查詢設定“恰當的”快取層。多瞭解實用案例，如果只是為了實現一個頁面訪客計數器的功能而構建支援多種同時響應請求的 XHR 框架，是不現實的。要有眼界，這是我最強調的一點，最好的程式設計師不是精通如何構建最棒的系統的人，而是瞭解系統不需要的是哪些功能的人。
另外，在軟體開發領域，上市時間是商業驅動力，在 web 應用開發領域，由於其動態性，這點更為明顯。當時間成為關鍵，“最優方法”就是最簡單的解決方案。
最後，我們來討論一下技術債務（指為了匆忙實現一個功能，破壞了現有的程式庫，在實現的過程中汙染了程式碼庫的設計）。如果在開發過程中，你在某 個地方偷工減料了，那麼就會產生無法解決的長期存在的技術債務，而且在之後的開發中，任何一個決定，都會受該債務的影響。事實上，在接手商業專案時，明白 何時、如何對程式碼進行簡化的能力是很關鍵的，這也是區分老手和菜鳥的標準。解決技術債務的辦法有很多，但應儘量做到不產生技術債務。同樣地，過度設計也不 可避免地會產生技術債務。
通常人們在談到技術債務的危險時，並沒有包含商業影響。但其實技術債務與實際投資回報率是相對的，因為在許多情況下，早日上市更具成本效益。也 有種情況是技術債務與收益同時存在，那麼你可以慢慢償還債務，但這會延長你的專案時間，很可能當你解決完技術債務時，你也失去了市場機會。
作為軟體開發人員，我們常常認為自己的工作就是開發軟體，但其實這只是一種手段，我們的目的是令開發商達到他們的商業目標，你的程式碼也許很優雅很簡潔，但如果不能達到目的，就絲毫沒有意義。
