我正在写的一个库，摆在我面前的是这样一段代码：

class CONSTANT_Utf8 < MyModule::String
  size :type => :u2
 
  define_type :constant_utf8
end

这里定义了一个类型，它定义了字符串类型，size的类型是u2，类型的名字叫constant_utf8。我翻遍了所有的代码，这个类型的名字（CONSTANT_Utf8）除了定义这里，根本没有人会用到。没有用的东西是否还有存在的价值，这是我面对它思考的问题，尽管这是我想当初费劲心力想出的名字。经过一番痛苦的思索，我打算把这段代码改成这样：

MyModule.Type.string(:constant_utf8, :size => {:type => :u2})

如此一来，那个完全没有必要存在的类名字便也烟消云散了。想清楚之后写代码还是容易的。

module MyModule
  class << Type
    ...

    def string(name, options)
      type(name, MyModule::String, options)
    end

    def type(name, super_type, options)
      klass = Class.new(super_type)
      options.each {|key, value| klass.send(key, *value) }
      define_type(name, klass)
    end
  end
end

于是，我兴致高昂把后面类似的代码用同样方法处理。突然，一个测试失败了，真正的问题在这段代码：

MyModule::Type.struct(:constant_long, :u4 => :high_bytes, :u4 => :low_bytes)

经过分析，让这段代码失败的理由是，后面两项居然都用:u4做键值，于是原本是两项，传进hash之后，就只有一项了。于是，我的思路开始发散，加上括号，改hash为array……

结论是，没有哪个让我满意，不是实现不了，而是着实没有美感可言。不知道大脑中的哪个弦跳动了一下，既然在这个思路下，问题没法解决，我不妨换一个方式，于是，代码被改成了这样：

MyModule::Type.struct(:constant_long) do
  u4 :high_bytes
  u4 :low_bytes
end

如此一来，hash可能带来的冲突便不再存在了，而且，这和最初的用类定义形式上也更加接近，还有，这里也不用再为symbol点那个冒号了。当然实现也是要相应调整。

module MyModule
  class << Type
    ...

    def string(name, &block)
      type(name, MyModule::String, &block)
    end

    def type(name, super_type, &block)
      klass = Class.new(super_type)
      klass.instance_eval(&block) if block_given?
      define_type(name, klass)
    end
  end
end

前两天和胡凯聊天，我们发现公司里有一些更资深的技术人员，他们解决问题并不是通过操起兵器直接上阵，而是通过分析，提出另一种解决方案，从而原本的那个问题也就不是问题了。这里，我跳了两次，躲过命名和hash的烦恼。

听着张惠妹的《解脱》，看着奥巴马当选美国总统的新闻。

对于政治，我不那么关心，对于奥巴马的当选，我看到的更多是一个美国梦的实现。和人说过，如果奥巴马当了总统，我就去买一本他的《无畏的希望》来读，看来要多读一本书了。当选的奥巴马经过了最初的喜悦，很快就会面对的更现实的问题：经济危机。经济危机，这个最初曾在初中政治课本上见识到的词，这一次迈着大步重回人间。

曾以为经济危机离自己很远，直到公司厨房里的零食开始减少，我才知道，原来，还是会有一些影响的。

今天下午，当我和几个同事正在热火朝天的讨论一个问题的时侯，忽然项目组召集开会。老大告诉我们一个坏消息，项目取消了！

原因很简单，在这个经济危机的冬日，客户准备扎紧腰带过苦日子了，所以，所有的项目都要取消了。比起厨房的零食，这次，经济危机的冲击更加直接。虽然老大说了很多，说我们这段时间的工作是有价值的，希望大家最后在把一些整理和收尾的工作做好。但散会后，大家的表现一目了然，刚还在为一个问题争论不已的我们，一下子失去了前进的动力。我们操起了放下好久的Wii，放肆的在“工作”时间打起了网球，甚至在其他人还在忙碌的时侯，一群人就奔向了KTV，准备引吭高歌一番。

对于我而言，听到“取消”的那一刻，我的思绪却飞回了六年前。

那时，我刚刚离开校门，还是一个干劲十足的毕业生。我放到了一个Java项目上，做的是一个彩信网关，那时侯，我们称之为多媒体短信（MMS）。这是我在职业路上真正意义的第一个项目，我不懂业务，不了解Java，不知道网关为何物。于是，我拼命的学着项目需要的各种各样的技术，写着尽可能有用的代码，也犯着初学者可能的各种各样的错误。还记得当时我是分配和一个在读研究生一起写协议，还有一个用于测试的客户端模拟器，他忙着写自己毕业论文，于是，我几乎一手包办了所有代码。当我的模拟器与我们的系统成功互通，我无比的满足。

在2003年新年到来之前，项目负责人宣布，项目取消了。当时的我，一下子就懵了，我拼命的回忆着自己到底做错了什么。现实是，这个彩信网关当时根本就没有需求，完全是部门领导拍脑门想出来的东西，当他们看到短时间之内不可能有真正的需求时，终止了这个项目。

那个飘雪的冬夜，项目负责人带着我们几个在一家朝鲜族饭店吃了散伙饭。

那之后，我知道，原来技术并不能决定一切。

时隔六年，现如今的我经历了很多，也能够更加坦然的面对同样的场景。项目死掉的直接原因通常与程序员无关，好程序员可以对一个项目的成功推波助澜，但却很难毁掉一个项目，放在大背静下更是如此。

冬天来了，春天还会远吗？