Ran Xiang: 2008 Archives

嗯，周末无事，想了想N久前就打算自己写BLOG系统的事儿，觉得还是说做就做吧。毕竟，业余时间在家老看美剧也挺无聊。 然后这个周末，花了几个小时，做成了现在这个样子就丢上来了。 现在blog.ranxiang.com还是原来的MT系统。而ranxiang.com已经是俺自己写滴老。哈哈 分页，tags，评论，Feed输出。 简单的功能都已经有了，不过还是有很多不完善的地方就是了。比如现在右边tag could点的话就会报错-_-### 还有页面也很简陋，而且后台也丑陋滴要死。 不过这些都没关系啦，慢慢滴做嘛。我觉得一launch人就会变得有动力，所以我宁愿把这么简陋的程序就放网上去。 时间花费的稍微久了点，其实ruby端很快就写完了，估计就十几分钟的事情。很多时间花在别的方面了。 比如这个挨千刀的CSS,哎哎。实在太折磨人了，好在最后我决定就抄MT的那个模板好了。然后进度这才开始一点点的加快。 还有就是将原来的数据导入现在的库的时候，因为乱码也稍微费了点周折。 本来想着，部署到dreamhost上也许会费一番力气，没想到挺速度的一会就弄完了。 不过和MT相比，发现dreamhost上静态文件和动态文件的速度简直不是一个级别啊。所以我也要给俺滴BLOG系统加上静态化的选项。 嗯哈，心情还是比较happy滴，现在想做滴事情好多啊，HOHO，看来以后晚上是有的忙活了。嗯，生命嘛，充实点好。 噢噢，讲了大半天，忘记说了，俺做滴BLOG系统叫rxblog，哈哈，在googlecode上开源呢，地址是

http://code.google.com/p/rxblog/

。当然，目前的代码惨不忍睹，目前也没啥测试，您就表较真了。且等着俺慢慢打磨，也弄出来一个媲美MT,Wordpress的blog哈。嗯，俺滴信心是和俺滴小宇宙一样滴强大滴。谢谢 还有，目前俺在feedsky上的feed还是抓的blog.ranxiang.com， 因为ranxiang.com俺自己写的这个程序还处在进度不稳定状态，俺可不好意思撑爆你的rss reader。Hmmm... 就这样，争取下周更新一个版本...

嘿嘿，有兴趣滴同学可以上 ranxiang.com 看看哈，体验下Dreamhost上，rails程度有多'速度'

    7天前的星期一，东八区下午2点28分，四川汶川发生了里氏8.0级别的特大地震。基本上大半个中国都感受到了不同程度的震感。身在北京，当时正在卫生间的我也不例外。

    这一周，相信对于每个人都是如此的难熬，每天看着网页上不断飙升的死亡人数和越来越惨不忍睹的震区图片以及越来越多震区发回来的视频报道，采访。心情如此的难过与哀伤，为那些死去的人们，为那些无家可归的人们，为那些失去父母的孩童，为那些失去孩子的父母......

    整整一个礼拜，对于四川灾区人民来说，定是犹如炼狱。不过，我很久以前就开始相信一句话：艰难的岁月总会过去，只要你能坚持下来。这次事件当中，也让人看到了很多的希望与爱心，让我对于我们的民族与国家增添了些许信心。

    明显的说，天朝在这次事件中的响应、重视、以及透明度都是近年来表现的最好的一次。而举国上下，无数的个人、企业、团体、组织献爱心的种种义举让让人值得振奋，也体现了我们的民族的凝聚力。这是一种伟大的爱，无疑是值得赞扬和歌颂的。

    当然，事件本身也应该引起足够的思考了，包括房屋建设的严重不达标，和震后救援的推进速度等等，也凸显了如此多的问题。我想，暴露这些问题是由好处的。只有暴露出来这些问题，将来才能更好的解决。

    一个礼拜过去了，我也终于有力气能说些什么了。当震区确定和灾情报道出来之后，我的第一想法就是想去当兵。从小我就一直在想着，如果哪天打仗了，我一定第一个去当兵，因为我觉得和平时期的军人其实是没什么意义的，军人的意思在于战争的时候，保卫自己的亲人，朋友，民族与祖国。这次让我知道，其实在和平时期的某些时刻，我也会去想当一名战士，去舍身，去拼命，去不计得失，不计个人安危的救人。这是一个男人，一个真正的男人所应该做的事情。修身，齐家，治国，平天下。我对自己很欣慰现在就想到了这些，明白什么是男人的社会角色与社会责任。

    我想，这次事件会让我们所有人的心灵经历了一次大的洗礼和锻炼。让我们的内心变得更加强大，充满力量。

    死去的人们，就祈福他们安息，活着的人们还要继续。就让每个人都更加的努力，用更多的勇气，信心去面对将来。艰难的时候总会过去，只要你我能坚持下来。

