代码重构(Code Refactoring)是一个编程的术语：在保留原有的功能的情况下改变计算机程序代码让其容易被修改为适应变化、增加可读性或者简化结构。这个实践对于产生高质量程序非常重要，而且这种想法不仅限于编程概念，也完全可以用在生活上。我的blog里面也会经常用到这个词（重构我人生），所以今天我决定就把生活的记录工具blog给重构一下
对于程序员朋友，这里插播一个问题，我发现中文的wikipedia对于代码重构(Code Refactoring)的定义非常的不准确，摘抄如下：
代码重构指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中，重构需要单元测试来支持。
为什么呢？因为martin folwer使用的定义和英文wikipedia这个一致：
Code refactoring is the process of changing a computer program’s code to make it amenable to change, improve its readability, or simplify its structure, while preserving its existing functionality.
中文解释里面所说的重构需要借助工具完成支持纯属放屁。而且遗忘了重构的一个目的是为了让代码易于维护那么就没有说明重构的经济意义。所以，大家看看我上面那个翻译如何？一起修改一下我去修改一下wikipedia的条目。
回到我要说的blog重构的话题。我现在的blog使用的是Wordpress，但是再往前推我还在Live Space和BlogJava写Blog。但是那个时候没有使用Tag来管理blog post，所以都使用了很复杂的分类（Directory），再后来我把Live Space的blog通过MSN Space mover迁移到了现在你阅读的这里，所以那些目录也就都被迁移过来了。
所以多分类Category是我第一个要重构的地方。原因在于分类最早的设计是一个严格的树形结构，也就是分类是一个逐级缩小范围的概念，它适合于自上而下的查找。比较常见的就是传统电子商务网站的目录和网站的树形导航。但是这两年大家发现很多人的阅读习惯并不是这样的，尤其对于blog这样的形式。blog我们分成两种场景来分析分类的使用：
- 搜索引擎或者链接：这种情况下用户是偶然看到了一篇他感兴趣的文章，那么他下一步会查找相关的主题，这个时候分类会是他第一个寻找的。但是，很少有用户会在乎分类的树形结构，而是对哪个具体的话题感兴趣就点进去。所以最好的方式就是话题和分类一一对应。如果你的blog的话题太多了，那么你一定不会注意到你的分类也太多了，这些噪音会影响用户探索你的blog。所以人们发明了Tag，也就是一个简短的关键词来定义你的一些话题，每个post还可以打多个标签，这个也方便了你自己，不用在给文章分类的时候抓耳挠腮。然后人们使用Tag Cloud这种方式突出你的blog的最重要的关键词（也就是统计使用频率最高的Tag配以较大的字体），它也帮助你了解自己写blog的习惯。那么对于这种场景，Tag Cloud是比Multi-Category（单篇文章多目录）更好的详细管理主题方式。
- 订阅：平常我们在使用工具订阅blog的feeds的时候我们一般都是按照这个时间序列来阅读，我们会忽略不感兴趣的feed，然后阅读感兴趣的，那么订阅的feeds需要满足这种习惯。不过最常见的订阅方式是订阅全部，这种方式有的时候不太好。比如我们公司有个员工blog聚合服务，我没有加进去，因为我的blog有很多生活的内容，别人肯定并不想阅读那些部分。也就是说不区分主题的feeds输出会让人看到很多不感兴趣的主题。如果你使用了Tag Cloud，它可以区分主题，但是它太多了，没有人会逐个Tag Cloud订阅你的blog，人们希望有一种稍微粗略一些的方式来订阅。我发现的一种最好实践就是按工作/生活的主题区分，对于技术人员也常见技术/非技术的分开，这种分法很粗放，但是却很有效。因为如果我是生活上的朋友我就会关注你非技术的post，而相反如果我是你的同事或者社区里面的朋友，那么我会关心你的话题。所以，这种场景下的一个最佳实践就是让你的blog的分类尽量的简单，2-5个我觉得就可以了。
啰嗦了半天，其实行动很简单。我需要把现在复杂的Category转换为Tags，还有添加新的简单分类“Tech.技术”和“NoneTech.非技术”。在Wordpress里面这个很简单，因为在wordpress里面Tag和Category实际上是同样的东西，但支持不同的显示方式。在wordpress的后台的Manage->Categories下面有一个category to tag converter的链接进去选择你想要转换的Category然后转换一下就OK了。一个简单的操作以后这些Category就都不见了。那么所有的文章就都跑到Uncategoires下面了。我好需要重新做一下分类，这是个体力活……不过我使用了Wordpress的客户端来实现。
那么下一步就是重构blog的下一个话题，选择一个客户端工具来更新你的blog。我试用了ecto和MarsEdit，它们是mac下两个有名的blog客户端，它们对blog的管理功能都差不多，但是编辑方式不一样，其中ecto的编辑器是所见即所得的，而MarsEdit是一个直接写HTML源码然后预览的界面。我对HTML烂熟，所以用MarsEdit没有困难。大家可以根据自己的需求选择，它们都是需要交注册费的。试用客户端的好处就是不用忍受浏览器的崩溃，不用忍受网络闪断造成的提交失败，不用因为写post时间太久而session过期，可以方便的存在本地，可以在离线的方式下修改/添加blog post，这些功能可以帮助你频繁的写blog，而不是每次都需要准备很久来登陆->新建post。我其实已经试用了几天Ecto了，比较满意，但是Ecto的试用版不能选择取回条目的数量（不知道注册以后是否可以？），所以对于修改分类这样的任务来说MarsEdit才可以修改我全部的项目。
在整理blog post的时候，我发现我这里有很多以前留下的Twitter聚合内容，我把它们都删掉了。以前我曾经想把micro blogging（微博客）的内容也放到blog里面，可是我发现有了FriendsFeed这样的工具以后我就不需要用blog来聚合了，这样是一种明显的Bad smell－重复。冰云同学批评过我聚合Twitter，他说的很对，现在我本人也很反感聚合Twitter，有这种行为的人的blog一律退订。
上面说的这些就是今天重构的实践，之前我还做过几个实践：保持只有一个blog服务（不需要同时使用Space和blogjava），如果不满意BSP（Blog service provider），那就自己买空间架一个Wordpress。定时备份你的Blog，并且最好有工具让你的blog可以转移成中立的源文件（如SQL、XML），方便以后迁移，选择BSP也可以以这个为标准。
最后总结一下我提到的重构blog的几个实践：
- 将复杂的Category转换为Tag，删除多余的Category，使用简单的Category，2-5个为好
- 使用一个Blog客户端，事半功倍
- 停止使用Twitter和Google Reader聚合生成blog post的功能，如果需要可以把它们放到你的blog的sidebar上，而不要生成到feeds里面
如果以后还有其它重构行为我还会更新这个post。今天已经好累了 -。。-
Concurrency introduces parallelism into our applications, and threading is, of course, one way to achieve concurrency. But it turns out that in Ruby, this relation is not transitive: execution parallelism is not the same thing as threading. In fact, if you’re looking for parallelism in your Ruby application, you should be looking at process parallelism instead. So why is that?
