作为程序员写好软件的诀窍

发表于:2013-06-18来源:外刊IT评论作者:不详点击数: 标签:程序员
作为程序员写好软件的诀窍。程序员身上的一个好笑的事情是,我们在毕生的职业生涯中都相信:我们的工作是告诉计算机如何去做。 真实情况

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

  真实情况

  真实情况是,计算机能正确的按照命令去运行。无论你写的是“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] =~ /fuck|cock|shit/

  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 =~ /fuck|shit|cock/

  errors.add(:text, "has some pretty bad language")

  end

  end

  end

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

原文转自:http://www.aqee.net/the-trick-to-good-software/