最近在调研一个product的API，Java版本的。毫无悬念的沿袭了Java框架大多数的通病，过度设计。

造成的结果就是API接口暴多，想完成一件小事就需要声明暴多的对象，调用暴多的参数。

所以在探讨如何调用的时候，我毫不犹豫的鼓吹采用JRuby来调用。因为如果用Java，总觉得人会情不自禁的掉入过度设计的陷阱。

继续思考，会感觉，语言本身的特性就会影响到设计的思路。比如Java Web框架那么多年也没出来个Rails Style的，而Ruby社区也没听说谁搞出个EJB类似的东西。

强类型的语言，存在的太多的约束。这些规则如果对于经验不足的程序员来说，是种保护。但是对于高水平的程序员，反而是种束缚。而我觉得程序员本来就都应该努力成为高水平的级别，那种写程序为了混饭的人压根就不应该有饭碗。

打完这段话我后悔了，因为我想到C/C++的fans一定会骂我，C/C++也是强类型的啊，但是就可以写的很灵活，并且高水平的C/C++程序员也很多，没听说谁觉得用C/++憋屈的慌。特别是牛逼的指针，用好了那叫一个帅。

所以问题到底在哪里呢？想象Java除了强类型还有哪些特点，噢。原来是OOP。是啊，Java里面一切都是对象。你想打印个hello world都得写个class，然后写个main方法。。。多傻啊

所以看来也许是严格的OOP造成了过度设计，造成了代码臃肿？

我想至少这话部分在理吧。毕竟一些特定场景是不适合OO的。特别是现在函数式语言的火爆让人嗅到一丝更清新的味道。是啊，我的地盘听我的，我就把函数当一等公民怎么了。我觉得舒服。或者我的业务就是流水，本来过程式语言就ok了。不需要加无所谓的对象，不需要处理对象和对象之间的关系，交互。

看看Java的框架吧，随便挑几个，都是大批大批的class，多到让人眼花缭乱的地步。可真正常用的就那么几个类。而且很多时候A类都是必须配合B类使用的。那么何必分成两个呢。

有人会说这叫解耦，可我想举个例子：如果生下来是连体婴，医生一定要想办法处理，如果本来就是个健康的小孩，医生还需要处理，卸他个胳膊腿么？

所以当大家都明白解耦的重要性时候，一定要回过头再看看不解耦的可行性。如果A类只跟B类交互，那么也许就要想想这个A类是否有单独存在的价值了。

所以我在某些时候特别反对Java，特别是Web开发。我做了3年的Java Web，2年的Rails开发。对比两种方式，感觉真的太强烈了。Java确实不够适合处理Web，所以最近几年基本没啥原生Java Web框架震撼登场了。反而Grails啊，Jruby on Rails啊等等滴开始发威。嗯，JVM毕竟是个好东西嘛，应该支持。至于Java，一些场景下还是选择个轻量级的更面对业务的语言吧。

过度设计其实我觉得有两个含义，一个是程序结构的设计过度了，一个是设计占用的时间过度了。两者有一定联系性，但我觉得还不是一码事。而且不管哪种，我都觉得是极大的浪费，脑力与实践都是宝贵的资源。我们应当学会珍惜，把刀用在刀刃上。说到底，最重要的还是实现业务，所以设计要追求简单，实用，要为业务服务。华而不实，好看不中用的玩意儿还是留给学院派自我吹捧玩吧。

回到话题最初，其实我觉得API的设计是最最需要谨防过度设计的地方了。因为一过度设计就容易暴露出过度的接口。而每增加一个接口肯定都回带来更多的维护成本。而API又是一个非常强调向下兼容的东西。所以反悔的余地很在很小。结论就是我觉得API千万不要过度设计，哪怕设计不足一点，只暴露粗粒度一点的接口。等确实需要了，再暴露更细粒度的接口，然后把粗粒度的接口用细粒度的接口组合起来实现。也比一开始就暴露一堆巨细无比但八成没用的接口要好很多。因为API的一个潜在意义就在于即便你觉得没人用也不许随便删滴，否则就不叫Interface了，而变成NoFace了^_^

呵呵，上一篇还强调设计，结果这么快又写了篇谨防过度设计。宁亚说我是不是可善变啊，嚎~~~

其实编程就是在走平衡木，你需要不断滴思考是往这边点，还是那边点。然后在不断地思考中得到进化，这样才能向前发展。因为如果你重心一直很平稳，停止了思考。那么你根本不可能迈出向前的步伐的。

刚才看自己的日志，看到上一篇中的第10条第一句。

开发人员应该多想多做

仔细琢磨了一下，觉得其实应该改为：

开发人员应该多想少做

其实并不是鼓励大伙偷懒，而且我觉得有时候真的少做比多做更能达到效果的。因为如果你向反方向奔跑，跑的越快只能加大你和终点的距离。

所以做事情前一定要多想，确实把需求理顺，架构设计合理了再去实现。而不要草率决定，草率编码。

因为编码也是一种成本，如果你为了一个不合理的需求盲目编码，只能制造垃圾。

而如果在没有合理架构的情况下草率编码，只能事倍功半，而代码最终也会变为垃圾。

所以，每写一行code的时候，务必问自己，这行code是不是必要的，是否非写不可，如果是，那么是否有更好的编写方式。

把思考融入在开发的每一个流程，从设计到实现到测试到维护。一定要不停的思考。

要做专业的工匠，不是专业的代码猴子……

一直想做点Mashup应用，但一直没下手。但脑子里确实经常寻思这个事儿来着。昨天晚上，又想到了一些。

现在很多流行的Mashup应用Adobe AIR来做。虽然AIR所用的技术基本都是web的技术。但归类来说依然是C/S应用。需要维护一个client。

而很多手机上的应用更是如此。所以需要一个client就总需要一些成本。而最难控制的就是升级了。

而Mashup的一个特点就是升级并不那么可控，譬如你做的一个twitter的client，这个client都是直接调用twitter的API的，某天twitter突然废弃了某API，你的client肯定就歇菜了。这样子用户体验肯定很不好。

所以，我觉得如果做Mashup的C/S应用，一定要build一层中间层。在自己的服务器上wrapper一下真正的那些个第三方服务的API，然后提供一套统一的API来供自己的client调用。这样子的好处就是。如果第三方服务API升级，导致兼容性问题的话。只需要在自己的服务器端把自己那套API的实现改一下。就可以完全避免client突然无法使用的问题。

嗯，总归跑在用户本地的native的application最好看，效率最高。所以我觉得Mashup应用也是C/S会比较好。但C/S的最大缺点就是更新与维护，在加上做Mashup，对第三方服务API升级是完全不可控的。所以总是很担心client突然失效的问题。昨天突然想到了build个中间层，其实问题就没了。思路很简单，我却一直没想到啊，罪过罪过。嗯，我打算给iPhone做个GTD的软件老。咔咔，思路已经比较明朗，就是对GTD的经验还不够多，需要进一步滴挖掘需求滴说-_##