有code有世界，没code没一切

最近在调研一个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是不是必要的，是否非写不可，如果是，那么是否有更好的编写方式。
把思考融入在开发的每一个流程，从设计到实现到测试到维护。一定要不停的思考。
要做专业的工匠，不是专业的代码猴子……

1，选择适当的技术与工具。
2，在是否适当这个标准，有很重要的一项就是当前的团队成员是否都比较了解熟悉。如果不是，那就要小心了。
3，另外一项评判标准就是让将来真正需要用他的一些人员去决策，而不只是不相干的人轻率决定。
4，如果实在没办法，需求导致必须用新的领域的技术与工具来解决问题。那么技术调研非常重要。
5，技术调研的时候一定要把需求可能需要的功能尽量的都想到，然后探讨，并做出结论。这点无论做多少都不为过，因为最后总要你想不到的绊脚石。
6，派去技术调研的同事必须应该始终在这个团队工作并充当探路先锋的角色，不应该随便脱离团队。
7，新的工具与技术总会带来更多的未知与不确定性，所以做计划的时候，应该理性的清楚这点，不要不切实际的幻想，盲目追求速度。
8，在使用的第三方工具，得不到源代码，文档也不够详尽的时候。领导应该理解开发人员的苦衷，并积极应对，而不是责备。因为巧妇难为无米之炊。
9，领导者要有勇气去决策，带领团队良性发展。当犯错的时候应该坦诚面对。
10，开发人员应该多想多做，对于合理的需求并且容易实现的要做好，对于合理的需求但很难实现的要尽力，对于不合理的需求但容易实现的要讲明，对于不合理的需求并且很难实现的—必须要坚持自己的意见。一定要说服别人或者让别人说服自己。切莫听天由命，摆出不在乎的样子，否则害人害己。
11，总之，要用心，要真诚。迷茫的时候要先思考这对项目是好是坏，答案就很容易出来了。
12，团队合作，就想一把筷子，攥成一把才会更加坚韧，零星的散落布局，只会被各个击破，最后每个人都焦头烂额。所以，交流很重要。teamwork，应该有兄弟的感觉，荣辱与共的范儿。
13，以上是最近的一些思考，欢迎补充和不同意见。

老婆去香港，我在北京。
老婆去泰国，我在北京。
老婆去日本，我在北京。
老婆去意大利，我在北京。
老婆去瑞典、巴黎，我在北京。
老婆又去匈牙利了，我TM还在北京。。。
我太爱国，爱首都了。。。想起来自己都热泪盈眶。这次公司产品上线后，弄完新房后，我一定要旅次游！！！~~~~~ 呜呜，我不要总在北京了。

早上6点钟睡不着，起来开始发呆。
看看JIRA上面还有一个ticket，而一会早上还有例会，产品的最新版也马上要release。无形的压力让我很不爽。
其实本来这个ticket昨天可以做完的，但我觉得最近干的活有点糙，所以希望能至少在代码层改进下，所以昨天又思考了下没做。
其实软件开发，总是这样子，在需求的迭代和变更中，开发人员慢慢迷失了自己，导致的后果就是代码越来越ugly，越来越不和谐。而被大多数人鼓吹的Agile与重构其实也并不是银弹。造成代码丑陋的问题也与Agile和重构没太大关系，最主要的还是需求变更导致早期为原来需求设计的架构不适应新的需求。而往往时间又仓促，结果造成代码拧巴。真的就是这样，别提什么方法论。那都是扯淡的，时间摆着，需求变化在那摆着，你丫再拥抱也就那样子，本质上依然有着矛盾，这就是个无解的本质问题。
从业这几年遇见的信仰问题太多了，至今还总能碰上纠结于是用LINUX还是WIN的人，并且总有一票没头脑鼓吹用Lin比Windows爽，这尼玛有意义么？操作系统的选择是提高生产力的，跟别的没啥关系，而像Agile，REST这些buzzword是为了提高高质量代码生产率。 这些都是过程，流程，都是为了最终的目的服务的。而就有很多人在寻求真理的过程中迷失了，忘记了自己最终的目的，而纠结于形式，于是有了WIN/LIN之争，有了JAVA VS C#， JAVA VS RAILS, VIM VS EMACS这种脑残对比。
我曾经也迷失过，醒过来劲发现傻逼后，就开始苦口婆心的劝着很多人，最后发现效果很差。即便有人回过劲了也基本是自个悟出来的，不是我点醒的。搞得现在人也淡薄了，他傻随他傻去吧。总有开窍那一天。
阿门，上帝保佑吃饱了饭不饿的人们。
程序员就是要写出有价值的代码，你在公司就是写对公司有用的代码，在家就是写让自个舒坦的代码。这跟特定一定要有XX操作系统，XX IDE，XX语言没有一毛钱关系。完全就是看自个喜好，想怎么搞就怎么搞。在这上面没有绝对的真理。适合你的就是你的真理，但也就相对于你。