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