模块化小议

        公司的中饭一直是个老大难问题。最早是一起到外面AA，可是上地附近人口稠密，一到中午各大小饭馆people mountain people sea，只能早去或者晚去，严重影响生活节奏。然后尝试订丽华快餐，菜式单一，送餐时间不准，经常是过尽千帆皆不是，望穿秋水地等呀……不说了，眼泪哗哗的～～自己带饭倒是不错，可是大夏天的太热，哪能眼看着老婆在厨房烟熏火燎地受苦呢。幸运的是，有一天发现楼下的饭馆提供订餐服务（须自取），对上文中提到的前两种模式做出了完美折中，价钱也合适，深得广大同事的喜爱。于是乎这种自助订餐运动遂在公司火热地开展起来。
        却说公司有位mm，虽然很少参加这类活动，但是对订餐的小票非常感兴趣。无他，盖因该mm需要帮人开发票另有公干，而持此种小票能到饭馆换开发票也。于是同事们领饭归来，均把小票交到此mm手上，由其自行开发票，倒也是各得其所，可称“和谐”。不想有一天，一位古道热肠的同事，顺手帮她开了张个人发票回来。自觉办了美事一桩，帮mm少跑了一趟腿。当他以9527上房拥抱风筝时的心情将发票交到该mm手上时，却突遭其当头棒喝：“兀那汉子，怎开得个人发票一张！？发票而不以xxx公司名义开之，发票与我何加焉？”该同事无以对。（注，以上情节在真实事件的基础上了进行了艺术加工，如有冒犯，得罪得罪）
        好心却办了坏事，是因为他并不真正了解别人究竟想要什么。换句话说，在开发票这件事情上，他缺乏足够的“领域知识”。当然，我们也不好因此就怪他说：“你怎么笨到连发票要开公司的事情都不知道？”（这是很多人对待别人的错误一种典型态度，它解决不了任何实际问题，还会带来情绪上的负面影响，严重者甚至造成后继的沟通障碍和隔阂，可以算得上一种反模式了）。因为毕竟没有人能够预知所有的事情，他不知道发票开什么单位是无可厚非的。问题的关键在于错把别人的职责划在自己的范围之内，不了解情况就去做。相较而言，以前其他同事的做法算得上是恰到好处。只带小票给她，自己不需要去操心发票怎么开，由具有这种“领域知识”的mm自行搞定就好了。
        软件设计也是如此：模块边界划分不当，常常会把本来内聚很好的部分拆开，却把本来需要隔离的部分耦合起来。软件就这样在不经意之间慢慢烂掉，最后变成一坨。看清楚问题的内在结构，把问题的不同部分划分为相对独立的组件，会给系统来极大的灵活性。这样做出来的组件，才可以“大成若缺，其用不弊”。