伪代码法

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

今天在看跟Bob借来的《Everyday Scripting with Ruby》，看到第7章第2小节提到的一个“假设式脚本编写法”，忍不住兴奋，这不就是我一直在用的所谓“伪代码法”嘛。顿时一股“英雄所见略同”的自豪感油然而生。 喔呵呵呵呵……骄傲了点。。

其实所谓的“伪代码法”的想法来自于《重构》一书中所说的：

引用

我们应当遵循这样一个原则，每当感觉需要注释来说明一些什么的时候，就将要说明的东西写进独立函数，并以其用途（而不是实现手法）命名。

以及论坛里一些前辈的经验之谈，还有自己在学习过程中的一点领悟（如从AWDWR中的depot思考软件设计）。遵循着这条原则写代码多了，有时候就会有意的把一些估计处理起来会比较麻烦的过程（往往不是该方法的职责）直接以一句话替代，也就是一个并未实现的方法调用。最后总结出这么个伪代码法。

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

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

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

根据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结合会相当的完美。

评论

2 楼 maddemon 2012-03-24  

我以前写过一个复杂的筛选逻辑，开始就是用中文写的。。。.net支持中文- - 后来就改成了英文。
其实就是注释法类似，也或者在纸上写下再转换成代码

1 楼 yuan 2010-12-14  

知道什么叫英雄所见略同么

《The RSpec Book》page 56 写道

The Code You Wish You Had
In my early days at Object Mentor I attended a TDD class being
taught by James Grenning. As he was talking about refactoring
a Long Method, he wrote a statement that called a method
that didn’t exist yet, saying something like “start by writing the
code you wish you had.”
This was a galvanizing moment for me.
It is common to write the code we wish we had doing TDD. Per-
haps we send a message from the code example to an object
that does not have a corresponding method. We let the Ruby
interpreter tell us that the method does not exist (red), and then
implement that method (green).
Doing the same thing within application code, calling the code
we wish we had in one module from another module, was a
different matter. It was as though an arbitrary boundary was
somehow lifted and suddenly all of the code was my personal
servant, ready and willing to bend to my will. It didn’t matter
whether we were starting in a test, or in the code being tested.
What mattered was that we started from the view of the code
that was going to use the new code we were about to write.
Over the years this has permeated my daily practice. It is very,
very liberating, and results consistently in more usable APIs than
I would have come up with starting with the object receiving
the message.
In retrospect, this also aligns closely with the Outside-In philos-
ophy of BDD, perhaps taking it a step further. If the goal is to
provide great APIs then the best place to design them is from
their consumers.