伪代码法

[b][color=red]2011-05-11 补充一个链接，这个例子实际些：[/color][/b] [url]http://www.iteye.com/topic/826710#1809014[/url]

今天在看跟[url="http://wxmfly.iteye.com/"]Bob[/url]借来的[url="http://book.douban.com/subject/3109238/"]《Everyday Scripting with Ruby》[/url]，看到第7章第2小节提到的一个“假设式脚本编写法”，忍不住兴奋，这不就是我一直在用的所谓“伪代码法”嘛。顿时一股[url="http://www.iteye.com/topic/243210"]“英雄所见略同”的自豪感[/url]油然而生。 :D 喔呵呵呵呵……骄傲了点。。

其实所谓的“伪代码法”的想法来自于[url="http://book.douban.com/subject/1229923/"]《重构》[/url]一书中所说的：[quote]我们应当遵循这样一个原则，每当感觉需要注释来说明一些什么的时候，就将要说明的东西写进独立函数，并以其用途（而不是实现手法）命名。[/quote]
以及论坛里一些前辈的经验之谈，还有自己在学习过程中的一点领悟（如[url="http://yuan.iteye.com/blog/452228"]从AWDWR中的depot思考软件设计[/url]）。遵循着这条原则写代码多了，有时候就会有意的把一些估计处理起来会比较麻烦的过程（往往不是该方法的职责）直接以一句话替代，也就是一个并未实现的方法调用。最后总结出这么个伪代码法。

现在觉得这样写起代码挺自然的，就像是一层层深入的，从最接近用户需求的表面到具体的技术实现的细节的，自顶向下的为你解释一个系统如何工作：
这个功能要做事情A，事情B；
当遇到某种情况时，要去做事情C；
否则，做事情D；
最后做事情E。

然后如果有必要的话，接着开始详细解释、或者说定义事情A、B、C、D、E，就像上面的解释一样。
事情A：
首先做XX
然后……

这样自顶向下写出来的代码目的很明确，下层的接口定义的很清楚，同时[b]保证了不会有多余的代码，你所写的即是你所需要的，避免了过度设计[/b]。也不会出现大把业务逻辑写在控制器中的情况了。因为你的控制器已经写明白了控制器要负责的事，剩下的都交给模型去处理吧：

根据perishable_toke查找用户
如果找到用户
  激活用户
  返回登录页面
否则
  返回报告错误页面
结束

@user = User.find_using_perishable_token(params[:token])
if @user
  @user.activate!
  redirect_to signin_path
else
  render 'activate_failed'
end

然后实现find_using_perishable_token方法（authlogic已经实现了）。
接着定义激活用户的方法：

激活用户：
设置user的active值为true
重置perishable_token
保存

User#activate!

def activate!
  self.active = true
  reset_perishable_token
  save
end

然后再实现reset_perishable_token和save方法，不过在这里这两个方法已经是authlogic和rails实现的了。

总的来说伪代码法就是用最直白最简单的人类语言把系统要做的事情简要说一遍（就像讲故事一样 :) ），然后再往下逐个解释每件事情大概应该怎么做，在处理每件事情的过程中可能又有更繁琐的细节，这时候也以一句简单的话概括，不管它如何实现，然后继续……直到整个功能完成。

之所以叫伪代码法是因为在一开始写出来的代码是不能执行的。不过现在找到它的名字了：假设式脚本编写法（scripting by assumption）、一厢情愿式编程法（programming by wishful thinking）。

我觉得这是一种很实用的开发方法，再跟TDD结合会相当的完美。 :D