　　如果大家認為這篇文章更多是在噴，我先說抱歉。“瑞士軍刀綜合癥”的想法是起源于我和項目經理、客戶、甚至其他開發者打交道的過程中產生的沮喪感，他們都以一種狹隘特殊的方式思考問題。我稱之為“瑞士軍刀綜合癥”。

　　瑞士軍刀

　　“瑞士軍刀”這個詞通常用于描述一種可以在各種情況下使用的多種工具的集合體。

　　雖然這樣的組合可能很有用，但同樣要注意一些風險。一個有太多活動部件的工具，可能最后是完全無用的！什么都能做的工具，就是什么都做不好的工具。

　　就我的經驗來看，同樣的問題也出現在軟件上。大多數時候，開發人員僅僅因為“這很酷！”就把一些功能或者一段代碼放進工程里；項目經理們會認為這樣或那樣的特性可以增加價值，并且在項目中期修改需求；消費者因為聽說或看到某個性能對他們“至關重要”而期望額外功能或特性。

　　這種“瑞士軍刀綜合癥”可以有很多形式：需求范圍的蔓延，過早的優化，等等。但是問題的根源在于，我們是如何理解并評判軟件、工作量及其附加價值的價值：

更多功能 = 更大價值

　　現實中，以及絕大多數情況，事實恰恰相反。一段代碼或者一個軟件越復雜，它提供的價值就越少。一個個人的例子就可以簡單說明這一概念，Demac Media內部使用的樞紐控制臺。

　　本來這個應用很簡單：我們需要一個（1）查看所有分配給小組的任務和（2）通過本周或兩周的底線來過濾任務——簡單來講，就是一個帶有過濾功能的任務整合器。

　　我用了一周時間，寫出了基本的功能。在下周周一時，我給我們團隊的項目經理展示的時候，他認為這個應用不錯，很有用。

“……但是，如果……，將會更不錯……”

　　于是瑞士軍刀綜合癥開始了：這個工具要和另一個團隊共同使用。在他們還沒有開始使用之前，我們就收到了一堆需要添加的新特性。突然間，我們有了很多遠超出這個應用最開始設計的需求。

　　明確目的

　　軟件應該是簡潔的，只提供它應該提供的功能。為了配合上面的軍刀，一段優秀的代碼，就應該像廚子的刀一樣。一個廚刀很簡潔，有特定的功能。一個專業大廚會在不同情況下用不同的刀。同樣的思維方式也應該應用到代碼中。

　　我們發現軟件設計中也有同樣的原則，通常叫做單一功能原則：

單一功能原則規定每個類都應該有一個單一的功能，并且該功能應該由這個類完全封裝起來。所有它的服務都應該嚴密的和該功能平行。

　　任何一個公司、項目經理、開發人員，或者是客戶都應當遵守這一邏輯。我們傾向于認為，擁有更多或者實現更多就等同于更好、更有價值。軟件應該是優雅的，優雅的代碼就是簡潔地完成需求的代碼。因此，我們開發人員有責任確保我們所寫的每段代碼都盡可能優雅簡潔。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。