写好软件的诀窍

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

真实情况

真实情况是，计算机能正确的按照命令去运行。无论你写的是“Hello World”，还是用无人飞机去杀死一个人。计算机都能精确的按照你的命令去做。

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

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

写软件要像讲故事

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

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

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

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

诀窍

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

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

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

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

例子

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

class Post < ActiveRecord::Base
 belongs_to :author, class_name: 'User', foreign_key: :authored_by
end

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

class Post < ActiveRecord::Base
 belongs_to :user
end

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

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

class Setting < ActiveRecord::Base
  belongs_to :creator
  belongs_to :editor

  attr_accessor :editing_user

  before_create :set_creator
  before_update :set_editor

private

  def set_creator
    self.creator = @editing_user
  end

  def set_editor
    self.editor = @editing_user
  end

end

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

class Setting < ActiveRecord::Base
  belongs_to :creator
  belongs_to :editor

  def editing_user=(user)
    if new_record?
      self.creator = user
    else
      self.editor = user
    end
  end
end

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

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

class PostsController < ApplicationController
  def create
    if params[:post][:text].present?
      if params[:post][:text] =~ /fuc k|cock|shi t/
        flash[:error] = "Be nice"
        @achtung = true
      end
    end

    if !@achtung
      @post = Post.new(params[:post])

      if @post.save
        flash[:success] = "Yoo hoo!"
        redirect_to :index
      else
        render :new
      end
    else
      redirect_to :index
    end
  end
end

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

试试这样写：

class PostsController < ApplicationController
  def create
    @post = Post.new(params[:post])

    if @post.save
      flash[:success] = "Yoo hoo!"
      redirect_to :index
    else
      render :new
    end
  end
end

class Post < ActiveRecord::Base
  validate :bad_language_check

private

  def bad_language_check
    if text =~ /fuc k|shi t|cock/
      errors.add(:text, "has some pretty bad language")
    end
  end
end

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

结论

其实很简单。想写出好的软件吗？别再给机器写代码，从此后为人写代码。

就这么简单。

英文原文：The Trick To Good Software / 译：外刊IT评论