this post is only a test, for twitterfeed and twitter, it will be removed in few hours later.

    其实最近两三个月，我感觉有差不多一半的工作时间都放在了Refactoring相关的方面了。然后又看了本新书《修改代码的艺术》。我想我对于重构滴理解应该说是越来越深了。
    其实在前些日子，我曾经有过苦恼(见在JavaEye发的帖子)，发现自己总对一个具体的地方重构，不断的重构，而一直没有达到让自己满意的境界。所以约重构约觉得苦恼，然后最后终于让人有一种喘不过来气的感觉。然后记得和gigix聊过一次天。他给我发了一段他和他同事的聊天记录，我看了之后感觉舒服了许多，然后自己又寻思了寻思，感觉心情一下豁然开朗了。很可惜，前阵子，系统坏掉。貌似把那段对话给弄没了......所以想想，那就写篇blog吧，省得万一将来某天完全忘记之后再次因为这郁闷。我的脑袋确实有时候忘性大的厉害。

    先谈谈下为什么我们需要重构呢？因为据说每个软件的成本，有相当相当大的一部分都出在维护上。无论是现有软件的fix bug，还是添加新的feature，都是需要在原有的code base上进行更改，添加之类的。所以原来的code base写的好坏对于将来的修改成本来说，就是至关重要的了。而基本上，软件没有不修改的，基本上从开发的中后期就要会出现大量的bug需要fix，然后将来的发布，升级，基本上都是和原来的代码质量息息相关的。而refactoring，就是在不更改原来的业务逻辑和code所具备的行为之上，对code内部进行的一系列的调整，使code质量更高，更易懂，更方便将来的修改，继承，复用。等等。

   所以说，这就是重构的目标，那么既然原因和目标都定下来了，实施起来的度也就好把握了。只要估算重构的成本+重构后代码的修改成本是否小于不重构代码的修改成本就好了。如果前者比后者的成本要小，那么说这样的重构就是有意义的，就是成功的，在商业上来说，就是有价值的。否则，在商业上来说就是一种浪费了。

   但其实要想仔细具体的评估两者时间的成本情况，我觉得还是比较难清楚的划分出来的。更重要的就是一些经验了。譬如如果说代码中嵌套了两三层unless，那么我感觉就不如改成if划算。因为if还是更为常见，将来别人读取来，理解也更为迅速。因为绝大多数语言都有if，所以大部分的程序员更容易接受if，而不是unless。然而如果要把这几个unless改为if的话，如果花费半个小时的功夫，应该是值得的。但是如果花费一礼拜的时间来寻思到底是改为if呢，还是保留unless呢，还是这样那样的。那么明显的，我感觉就不值得了。

    其实我觉得我曾经那段时间自我郁闷的问题就处在这里。我没有想明白refactoring所带来的价值，而纯粹的陷入到代码的细节中去想，究竟是A方案，还是B方案。其实有时候两者的差别并不太大，也许A方案只比B方案好一点点。如果这种情况下，我却花费的更多更多的时间来思考究竟是A还是B的时候，如果这个时间花费超过了A比B方案好过的时间成本。那么，应该说，这次重构就失败了。所以很多情况，我觉得重构的时候，一定要想清楚，到底重构是干什么的。最主要的是为了节约将来修改的成本，而不是说让code达到完美无缺的境界。毕竟，完美基本是不可能的，不管任何事物都没有什么完美的。而，把握好那个度才是至关重要的。