离坚白--关于层概念的认识。

    本文的一些名词约定：

     产品：视频会议软件的终端实现部分。

   

     最早对层概念的理解是来源于《计算机网络概论》，但非常模糊，看过以后感觉就是那么一回事儿，就那么过去了。

到这家软件公司开发视频会议这个产品。一直在做业务层的程序。当然也包括了vxWorks、Linux两个操作系统上的操作界面。但还是没有感觉到层的具体含义。只是知道当质量组把bug打过来后，我们进行通查跟踪分析，看问题有可能出在哪里。然后再找相关的组进行协调解决（比如，音视频编解码组、协议组、操作系统接口封装组…）。也就仅仅限于理解到这些组提供的接口库有bug，需要修改。仅此而已。

     直道怀着要知其所以然的心态来到音视频编解码组，学习先前同仁的代码，两个周后终于发现了惊天的大秘密，原来这音视频编解码组的工作也是在封装”API”,只不过这些“API”是由音视频算法组提供的各种音视频算法接口以及各家dsp厂商提供的硬件编成构架还有就是操作系统组提供的各种操作系统接口！

极度失望的心情迫使我再来回顾这两年来在这家公司的开发工作，从一个视频会议产品的角度来分析产品的构架时，突然发现了层的影子。一个似曾相识的影子。真是人生何处不相逢，而相逢却又为什么总是恨晚呢？

其实在业务组进行开发时候就已经是在采用层的结构进行处理了，只是自己那时不知而已。那时虽然也参与了全部的设计编码工作，但对于最后的确定方案却是总是认为不是最好的。既违反了面向对象的基本思想。也不是严格的面向过程的组织方式。所以那时就抱着认清自己的位置的态度，抱着对薪水负责的态度，安安心心负负责责的尽自己的全力完成组长交待的工作就行。腹诽归腹诽，但问题却不能从我这里而出。因为项目的失控自有组长负责，但所负责任务开发的拖延或者失败却是自己问题。

很不幸，产品成功了。而且几近完美的成功！这怎么可能？但产品确实是卖到了真金白银、通过了电信通信研究院的认定、在各地的实际招标中也算是力挫群雄，拿到了不菲的订单。 失败的经验总是相似，成功的经验确各有不同。这到底是为什么呢？

于是我申请到了我认为公司最核心小组：平台组！到了平台组之后，分到了音视频编解码组，两个周的代码学习，发现除了封装，还是封装了。直到有一天在绝望中发现了层的思想。莫非这成功和分层的有着某种关系？那分层又对这次的成功有着多大的作用？

仔细想想，这次的成功确实和分层的思想关系密不可分。正是因为分层的思想屏蔽各个开发人员的水平差异，才使得此次开发在二（老员工）带三（新员工）带一（实习生）的情况下取得了成功；分解了核心技术的风险，使得每个人都在没有任何核心技术压力的感觉下完成了一个成功的产品。所以我们总认为我们的产品很简单，直到有一天干掉了华为的产品，抢了polycom的订单！才发现原来简单就是美确实是一条真理。

层是一个横向看问题的过程。是由需求驱动的。一个层的功能实现一般是建立在另一个层之上的，他们之间的联系仅仅是一些接口，一些约定！这在最大程度上阻止了问题的蔓延。比如在UI层能解决的问题就不会拖延到业务层，因为UI层的开发人员并不知道业务层是否会对这些问题进行考虑，同样的道理业务层的问题也不回蔓延到UI层去解决，因为他无法掌控UI层的实现！

层之间的接口，丰富多采，消息、函数、普通类、抽象类等等。只要能完成指的定功能，任何表现方式都可以，这基本上取决于这一层的设计实现人员。但层的功能定义却是由调用者所决定的！但必须明白的是层的接口是属于层的，这和面向对象中接口与实现分离是两回事儿！因为从层的角度来开，一个没有实现的接口是毫无意义的。

当静下心来从宏观的角度再来看周围的软件时，发现竟然都是在使用层结构：物理电气层—操作系统层—应用程序层莫非是因为手上拿着榔头看什么都是钉子？

 

附录：

1．  关于视频会议终端产品的一些数据统计：全产品源代码超过8M、共分为13个独立单元、600多个文件，代码总量超过20万行，其中尚不包括测试代码。

2．  此次开发的人员背景：老员工2：一个在通讯行业工作超过6年，一个在本组工作三年，从事软件开发工作5年；新员工3：一个硕士，刚毕业。两个本科生工作经验2年（刚进入小组时）。三人均无通讯软件开发背景；实习生1：在项目后期到公司实习。作为公司的储备人才，作为产品的初步维护人员。

3．  产品层划分的图示