从一碗面，领悟软件开发

     中午吃饭，点了一碗面。纯手工打造，看着服务员，将各种佐料放入碗中，不时向我询问，调配着这碗面的时候，就其手法可算上乘，与茶艺无异，从服务的角度来看，此乃一种享受。能够欣赏到厨师娴熟的手法颇为不易。就像我们去海底涝点面一样。
   
    缺点：

    然而从程序设计的角度上却有着严重的问题，首先，就线程而言，他没有采用并行的思想。她是先调配佐料，而后煮面，将原本较慢的操作方到优先级较高的地位，而将完全独立的另一缓慢操作（煮面）却放到了后面，采用串行工作的方式。造成资源浪费。
  
    另一方面，由于每次调配佐料都采用单点服务的方式，没有将公用操作合理化，造成额外的交互，降低开发效率。
   
    对于互斥资源（客人特色材料例如辣椒的计量）与公用资源（油等）同事放入关键代码段。进行互斥操作，严重影响程序效率。

   
    优点：
   
    采用同于接口，组件化开发，面向接口编程，并且接口通用性很好（汤勺），通用模块（各个碗中的调料），根据用户的个性化需求，任意组合，做到低耦合，高内聚。

     所有程序都希望做成这样，但是鲜有如愿者，之所以有此问题，是因为我们不能有效的定义接口。无法定义汤勺这样的接口对象。因为总想设计出通用性高的接口， 做出大而全的东西，反而发现，最后受制约的也是自己。所以我们天天叫嚣着平台化思想，如何代码重用，为了实现这个目的我们加上了无数的设计模式思想进去。 到头来却越来越不好用，最终夭折。

    然后我们消沉一段时间后，重整旗鼓，恢复信心，重头再来。重做之前的事情，采用一条完全不同的道路再次尝试，其实效果不见得比之前的好。也不见得比之前的差，就像中餐、西餐一样。意大利面和老北京炸酱面都是一样的。不同的就是一个用碗装，一个用盘装。
   
    之前的经验完全摒弃，周而复始，发现除了消磨时间。我们没有任何收获。没有吸取历史的教训。却反而将灾难重复上演，就像X档案中的一集，主角每次醒来都是 为了同一个目的去尝试不同的办法。每次都在尝试着不同的解决办法。却发现每次的结果都是失败的，直到最终他意识到不应该盲目的寻找新的解决办法，而应该总 结每次失败的共性，发现什么是问题的本质。最终才得以解决问题。
   
    而我们平台化的工作也是每次都采用全新的思想。而不是总结上次失败的教训。并保留上次的成果。(未完。。。)