底层的困惑

    这半年一直在忙，忙着加班，忙着被领导叫去修修改改，忙着被上层的开发人员问东问西。

    这个的项目应该算是个大项目，70多人的样子，国家电网的C/S的GIS系统。所以从数据模型到业务需求有了渐渐清晰的认识，从系统架构到各个模块积累点设计的经验，从底层接口到上层引用学到了一些沟通的技巧，从STL到模板扎实了一些语言基础。。。

    每天早上来的第一件事都会打开程序跑跑，测试下自己写的几个上层功能组件的可用性和易用性。每天打开程序review一遍自己的程序，看看是否能读懂，还有没有修改的余地（但很多时候看到代码总是带着一种成就感。。这显然是自己太容易满足了，这个需要以后注意，要谦虚谨慎。。。）

     说了那么多废话，其实今天想说的是，做了一段时间底层的代码，发现沟通才是底层接口设计过程中最重要的一个环节。整个系统的开始不算是并行的。当底层的平台支持组件比如DB，VIEW等已经开始开发的时候，上层的应用功能比如电力设备改接，电力设备拓扑分析展示等组件还处于与客户的需求收集阶段。这个时候我没有和上层开发人员进行沟通，以自己预想的功能需求设计出一些通用的接口，预想的意思是：举个例子DB组件，一般情况都会提供OpenDB，CloseDB，ExecuteSQL等通用的组件出来，因为任何系统在访问数据库都需要这样的接口。

     但是在上层组件开始设计和编码的时候，我又没有及时的和他们沟通需求，造成他们有一个需求的时候，经过讨论我就为其增加一个接口，另外一个人有个接口需求，我就再为其增加，到后来接口越来越多这时候我开始觉悟到这些接口的管理开始变得臃肿和复杂。更有甚者有些开发人员不来沟通翻查了我提供的所有接口没有找到想要的后自己动起手来写了一些访问数据库的代码，这就可能造成对数据的管理没有通过一个单一的渠道来而导致数据经常出现不一致或者数据库死锁。

     底层开发过程中我错误的以自己为中心，将自己臆断后设计的接口作为一本手册，上层开发人员按照这个手册去开发，会出现许多效率损耗的问题。例如：一个四角的关系

                            PraentA ---------------ParentB

                                 |                               |

                             ChildA                        ChildB

     假设组件只有2个方法：

                          QueryChildBByChildA(ChildA, &ChildB)..也就是通过他老爸找到他朋友的儿子。

                          QueryChildByParent(Parent, &Child)..通过父亲中道儿子。

    而客户有个需求是当前只有ParentA，要想给他儿子找个伴。那么他得调用QueryChildByParent然后调用QueryChildBByChildA，而QueryChildBByChildA内部的实现是ChildA找到PraentA ，然后再找到其朋友的儿子。反复查询损失效率，如果直接提供接口QueryFriendByPerson（person， &Friend），那么直接调用QueryFriendByPerson和QueryChildByParent，就没有走多余的回路。

     通过我在学习上层开发人员的代码的时候我发现了很多因为接口问题走回路的情况，造成很多地方效率损失了，实在是罪大恶极啊！

     总结：底层应当将上层的开发人员作为客户，需求分析阶段应该放在在上层开发人员与他的客户需求分析之后。而且要多主动的与他们进行沟通，以客户的需求为中心随客户变化而变化。