做软件也要走“捷径”

　　做软件也要走“捷径”。程序员身上的一个好笑的事情是，我们在毕生的职业生涯中都相信：我们的工作是告诉计算机如何去做。

　　真实情况

　　真实情况是，计算机能正确的按照命令去运行。无论你写的是“HelloWorld”，计算机都能精确的按照你的命令去做。

　　可我们的工作，我们的真正工作是：告诉程序员和我们自己：我们让计算机做什么了。现代的软件编程思想就是结构化的、清楚的描述计算机将要执行的任务。

　　事实上，计算机并不去阅读你在程序里写了什么，而人会。计算机把程序员写的代码编译成字节比特，真正会去看你写的是什么的只有人类。

　　写软件要像讲故事

　　如果你对你的工作和你写的代码的行为有了新的认识，你会马上很清楚的发现，编程工作更像讲故事。

　　想一想。你是如何知道一个人讲故事没人爱听的？这很简单，他老跑题，他老是纠结在不重要的细节上，他老是在故事场景中挑来跳去，等等。你立刻能知道故事被他讲烂了。

　　虽然在最后你能明白故事里发生了什么，你甚至能复述它，但你会喜欢这样的故事吗？你会有兴趣转述给别人或丰富故事内容吗？

　　相同的事情也发生在软件开发中。如果你的代码写的含糊不清，乱七八糟，没有人会愿意欣赏它。没有人会愿意看它第二次。并且你是第一个受它折磨的人。

　　诀窍

　　那么，现在你想要知道这个简单的秘诀，不是吗？下面就是

　　代码里的干扰因素越少越好

　　注意，我不是在讨论明晰的代码vs隐晦的代码，不是在讨论约定优先，不是在讨论元数据编程有害或其它类似的东西。

　　写出好的软件的诀窍是代码里只写那些能让你的代码讲出的故事更有意义的内容。如果它能让你的代码更清楚，那就这样写它。如果这个东西对故事没有任何意义，那就扔了它。扔了它能让故事更好。如果代码耦合模块不清，就用元数据编程和约定。

　　例子

　　有一些经典的例子可以证明这一点。比如，描述一篇帖子和它的作者的关系。

　　1 classPost

　　2 belongs_to:author,class_name:'User',foreign_key::authored_by

　　3 end

　　看见了没？所有关于类名，外键的信息都是干扰。去掉它们。

　　1 classPost

　　2 belongs_to:user

　　3 end

　　第二版中没有好听的“作者”字眼，但却是更优的，因为它直奔主题，用最简短的语句告诉所有你想知道的。

　　另外一个例子，说一个类需要关联那些创建/修改它的信息的用户

　　01 classSetting

　　02 belongs_to:creator

　　03 belongs_to:editor

　　04 

　　05 attr_accessor:editing_user

　　06 

　　07 before_create:set_creator

　　08 before_update:set_editor

　　09 

　　10 private

　　11 

　　12 defset_creator

　　13 self.creator=@editing_user

　　14 end

　　15 

　　16 defset_editor

　　17 self.editor=@editing_user

　　18 end

　　19 

　　20 end

　　干扰，所有的这些回调和attr_acessors都是干扰，都是垃圾信息，没有任何价值体现在你想完成的任务中。更简洁更好的方法是下面这样写：

　　01 classSetting

　　02 belongs_to:creator

　　03 belongs_to:editor

　　04 

　　05 defediting_user=(user)

　　06 ifnew_record?

　　07 self.creator=user

　　08 else

　　09 self.editor=user

　　10 end

　　11 end

　　12 end

　　你可以看到它精炼的告诉了我们发生了什么。这段代码说，这个类有一个记录创建者，一个编辑者，我们用editing_user赋给它们值。没有回调干扰。没有几个private方法的无用信息。

　　一个更经典的例子。在controller里管理数据

　　01 classPostsController

　　02 defcreate

　　03 ifparams[:post][:text].present?

　　04 ifparams[:post][:text]=~/fuck|cock|shit/

　　05 flash[:error]="Benice"

　　06 @achtung=true

　　07 end

　　08 end

　　09 

　　10 if!@achtung

　　11 @post=Post.new(params[:post])

　　12 

　　13 if@post.save

　　14 flash[:success]="Yoohoo!"

　　15 redirect_to:index

　　16 else

　　17 render:new

　　18 end

　　19 else

　　20 redirect_to:index

　　21 end

　　22 end

　　23 end

　　所有的这些条件逻辑跟你的controller实际上没有任何关系。所有的这些逻辑判断并不属于controller层负责。当然，你可以这样做，而其能正常的运行，但这不是好的软件。

　　试试这样写

　　01 classPostsController

　　02 defcreate

　　03 @post=Post.new(params[:post])

　　04 

　　05 if@post.save

　　06 flash[:success]="Yoohoo!"

　　07 redirect_to:index

　　08 else

　　09 render:new

　　10 end

　　11 end

　　12 end

　　13 

　　14 classPost

　　15 validate:bad_language_check

　　16 

　　17 private

　　18 

　　19 defbad_language_check

　　20 iftext=~/fuck|shit|cock/

　　21 errors.add(:text,"hassomeprettybadlanguage")

　　22 end

　　23 end

　　24 end

　　现在你的controller能清楚的说明白发生了什么。你可以清楚的看明白当记录可以创建和不能创建时会发生什么。跟Post类一样，你可以清楚的理解它在过滤那些不干净的文字。而且校验器有自己单独的地方。它的实现方式不会影响Post本身。