最近在公司同时带了好几个项目，在开发过程中总会遇到不同的需求然后不断的修改，最后回过头来对比最初的项目设计发现一个很小的项目最后竟然变得如此之复杂，冗余的API和大量复杂的接口。
而这一切就是为了满足不同的客户需求，降低客户的使用成本。但是这样的设计最终会是一个软件面临死亡（复杂过度以至于在重构的代码大大增加）。
反思自己所带的项目内容和开发现状，我想到了一个词－－－软件的极简主义
软件的极简主义，虽然目前没有明确的定义，就当作是我的瞎想吧。
一般认为“极简主义”是设计界的一种风潮，但是软件发展至今，好像也渐渐有了这样的趋势，甚至我认为这是未来的必然，我们经常听人说“flexible”这个词，字面上来看就是“灵活的”，但是具体到这个软件是否灵活，就不太好判断了。
但是，简单的软件，一定是灵活的。
极简主义的的大敌
软件极简主义的三个大敌：配置文件，冗余的参数，和大量复杂的接口。
很多人热爱配置，迷恋配置，认为越多的配置项意味着软件越强大，适用范围越广，但这是九十年代的事了。实际我们仔细翻翻常用的软件，90%的配置都是多余，没有人明白他是做什么的，也没有人希望去改变他。比方很多软件的configure文件，常常能列出上百个配置项，但是我们真的需要这么多吗？不，我们需要默认的那些值就行了。何谓默认？因为软件的设计者觉得这些是最优化也最有可能被选择的配置，那么既然是最优配置，我们又有什么理由去改变他们？
再说说冗余的参数，linux中有一个非常强大的命令’tar’，从man文件看来他起码有二十来个参数，但是我真的需要这么多参数吗？其实我只要记住压缩是-c，解压是-x就可以了，那么何必为了1%的功能而去加上这99%的参数呢。
最后是复杂的接口，举个栗子，全文搜索引擎solr非常强大，能满足我们对于文档索引的各种需求。但是他使用起来可不简单，原因我想就是因为他那种sql式的查询接口，把一件很单纯的事情搞复杂了。我们来设想一下，需要找出包含某几个关键词的文章，必要的条件是什么？关键词，文档，没了。而文档是存储在服务器的，为什么我们提供了关键词之后，仍需加上各种条件，他才能告诉我们想要的答案呢？我想软件发展到一定的智能，他就应该像一部能说话的百科全书，提问，然后告诉我们答案即可。
凡事都要对比着看，所以我们找点软件来对比一下。
redis 与 sql
redis很灵巧，所有源代码加起来不满5M，但是他很强大，hash结构能取代我们80%对于sql的需求。他也有配置文件，但是选项很少，而且每一项都有详尽的注释，并且使用默认配置就可以应对大部分的情况。唯一值得诟病的就是他的接口种类繁多，但好在这些接口很有规律可循，你只需了解了redis的基础数据结构，那么跟着官网的文档就很容易搞懂所有接口的用途，而且大部分的接口都只接受3个以内的参数，这可好记多了。我刚接触redis的时候，只花了半个小时就能玩得起来，我想面对sql恐怕没人能这么轻松的掌握吧。
zmq 与 rabbitmq
zmq是我见过的最具有极简主义风格的软件（组件）。一方面他要面对的任务非常繁杂，在异步通信中所有我们可能遇到的情况，他都为我们考虑到了，但是他又将底层的复杂问题掩盖起来，让我们看到一个光滑的表面，深藏功与名。同样来看看他的同行rabbitmq，关键词：中心服务，多线程，模式单一，最后一个特点，慢！而仅有1.7M的zmq，快是最直观的感觉，而分布式和扩展性则是锦上添花。有人说zmq就像乐高积木，每个人都能搭出他想要的形状，这话一点都不错。
结语
软件的设计日新月异，将来肯定会接触到更多优秀的软件，也许哪天我想法变了，也许哪天遇到了更神奇的方案，可能我会补充在这里。