软件思考

最近在调研一个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了^_^

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

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