草色天涯

1. 默默。逻辑思维方式。

2. 梦头。在不见其增，日有所长和有关咨询的一点事儿里面已经提到了

3. Tin。今天晚上跟Tin说起对某人的一些负面印象，他在肯定了我的看法之后，又很认真的给我指出他身上有哪些优点是值得去学习的，之后又建议我去给他一些能够给他提供帮助的反馈。

这些都很好，自己要想办法养成这样的习惯。

rojam是dreamhead同学做的一个用ruby代码操作java字节码的开源项目，项目具体内容因为跟本文主题无关，所以就不多描述了。我最近一段日子因为onbeach，所以就参和了进来。在开始读到rojam的代码之前，我原本以为自己还是会写一点ruby程序的，然后就被深深的打击了。。这里记录下来一些rojam中的metaprogramming技巧，并不是什么系统化的知识，只是自己的一点总结把。

先看这段代码：

class << self
       {
        :no_arg       => 1,
        :var          => 2,
        ......
      }.each do |type, size|
        class_eval %Q{
          def #{type}_instructions(*opcode, &block)
            instructions(#{size}, *opcode, &block)
          end
        }
      end
......
end

eval方法会将字符串作为ruby代码执行，它的变体有如下几种：class_eval, instance_eval, module_eval，分别用于其名字所表示的上下文。上面那段代码的含义就是，把block跟hash的each方法关联起来，当block被调用的时候，%Q{}所包含的部分就会被作为ruby代码执行，于是就有了

def no_arg_instructions(*opcode, &block)
    instructions(1, *opcode, &block)
end

def var_instructions(*opcode, &block)
    instructions(2, *opcode, &block)
end
.......

自然，这些方法是动态生成的。

接下来再看这两个方法：

def instructions(consumed_byte_size, *opcode, &block)
   opcode.each do |single_bytecode|
      define_method instruction_method_name(single_bytecode), &block
      consumed_byte_size_table[single_bytecode] = consumed_byte_size
   end
end

def instruction_method_name(instruction_code)
    "__#{instruction_code}__"
end

这行代码：define_method instruction_method_name(single_bytecode), &block，会把instruction_method_name(single_bytecode)所返回的字符串定义为方法，后面的block作为这个方法体的一部分。最终的结果就是为每一个opcode都定义了与opcode同名的方法。

昨天听默默的讲座，清一色的头脑风暴，完事以后大家都感觉特累。

在一个头脑风暴里，当时是要每个组都给四天的课程安排agenda，我们组的人讲完以后，dreamhead说：我其实特别关注你的思路，因为你现在不是跟客户讲，而是跟公司内部的人讲课程安排，所以思路就很重要，你是出于什么目的来这样安排课程，这样安排会带来什么样的好处，这些一开始就是需要讲清楚的。

唔，其实何止是没讲清楚，我很怀疑大家有没有自己想清楚为什么要这样安排课程；当时team的人都是匆匆忙忙的往白板上贴纸条，后来我强调了一下，告诉大家别只顾着零零碎碎的贴，自己心里得有谱，有一条线索把你贴上去的这些东西能够串起来，自己能按照这些纸条把几天的课讲完。

不过dreamhead的话还是让我感触很深，在服从习惯做这样那样的事情的时候，一定要多问自己几个问题：为什么要做这样的事情？它给自己或是别人带来什么样的好处？有没有更好的方式来做这件事情？比如我现在用blogbus的编辑器写博客，旁边dreamhead就在用文本文件写，写完以后再往上贴。

以后要时时提醒自己，让自己做事更有效率一些。

今天听@eaglexiao讲去某大型电信厂商那里作咨询，做CI的一些经验心得，然后大家又探讨了很久。

下面是学到的一丁点东西：

1. 团队内部的沟通。我们是作为一个整体去为客户提供服务的，所以要有一致的声音，任何一点微不足道的分歧，在单独面对客户的时候都有可能给人产生不靠谱的印象。所以当我们在内部表达观点的时候，应当要努力坚持，直到被说服为止，而不是被简单的否定。不然就没有很主动的心态去说服客户也接收这个观点。

2. 知识的系统体系。上个月老大在office update的时候也讲到了小强的故事，说他每天晚上都要狂补CI、配置管理的知识，今天听@eaglexiao和dreamhead也是说同样的观点，很多知识也许在我们看来是common sense，但是客户不一定，甚至就是不这么以为。那么要说服客户，抛开沟通技巧、演讲技巧之类的软性因素不谈，自己和团队必须得建立完善的知识体系结构──至少在自己所擅长，所要为客户提供价值的领域内。这样自己心里有谱，客户也会觉得你比较专业。

3. 不要用自己的知识面去套客户所面对的问题。这还是锤子和钉子的典故了，一旦有了心理暗示，就容易忽略掉其他证据。要多听，多调查。

4. 多探究问题的本质。客户暴露给我们的问题、要我们去解决的问题可能只是表面现象，我们得追求它的成因，这才是能够更好提供价值的地方。

5. 不一定客户问什么，我们就得回答什么。那句话实际上是前面那条的引申，这是在@eaglexiao陈列客户问题的时候，dreamhead提出来的。当时列出来的问题有：单元测试应该有多大的覆盖率？测试代码跟产品代码的比例应该是多少？dreamhead就说，你不一定就非得给客户把这些问题回答出来，你可以问他，你问这些问题的目的是什么？这背后可能就隐藏着一堆问题是需要解决的。如果你告诉客户，测试代码跟产品代码的比例在0.8～1.5之间，这种答案对他有意义么？没有。也许你问他以后，他可能会回答你，他要用这个数据去做评估，那么你就继续问，为什么要用这种数据作评估，然后顺藤摸瓜找出流程的问题来。这样一来就可以找到让我们价值最大化的地方了。