今天回家的路上，竟然刮起了大风，虽然骑行艰难，但是想想公交中的闷热，倒是觉得凉爽多了。

在路上的时间是无聊的，于是就喜欢胡思乱想，很多自以为很棒的点子其实都是在这种不经意间想到的，办公室里的久坐反而显得效率低下了。回味一下最近做的几个项目，高屋建瓴的想想当初的设计，突然很想写一些关于软件设计的文章。就着饮料和巧克力（来点酒么？），今天就来写写软件极简主义吧。

Google了一圈，也没找到对“软件极简主义”的定义，姑且当做是我的独创吧。一般认为“极简主义”是设计界的一种风潮，但是软件发展至今，好像也渐渐有了这样的趋势，甚至我认为这是未来的必然，我们经常听人说“flexible”这个词，字面上来看就是“灵活的”，但是具体到这个软件是否灵活，就不太好判断了。但是，简单的软件，一定是灵活的。

极简主义的的大敌

软件极简主义的三个大敌：配置文件，冗余的参数，和大量复杂的接口。

很多人热爱配置，迷恋配置，认为越多的配置项意味着软件越强大，适用范围越广，但这是九十年代的事了。实际我们仔细翻翻常用的软件，90%的配置都是多余，没有人明白他是做什么的，也没有人希望去改变他。比方很多软件的configure文件，常常能列出上百个配置项，但是我们真的需要这么多吗？不，我们需要默认的那些值就行了。何谓默认？因为软件的设计者觉得这些是最优化也最有可能被选择的配置，那么既然是最优配置，我们又有什么理由去改变他们？

再说说冗余的参数，linux中有一个非常强大的命令’tar’，从man文件看来他起码有二十来个参数，但是我真的需要这么多参数吗？其实我只要记住压缩是-c，解压是-x就可以了，那么何必为了1%的功能而去加上这99%的参数呢。

最后是复杂的接口，举个栗子，全文搜索引擎solr非常强大，能满足我们对于文档索引的各种需求。但是他使用起来可不简单，原因我想就是因为他那种sql式的查询接口，把一件很单纯的事情搞复杂了。我们来设想一下，需要找出包含某几个关键词的文章，必要的条件是什么？关键词，文档，没了。而文档是存储在服务器的，为什么我们提供了关键词之后，仍需加上各种条件，他才能告诉我们想要的答案呢？我想软件发展到一定的智能，他就应该像一部能说话的百科全书，提问，然后告诉我们答案即可。

凡事都要对比着看，所以我们找点软件来对比一下。

redis 与 sql

redis很灵巧，所有源代码加起来不满5M，但是他很强大，hash结构能取代我们80%对于sql的需求。他也有配置文件，但是选项很少，而且每一项都有详尽的注释，并且使用默认配置就可以应对大部分的情况。唯一值得诟病的就是他的接口种类繁多，但好在这些接口很有规律可循，你只需了解了redis的基础数据结构，那么跟着官网的文档就很容易搞懂所有接口的用途，而且大部分的接口都只接受3个以内的参数，这可好记多了。我刚接触redis的时候，只花了半个小时就能玩得起来，我想面对sql恐怕没人能这么轻松的掌握吧。

cake 与 grunt

cake和grunt是nodejs中两个管理任务的模块，后者的名声更大一些，前者甚至不能说是一个模块，他只是coffeescript中附带的一个小工具。我曾尝试使用grunt来做任务管理，但是当我看到grunt官网那长长的一段initConfig时，就望而却步了。就像是我希望在墙里敲个钉子，你却给了我一台破城锤。我只不过想要给每个任务起个名字方便我以后调用和查阅而已，所以cake的一行命令足矣。

zmq 与 rabbitmq

zmq是我见过的最具有极简主义风格的软件（组件）。一方面他要面对的任务非常繁杂，在异步通信中所有我们可能遇到的情况，他都为我们考虑到了，但是他又将底层的复杂问题掩盖起来，让我们看到一个光滑的表面，深藏功与名。同样来看看他的同行rabbitmq，关键词：中心服务，多线程，模式单一，最后一个特点，慢！而仅有1.7M的zmq，快是最直观的感觉，而分布式和扩展性则是锦上添花。有人说zmq就像乐高积木，每个人都能搭出他想要的形状，这话一点都不错。

不是结束的结语

软件的设计日新月异，将来肯定会接触到更多优秀的软件，也许哪天我想法变了，也许哪天遇到了更神奇的方案，可能我会补充在这里。