英文原文：Swiss Army Knife Syndrome
如果大家認爲這篇文章更多是在噴，我先說抱歉。“瑞士軍刀綜合症”的想法是起源於我和項目經理、客戶、甚至其他開發者打交道的過程中產生的沮喪感，他們都以一種狹隘特殊的方式思考問題。我稱之爲“瑞士軍刀綜合症”。
瑞士軍刀
“瑞士軍刀”這個詞通常用於描述一種可以在各種情況下使用的多種工具的集合體。
雖然這樣的組合可能很有用，但同樣要注意一些風險。一個有太多活動部件的工具，可能最後是完全無用的！什麼都能做的工具，就是什麼都做不好的工具。
就我的經驗來看，同樣的問題也出現在軟件上。大多數時候，開發人員僅僅因爲“這很酷！”就把一些功能或者一段代碼放進工程裏；項目經理們會認爲這樣或那樣的特性可以增加價值，並且在項目中期修改需求；消費者因爲聽說或看到某個性能對他們“至關重要”而期望額外功能或特性。
這種“瑞士軍刀綜合症”可以有很多形式：需求範圍的蔓延，過早的優化，等等。但是問題的根源在於，我們是如何理解並評判軟件、工作量及其附加價值的價值：
更多功能 = 更大價值
現實中，以及絕大多數情況，事實恰恰相反。一段代碼或者一個軟件越複雜，它提供的價值就越少。一個個人的例子就可以簡單說明這一概念，Demac Media內部使用的樞紐控制檯。
本來這個應用很簡單：我們需要一個（1）查看所有分配給小組的任務和（2）通過本週或兩週的底線來過濾任務——簡單來講，就是一個帶有過濾功能的任務整合器。
我用了一週時間，寫出了基本的功能。在下週週一時，我給我們團隊的項目經理展示的時候，他認爲這個應用不錯，很有用。
“……但是，如果……，將會更不錯……”
於是瑞士軍刀綜合症開始了：這個工具要和另一個團隊共同使用。在他們還沒有開始使用之前，我們就收到了一堆需要添加的新特性。突然間，我們有了很多遠超出這個應用最開始設計的需求。
明確目的
軟件應該是簡潔的，只提供它應該提供的功能。爲了配合上面的軍刀，一段優秀的代碼，就應該像廚子的刀一樣。一個廚刀很簡潔，有特定的功能。一個專業大廚會在不同情況下用不同的刀。同樣的思維方式也應該應用到代碼中。
只做一件事，並做好它。
我們發現軟件設計中也有同樣的原則，通常叫做單一功能原則：
單一功能原則規定每個類都應該有一個單一的功能，並且該功能應該由這個類完全封裝起來。所有它的服務都應該嚴密的和該功能平行。
總結
任何一個公司、項目經理、開發人員，或者是客戶都應當遵守這一邏輯。我們傾向於認爲，擁有更多或者實現更多就等同於更好、更有價值。軟件應該是優雅的，優雅的代碼就是簡潔地完成需求的代碼。因此，我們開發人員有責任確保我們所寫的每段代碼都儘可能優雅簡潔。