He's Pirate.
2009年三月
胸围与罩杯
三 31st
男同学，请回答我。胸围与罩杯是一回事不？如果不是，区别是什么？是不是胸围越大，罩杯就一定也越大呢？
要是女同学，你就找个男同学问一下。
好吧，你有答案了吧。我猜八成的男人一般都不会太清楚这俩到底是不是一回事，区别在哪里。至少我认识相当一部分男人（包括曾经滴我自己）一直以为胸围有多长罩杯就有多大。
其实呐，根本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：这年头，标题党不容易啊。
关于强迫症滴碎碎念
三 29th
刚从Google Reader中看到了Kevin最新的日志（链接），发现Kevin又被强迫症所害。想起自己一年多前，也是被强迫症搞得心力疲惫。所以很想写点什么。
那应该是07年年底的时候，我加入FreeWheel有了个3个月左右的时间。上班没多久，我就开始负责构建系统中报表部分的展现模块。因为是start-up，因为是从头开始构建一个新的系统。对于我来说，很是兴奋，很想大干一场。可现实总是出现不如意滴，比如兄弟团队符合给我提供数据的同事那边经常需要调整数据库schema，调整查询方式，然后还是有PM这边断断续续提出来的需求。慢慢的，自个身上的锐气就变成了怨气。因为总是出现很多新的变化，使得我最初所设计的小框架无法轻易支持或者说扩展。后果就是代码结构越来越混乱，伴随着的就是代码质量的下降。那会尝尝对着IDE发呆，因为不知道明天有会产生怎样的变动。过了元旦，系统上线了。各方面开始慢慢稳定下来，我窃喜以为终于有个机会可以好好收拾自己的代码了。于是我又怀着极大滴热情开始着手重构的事宜。我心想，前阵子各种对于理清代码结构或者提升架构的点子终于可以好好发挥了。结果进行了一两个礼拜，中间换了好几种思路，都觉得没有一个最perfect的状态，总有各种不满，然后导致我严重怀疑自己。于是在JavaEye上发了个帖子发泄了下（链接）。
强迫症的状态是越来越明显，我开始每天的失眠，每天的不停的在IDE里面敲code，实现我的新想法，然后最后又开始自我否定，全部删掉。坦白讲，那会有点崩溃的。因为本来觉得代码烂是别人的问题，比如需求变动，接口变动。结果等到各方面都稳定的时候，发现我还是不能写出让自己觉得舒坦的code。所以一下子就怀疑自己了。我那会不停的买书，翻书，各种讲设计，讲模式，讲重构的，我挨个的从中寻找我的解药，可惜最后还是无解。知道有一天在SMN上和robbin以及gigix的聊天使我一下来醒过来了。
robbin告诉我，代码分什么好坏，然后拿着JavaEye举例子，说如果现在给我看JE的源码也许我照样觉得很丑陋。但是就是这份也许很多程序员觉得很垃圾的代码，却支撑起了一个业界专业的一个网站，让很多人在上面交流技术，经验。这就是那份代码的价值，即便也许会有人觉得他很丑，但是他的价值是巨大的。
robbin的话一针见血，让我一下子就翻过劲儿来了。而gigix说的则是更好。嗯，其实他没怎么说我应该如何解决我的困惑。只是把他和他同事曾经的一段聊天记录发给了我看看。记录里，他们在讨论代码的价值，某位高人是这么讲，代码的价值是通过客户来实现的，如果你的项目使得客户获得了更大的收益，那么你这个项目的代码就是有价值的。而做不到这一点，你代码写的在天花乱坠其实也没什么用处。譬如重构，如果重构是为了减轻客户维护的成本，或者减轻系统某方面的开销，那么做这个重构就是有价值，如果重构只是为了程序员自己心里是否舒坦，那么这个是没什么意义的。至少浪费客户的时间与金钱。
gigix和他同事都是做咨询滴，所以看待问题就是看代码对于客户是否能产生商业价值。而对于自己公司的产品，我想更是应该这么要求。
强迫症很快好了起来，我不再每天对着IDE纠结。而是不停以是否为公司代码的商业价值去编码，去重构，去设计。我再也不只考虑自个是否舒服了。因为只考虑自个看着是否舒服不符合公司的利益。如果只为满足自己的喜好，那下班回家做opensource去，在公司为公司写的代码，衡量他的唯一标准就是以公司的利益。无他……
再往后，顺带着自己又多了些变化，特别是和同事争论或者讨论的时候，我只留心对于公司是否有好处的东西，如果你只是说因为某某书上说要这样那样，而要求我这样那样，对不起，我没兴趣。而如果你告诉我，你是从公司利益角度出发，来思考，觉得某些地方应该有change之类的，那么我会非常乐意倾听与讨论。
至此，关于代码的强迫症在我身上已经完全不存在了，直到今天，我依然每天都是以比较良好的心态去写着代码，改着代码。再也没有怀疑过自己。当然，我还是尽量把代码写的让自己舒服的，但是如果某些原因导致我怎么也没办法写出让自己看着特爽的代码，我也不会睡不好。因为我知道，如果某些地方实在复杂，那么就很难找到完美的状态。而抱着实用的心态去解决问题，才能产生最大的价值。
回忆到此结束。随着我对于代码的心结揭开，其他强迫症迹象也都纷纷好转。终于又过上的幸福快乐滴生活。哈哈。。。当然，这段经历对我来说，实在影响很大，我后来也对强迫症这种行为产生的兴趣，并且思考很多。下面是一些碎碎念。
我觉得强迫症一般都会发生在完美主义的人身上，因为只有一个人特别要求完美，才会对不够完美的地方玩命的思考，玩命的拧巴。如果说是一个大大咧咧的人，他很难对一项事物具有太大的执着。
所以像天天强迫自己每天要看多少书，写多少code的人来说，他肯定是希望他的编码技艺是最好的，是不会犯错滴。
一天洗手20次的人，肯定是对自己有强烈的洁癖，从不想让手有不干净的细菌。
总之，他强迫症所在的地方，就是他潜意识里最希望自己在那方面完美的地方。
而解决办法，其实就是很简单的，从另外的角度思考问题，也许每天只是强迫看过多书与编过多的code，并不一定能真正得到非常大的提高。反而是自己丧失了灵性。而每天洗手太多，也许并不能把手洗的更干净，反而造成脱皮等等更不好的情况发生。
这是第一点，先认识到强迫症所在并不一定有助于解决自己想变得完美的那个方面，然后再想想如何真正的去改善。比如也许更多的和高手切磋会更加显著的提高编码技艺，比如我如果勤剪指甲会使得手自然携带细菌数量就会减少。
当然，方向很重要，比如我当初就是方向错误，只顾着自己的审美观，而没去考虑代码真正的商业价值。所以还有一点就是一定要认识到自己强迫症的目标是否是一个伪命题。如果是那么立刻收手啦。人生短暂，应该把时光浪费在美好滴事物上滴。
嗯，俺滴碎碎念说完了，review了一遍，感觉也许都没说到点，不过也无所谓啦，强迫症本来就是一种自我拧巴的过程，自我累的时候，大脑自然就会出来调停，告诉你，要休息了，不要内战啦。
最后祝福Kevin速度摆脱强迫症滴干扰:D
说说项目中文档的那点事
三 12th
我觉得这篇写不长，因为其实关于文档的一些理念基本都是那种说着很简单，做着很难的。
文档多了好？
记得以前看CMM的时候，很强调文档的重要性。这是为什么咧？因为CMM是典型的软件工程理论嘛，而软件工程怎么来的咧？就是从建筑工程学来滴嘛。君不见，黄河之水天上来盖栋房子得有多少文档啊，来描述这个建筑的架构，每个房间的布局。这啊哪的，反正肯定很多就是了。都是设计师仔仔细细设计规划好弄好了，然后由俺们最可耐滴农民工一砖一瓦的，蹭蹭的，一栋building就出来了。所以CMM挺强调文档滴，整个软件周期，都要有这文档那文档的，堆积如山的。而实际效果呢？用猜的也知道肯定不怎么好了，不然现在人都表当自个Agile，而不说自个CMM了呢。
好吧，那你说这是为什么呢？我来告诉你。如果你建个大楼，建完之后你会没事拆着玩么？比如把18~20楼拆了，换个盖法。或者把楼里的钢筋全换一遍，换个回扣给的工作的牌子。你不会吧。所以你盖好之后，你那份文档描述的就是你的building，所以可以从下水道偷偷溜到你楼顶。所以这份文档是即使的反映了这个building的结构与状态的。
反过来，看软件开发。你能保证你写完之后的code有几天不被改？重写，重构，bug fix，需求变更。这些常见的活哪个不是要你改code。而你弄了那么多的文档，最后发现和code完全不一致了，那你说这效果能好么。文档说CLASS A是干这事的。结果一看code发现CLASS A根本就不是干那事的。当然，也可能你根本已经找不到CLASS A这么一个玩意儿了。
所以说文档足够多并不一定好，因为软件开发中，变化是从头到尾的。所以如果文档的变化跟不上项目的变化，太多的过时信息。最终非但不能帮助项目，却还会拖后腿，造成更多的怀疑，浪费经历。
少就是多？
爱扯Agile的肯定都说过这么一句话：代码即文档。
嗯，如果我没记错，好像这句应该是敏捷宣言中的？（刚查了下，原话和我记性不太一样，原话是：Working software over comprehensive documentation.）就是说如果你的代码写的足够好，本身就足够说明很多问题（比如通过起带有意义名字的变量，比如使用元数据编程，比如加恰当的注释）。那么就不需要和外在另外一个地方写场面大论来描述代码是怎么回事。
其实这方面我觉得很有代表性的就是javadoc和Xdoclet。javadoc也影响了很多后来的框架和语言啊。因为做的确实不错。通过在注视中加入一些符号，可以自动通过程序来抽象出注释，组成有意义的文档。这是多么automatic的事情。而且特别是你的注释和你的code在一起，就减少了很多两遍对不上，描述过时这类的事情。Xdoclet当然也是关于这方面的一个工具吧。
嗯，还有元数据以及DSL这种编程方式也在很大程度上为代码可读性做出了优秀的贡献。
比如Rails中，在Model之间声明关系用的belongs_to, has_many之类的关键字（当然，其实他们不算关键字，也是方法，只是表现形式cool了些）。是多么的简洁，有力，聪明，异动啊。
所以我基本上很赞成，因为大科学家爱因斯坦都说简洁性就是一种美。因为俺觉得懒惰的程序员才是好程序员。如果代码就够清楚的，或者通过代码就能生成出来很清楚的文档，那么鬼才写文档。当然，其实这观点是偏激的。因为我们确实需要文档。因为代码只能从微观角度看问题，即便你给我一个SDK文档，我还是很难看出你当初都是为什么这么设计，那么构造之类的。So，我们依然需要文档。但是要强调一定，我们需要的是高质量的文档，正确的文档。因为Diane说过：方向很重要（嗯，某次开大会说滴，很富哲理啊）。文档都是错了，就算你看个三天三夜，你也只能越看越错下去。所以，文档只有在正确的时候，才具有很大的重要性。如果只是过时的玩意儿，那么不如放到回收站吧。
The End
到现在，观念应该清楚了，文档其实还是需要的，但是我们如何去写文档呢？怎么使得文档是正确，有重大价值的呢？
嗯，我又发明了一个小所写KISSS原则。全称是：Keep it simple, stupid and synchoronous with your project. 嗯，别小看后半句噢，其实是一件非常难滴事情呢。因为锻炼你的写作技巧，尽量使得文档简洁又易懂，也许需要一些时间的锻炼，都能达到。但是synchoronous with your project需要的可是你长期的坚持啊。如果你的项目中某方面的改变牵扯到一些文档，会造成一些文档的过时，那么不要犹豫，立即更新它吧。真的不骗你，bad document的味道不比代码中bad smile造成的伤害小多少。
好吧，最后的结论就是，尽量写具备自描述能力的代码。如果某些时候，必须要写文档才能解决问题的时候，记得随时更新它。使它和你的项目保持同步。
随便聊聊-结对编程的三点看法
三 5th
眼睛一睁一闭，一天就过去了，嚎~~~~
嗯呐，一不小心，就又是好几天没更新blog。时间真的过的太快了。今天开了一上午的会，大伙聊了很多东西，搞的人比较high，这会离下班还有半个小时。任务也提前完成了。所以拿来写篇BLOG吧。
今天呢，就是同事给我们讲了一些Pair Programing的一些东西，算是Agile的一部分吧。当然，像我这种一贯喜欢否定的人总还是会提出很多自己的看法，毕竟，独立的思想与完整的人格我觉得是必须坚持滴。哇咔咔
好吧，不自夸了。今天要说的三点究竟是哪三点呢。请看大屏幕下面继续。
一，Pair Programing不一定就提高生产效率以及代码质量。记得我第一次看完《人月神话》之后，就坚信了一个观点：没有银弹。任何方法论或者所谓的最佳实践都有其自身的局限性，所以你要是给我说一个东西怎么都好，我直接心里就否定了。没有怎么都好的东西，包括现在这么hot，甚至都快过气的Agile这个big buzz word，当然也就有PP这个子集了。因为想起这些我就想起了CMM在很多年前的样子。诚然，Agile是有很多不错的理念，但千万要记得，没有银弹。PP也不可能面面俱到的。比如，性格不合的两个人去PP，互相谁也说服不了谁，结果一个变量的命名究竟是叫love_you还是LoveYou就争执了一上午，导致啥都没干。我主观不认为这会提高任何效率与质量。同样，俩人如果关系特好，互相默契很高，但如果很不专业，在一块躲在角落里偷偷的看《Prison Break》，然后每个小时看一集，再用剩下的不到20分钟时间里随便堆砌点垃圾去提交。这也是敷衍了事滴。再比如，如果你的上级给你们小组4个人每个人分了30个ticket。要求2天做完。这种根本是Mission Impossible的事情。你说这4个人会有心情PP么，会有心情考虑如何帮对方把代码写的优雅，把逻辑写的清楚不？反正我不信。还有，如果说我今天只不过是要修改一些页面上的typo或者是小样式，如果叫个人跟我Pair，他80%的时间里肯定觉得非常无聊。你觉得呢？上面举了好几坨例，有时候两个人会把事情搞的更糟，有的时候虽然不会搞的更糟，但是也会造成效率的浪费。想想Yahoo的衰败以及SINA的收购，过分的民主或者过分的股权分散，其实都是很不好的事情，会浪费很多机会，也会浪费很多时间去扯皮。在PP这里呢，就是PP不能确保提高效率以及质量。
二，一切方法论，包括Pair Programing其实最重要的因素都是人。嗯，确实是这样，从我上面举的例子应该看出来基本都是人造成的PP好用或不好用。其实这基本等于废话，计算机来说1+1等于2那就是定了。人喝多了那他可什么答案都敢说。人本身充满着不确定性，所以，把一切问题都归结到人肯定是放之四海而皆准的废话。可我还是喜欢强调这个，就是因为我发现虽然大家都知道人是问题的根源，但大家却不一定能重视这个认知。我把这个现象叫做‘认知回避’，是啊，谁没事愿意觉得自己这个物种是很不完善的呢。需要改进的呢。但回避也没用，反而后果更大。早点正视这个问题，正视你我包括所有人都有优缺点，都有不完善的地方，都会犯错误这个神一般存在滴事实，是很有益处的。只有你清楚的知道你的优缺点，你才知道如何去改掉缺点，或者如何避免你的缺点所造成的负面影响。好吧，说远了，回到PP，PP其实好处也是一大堆呢，具体的就google吧。可是如果想使PP发挥到如同那些大牛所说的魔力或威力的话，有一个很重要的条件，就是实施PP的人（之所以不说是第一重要的条件是因为第一条件肯定是得有台电脑-_-###）。你想想大牛说的那些魔力威力来自于PP，其实很大一部分也来自于那些人本身。因为他们本身就足够优秀，所以如果配上合适，科学的方法的话。那肯定做出来的成绩就更加的优秀了。所以，你如果想用PP也能收到同样的效果，那有很重要的一点就是除了按照大牛告诉你的最佳实践来实施PP本身，还一定要努力让自己向大牛看齐。包括你的人品，素质，性格，看待问题的角度，理解能力，沟通能力等等。这就好比乘法：PP比如说是5，如果你是2，那么得到的结果就是10，如果你是-2，那么得到的结果就是-10了。现在想明白了吧，PP重要的其实是你自身，流程啊，方法论，书上的探讨了，但是大部分PP的资料都不会讲关于提高你自身的方法，所以，速度补上这块短板吧。不然即便PP再好，你是个-2，那也没辙。
三，客观点，科学点。嗯，今天其实听同事讲PP这个topic，真的是听起来很美，但是最让我感到忐忑的就是没有数据。虽然developers都积极的表明PP提高了很多代码质量，可是从QA的角度就是还没有个数据。我觉得其实数据很重要。否则，空对空，很容易使大伙回到几十年前“赶英超美”那个疯狂的年代。所以，务实点，尽量脱离主观感觉，通过客观的数据来证明一件事物的属性，或者一件事情的好坏，或者一套方法论的可用性。这才是科学的态度啊。所以，我在会上也提了，希望可以量化PP带来的好处。看看PP对于我们的实际帮助到底是怎样的？不能莽撞认为我实施了PP，那PP资料里面所描述的那些个好处，我自然就得到了（想象曾经的EJB，真正让你得到了多少好处呢？）。科学的态度不是这样的，因为不要忘记了，想要发挥PP最大威力，你还得是那个2才行。（参见第二点）。
嗯，一不小心，就说了这么长，其实挺恨自个的，老喜欢跟人抬杠。但是吧，我爱科学啊。科学家最喜欢干的事儿就是怀疑与否定了。所以，对于这些看起来都很美的东西，一定不能让自己一下子就被带进去。不管是SOA, Agile还是最近的REST和SNS。因为真理往往掌握在少数人手里，也许你能多独立思考那么一晚上，你可能就能领悟到比别人更多的东西。同时也能训练着自个变得更加的客观。何乐而不为啊。
咳，老是一不小心就又扯的没边儿。好吧，准备就此搁笔吧。关于PP，其实我并没有深仇大恨，只不过赞扬的人太多了，我就想客观的说点别人没说或者没想的东西。
其实经历过这5，6年的软件开发，真的慢慢感觉出来一个道理：
成功的因素存在太多偶然性，而失败的因素中，很多原因确是具有必然性的，所以关注失败也许是为了迈向成功更好的一种途径。
所以，我现在很喜欢研究失败，研究最差实践，嗯，基本大伙管这个叫-教训。我想也许以后我会多聊聊关于失败，关于错误的事情？哈哈，看我时间吧。
PS：下一篇，准备简单聊下我对项目中各色各样的文档的看法。欢迎拍砖。
近期评论