致命的细节与令人喜欢的细节

    有些事情从开始计划的时间，从表面看什么都是对的，初衷都是好的，但是最后执行的结果，却走样了！那么其中一定有致命的细节被忽略了，而且也正是因为这个不起眼的细节，导致了什么都与最开始的初衷偏离了........

     致命的细节，你让我紧张啊？美丽啊，你让我慌张:) 突然想到倾城之恋这个歌词，以表示对细节的敬畏！

    这个感慨是因为近期公司所执行的考核制度，在执行的过程中，参与考核的各方之间发生了很大的“内耗”！本来就很短、很宝贵的开发时间，就被无效率的讨论、忽悠、扯皮中浪费过去，或许真正的民主或真正的流程化就是如此，但是，我觉得对一个处于快速成长期的公司来讲，对宝贵时间的浪费，往往是可耻的和令人后悔的，遂觉得这项考核的政策有点太过了！同时也觉得，可能跟它的结果与它最初被设计时所想产生的预料结果，肯定有很大的偏离，只不过高高在上的人不一定了解。

    在不断思考这个问题的时候，发现公司的创始人，所提倡的两个深入,"深入客户、深入员工"是多么精髓的公司经营理念!如果这样理念能被很多人理解和把握，以及带到实际中贯彻执行的话，我想有些事情是可以发现于千里之堤毁于蚁穴前，或者出现让参与的各方感受更好的制度，一切都在不断改进中进化。


  其实，这个致命的细节，实际上很明显，一点都不难发现，一般是你进行一些设计时所依赖的最初假定！只所以最后会形成致命的细节，一般是它在现实中都得不到满足。我们一般假设一个设计或一个政策，会取得一个好的解决，是在一定的基础进行合理的推演，所预料发生的。但是，当你所依据的基础，在现实中并不能得到满足的话，最后它所执行的结果就会大相径庭！这也是我博客，最开始的一篇博客中提到的《逻辑悖论与刻舟求剑》样，随着发展实际上好多可能都会变化，一定要警惕变化！！


  但是，我在这里更要着重着重说明的，细节在编制程序时，拥有另外一番魅力！程序设计时所涉及的细节，往往拥有一种很具参考研究方向，以设计出结构更好的程序出来，呵呵！
 
     我们来展开对细节的描述吧？go on!

   当一段代码需要用if/else/switch来判断一个细节的时候，这就证明在这里细节被抹杀了，这里不拥有细节的决定能力，细节的决定能力在这个地方的外边。在面向对象的设计中，这个外面可能反映为调用方或者基类的继承子类。

  例如，设计模式工厂方法一样，在基类里面只定义了接口，决定它实现类的能力留给了它的子类；而对于strategy模式，决定策略实现者的是调用算法的人，由算法的调用者，也可以说它的上下文给定算法的实现。

  我们在设计一个模块的时间，按照两个思考方向来决定设计，可能是非常好的：
  1.该地方有没有细节决定能力
  2.没有细节决定能力，就放给它的外界，子类或调用方或它的上下文


  这样程序软件就可以象模式一样，拥有比较大的合理对外假定，以及支持变化！