在编程语言的世界里有一种理念，就是把代码分『块』，这个块在每个语言中名字不完全一样，有的叫def，有的function…… 但它们的运作原理都是一样的：可接受输入，运算后输出，每个块只实现单个功能。 它们的特点是：内部算法不对外暴露，与外部模块对接完全依靠它的输入参数与返回值。虽然几年前学过的C已经忘得差不多，但是这个设计模型倒是记忆尤新。 最近经常思考总结一些生活与工作的效率与方法，竟觉得计算机语言模型是一个效率极高且极稳定极有条理的一个方法（debug也就是责任分担极其明确）
举例来说，如果我需要和朋友一起做一道美食（其实我不会做菜啦啦啦），而这个事情基本可以分为几个『块』：原料收集，洗菜配菜，下锅烹饪。『原料收集』只需要接收购物清单，然后只需要输出保质保量的原料给『洗菜配菜』，『洗菜配菜』只需要接收原料与配菜比例，然后生成一盘盘配好的生菜给下一个『下锅烹饪』……
这一系列运行的要点在于：
- 找到『最优实现』的人来负责它的『块』。（相关文章：如何判断专业水准）
- 清晰明了的输入与输出。（相关文章：deadline的作用与技巧）
- 永远不要插手其他『块』内部的运作。除非如果你也是内行并且有更优秀的实现。
这里重点解释一下第三点，大家都说人多力量大，为什么不能插手其他『块』内部的运作呢？因为人多力量大这一点只对第二条有用，也就是当你不清楚你的方向的时候大家可以一起瞎哄哄然后把各种点子搞一堆再实现最优选。
第三条就完全不是『人多力量大』，应该叫『人多力量杂』才对。相信小时候大家扎堆玩俄罗斯方块时都有个特别讨人谦的多嘴哥在耳边的经验。而且在这种乱七八糟的人都自以为是地来『优化』块内部的运作细节通常会导致糟糕的结果。然后面对糟糕的结果的时候心理学上的『责任分摊效应』就出现了，插手与被插手的人都会觉得是对方的责任。而在团队合作中，『责任定位』是非常重要的环节，做坏了事不重要，重要的是做坏了事还不认为是自己干坏的，那么下次再坏事也就不奇怪了。
总结：想要轻松而又高效的与人共事，首先找个精于某道的人，然后清晰明了的告诉他你现有的需求以及预期的目标，然后该干嘛干嘛去准点来收工。
顺便说一声，2015来了，哎又有好多东西要总结的……大家等我的作品哈……
后记 光阴如梭（2016），现在回过头来看这个观点价似乎说的太过了。 上文提到的『块』的概念，其实并非合作与效率的关键，关键在于：人。 做事靠谱的人，有能力完成任务的人，与其沟通是一件愉快的事情。但大部分的时候的现状是你找了一个60分的人，企图让他做出80分的成绩。 如果你本身就有90分，这是可行的；如果你本身就不是干这个的或者也是60分，就别做这种吃力不讨好的事儿了。
追求『性价比』有时候反而是最贵的。