手头的项目终于要GA了，从年初到现在用了接近一年的时间。而本来这个项目最初的预定才是3个月。

最大的感觉有几点。

采用第三方的商业库/工具是有很大风险的，有利有弊。好处是可以轻易的快速的实现很多功能，缩短了开发周期，坏处呢，就是如果这个第三方的support不利，那么将会大大降低开发效率，并且打击开发人员自信。

一直以来基本都是和oepnsource打交道，有什么不爽的地方hack一下，或者有bug就fix一下，然后就很快的过去了。也没感觉open source是多么的重要。这次真的彻底的体会了一把。那种在黑盒子里摸着乱闯的感觉。加上如果第三方的support跟不上，总是答非所问，或者非常不专业。更是会让开发人员抓狂。

无法看到code，意味着你得花大力气才能通过外表表现来猜测逻辑，无法看到code，意味着当出现问题的时候，你很难直接在问题所在处痛快解决而不得不采取一个又一个的workaround，无法看到code，意味着你总是会时时刻刻担心自己的程序，因为不知道会产生什么意外的行为。

open source之所以能像秋风扫落叶一般得到人们的共识就是因为消灭了以上的种种弊端。把code拿给你看，还有什么比看code更让程序员放心的事情呢。是吧，然后基于code在那里摆着，再接着买service赚钱。或者为客户做一些custom的工作。这才是好的商业模式，因为有code做基础，才能有上面的各种赚钱法门啊。

我相信随着oepn source的更加普及，闭源模式终究会灭亡的。至少在做middleware这个市场，闭源肯定要衰败的。

嗯，借用COSMO童鞋们的一句名言改变来就是：有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，以上是最近的一些思考，欢迎补充和不同意见。

男同学，请回答我。胸围与罩杯是一回事不？如果不是，区别是什么？是不是胸围越大，罩杯就一定也越大呢？

要是女同学，你就找个男同学问一下。

好吧，你有答案了吧。我猜八成的男人一般都不会太清楚这俩到底是不是一回事，区别在哪里。至少我认识相当一部分男人（包括曾经滴我自己）一直以为胸围有多长罩杯就有多大。

其实呐，根本8是这样子滴。就让百度告诉你。

胸围指人体胸部外圈的周长。

from http://baike.baidu.com/view/54963.htm

罩杯的尺寸则由其深度决定。乳房最高点的乳围（三围之一）减去乳房下围一圈的长度，AA 7.5cm A 10cm B 12.5cm C 15 cm D 17.5cm E 20 cm F 22.5cm G 25cm H 27.5cm I 30cm ，两种罩杯间的尺寸则以够长的背扣来解决。

from http://baike.baidu.com/view/426973.htm

由此可见，胸围和罩杯不是一回事，也并非胸围越大，罩杯也越大（相信很多小正太/宅男都有或有过这种错误滴认知）。两个是蛮有差别滴。而且根据这两个定义可以推理。罩杯比较大的女性的胸围肯定在某一个区间，胸围过大或者太小的女性一般来说更难达到C，D等高级CUP。这个推理如果有人不理解，自己慢慢琢磨哈。俺就不解释老。咔咔，或者实在琢磨不明白多多观察。

————————- 俺是坨华丽滴分割线 —————————

好了，啰啰嗦嗦的一大堆，这下不能算俺标题党了吧。开始进入正题，上面那一段主要是想表明，在日常生活中，往往有些概念大家很容易就认为是一致的或相似的，可真正仔细看一下，发现其实还有很大区别的。那么在程序中往往也有很多地方，总感觉是一样的东西，但其实表现来却不是一回事。据个例子吧。

今天hideto同学遇到的一个bug就是，DB中对于某个column的定义，约束这个varchar不能超过222个，而在Rails中与之对应的ActiveRecord对象也声明了这个validation，超过222个就报错。可经过实际测试，发现如果使用英文或数字的话，程序是没错的。如果夹杂了一些汉字，那么发现，还没到222个字符。Rails就报错了。但实际上，数据库是可以插入滴。

