该帖子同步发自：(感度的博客  访问该博客)

　　瑞士军刀

　　“瑞士军刀”这个词通常用于描述一种可以在各种情况下使用的多种工具的集合体。

　　虽然这样的组合可能很有用，但同样要注意一些风险。一个有太多活动部件的工具，可能最后是完全无用的！什么都能做的工具，就是什么都做不好的工具。

　　就我的经验来看，同样的问题也出现在软件上。大多数时候，开发人员仅仅因为“这很酷！”就把一些功能或者一段代码放进工程里；项目经理们会认为这样或那样的特性可以增加价值，并且在项目中期修改需求；消费者因为听说或看到某个性能对他们“至关重要”而期望额外功能或特性。

　　这种“瑞士军刀综合症”可以有很多形式：需求范围的蔓延，过早的优化，等等。但是问题的根源在于，我们是如何理解并评判软件、工作量及其附加价值的价值：

更多功能 = 更大价值

　　现实中，以及绝大多数情况，事实恰恰相反。一段代码或者一个软件越复杂，它提供的价值就越少。一个个人的例子就可以简单说明这一概念，Demac Media内部使用的枢纽控制台。

　　本来这个应用很简单：我们需要一个（1）查看所有分配给小组的任务和（2）通过本周或两周的底线来过滤任务——简单来讲，就是一个带有过滤功能的任务整合器。

　　我用了一周时间，写出了基本的功能。在下周周一时，我给我们团队的项目经理展示的时候，他认为这个应用不错，很有用。

“……但是，如果……，将会更不错……”

　　于是瑞士军刀综合症开始了：这个工具要和另一个团队共同使用。在他们还没有开始使用之前，我们就收到了一堆需要添加的新特性。突然间，我们有了很多远超出这个应用最开始设计的需求。

　　明确目的

　　软件应该是简洁的，只提供它应该提供的功能。为了配合上面的军刀，一段优秀的代码，就应该像厨子的刀一样。一个厨刀很简洁，有特定的功能。一个专业大厨会在不同情况下用不同的刀。同样的思维方式也应该应用到代码中。

　　只做一件事，并做好它。

　　我们发现软件设计中也有同样的原则，通常叫做单一功能原则：

单一功能原则规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的服务都应该严密的和该功能平行。

　　总结

　　任何一个公司、项目经理、开发人员，或者是客户都应当遵守这一逻辑。我们倾向于认为，拥有更多或者实现更多就等同于更好、更有价值。软件应该是优雅的，优雅的代码就是简洁地完成需求的代码。因此，我们开发人员有责任确保我们所写的每段代码都尽可能优雅简洁。