问题很简单，字符编码问题。DB中是用的utf-8。而Rails中，AR的那个validates_length_of 中的size没有考虑宽字符的情况。所以， 类似“我love你”.size 返回的就是8,而我们希望得到的是6.

问题很快查明了，自然就容易解决了。可是我突然之间觉得这个小地方还是挺值得玩味的。

自打工作以来一直做的java，而Java天生就是对Unicode支持的，所以在Java的世界，是没有这种情况的，我也一直没仔细思考过，直到遇到了ruby。ruby可不是天生unicode。所以在ruby中，一个中文字符的size就会是2.想得到1，那好吧，请require jcode. 并且调用jsize，而不是size。

只不过是因为字符集的问题，就需要不同的两套方法。在我看来，Matz身为日本人，本应该把这个问题考虑的更加完善一点滴。

和size一模一样的那个方法叫length。最一开始，我觉得真的好方便，ruby真滴好灵活诶。但日子久了，我开始觉得，其实这两个关键字是大有学问滴。只是，好像我接触的语言中并没有区分过两者之间的关系，都当成一样的了。我个人认为这其实很不合适。

size，应该是描述大小，也就重量（质量）的。比如一块蛋糕，比如一件T-shirt。

而length，是描述长度的，比如一条皮带……

所以，这两个其实是不一样的。而对于一个String类来说，这两个方法也应该具有不同的含义。也许你立刻想问一个问题：字符串也就有长度的信息，字符串能有什么重量（质量）啊。那么不好意思，你想当然的错了。YOU ARE WRONG, VERY WRONG!!~~~

字符串的重量，就是字符串在物理的寄存器中所占用的bit。这就是字符串的重量。

所以你看，如果能够把size和length的定义更加清楚一些那么也许就能够避免很多问题。

比如在ruby中，我们需要判断这个字符串的长度，那么就需要length这个方法。但也有时候，我们有个binary string，这时候我们并不会去care他的长度，因为没什么意义。我们这时候care的是这个字符串的大小，比如要大于0.5K，小于2M之类的。这时候就要用到size了。

也许有人认为如果照着我的建议，会使得代码概念混淆加重，但我觉得即便是如果出现这种事，那么肯定也是惯性使然，如果让一个没有程序经验的人直接告诉他size和length是不同的定义。我想他应该不会产生混淆的感觉。特别我越是动态的语言，基础库的特性一定要更加的把握好，力图更加精准，清晰。这样子，才能更友好的方便上层应用与扩展。

按照我刚才的定义，在unicode的语境中，两个方法返回的数字应该是保持一致的。但即便一致，我想如果一门语言能够分清楚和说清楚两者的不同含义，那么好处也是大大的。因为即便你以unicode来存储，即便目前每个字符都可以用一个unicode码来表示。难保将来不出现一门火星语，对吧。如果到时候unicode的16byte空间又无法描述一个火星文了，那么那会就又要混乱了。

所以，我衷心的期望在各种语言中，别再将size和length视为一个方法的两种表达方式。而是让他们各司其职，发挥各自应有的作用。

当然，这八成只能算奢望，好吧，那么就让我期望如果我这辈子要发明一门语言的话，一定要将size与length区别开来。

永远不能忘记 — ”胸围太大并一定值得庆幸喔，也许那胖妞滴CUP只有A“~~~~

好了，现就这样。其实这种类似的小地方，我觉得还是蛮好玩和值得讨论滴。比如我前阵子就曾在公司邮件中聊了把空字符串”与nil滴区别。这个嘛，也许将来会再写一篇。只不过得先想到一个闪亮滴标题才行喔。

PS：这年头，标题党不容易啊。

早上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语言没有一毛钱关系。完全就是看自个喜好，想怎么搞就怎么搞。在这上面没有绝对的真理。适合你的就是你的真理，但也就相对于你。