追求完美很容易在开发上过度设计 -- 树形结构的设计不仅带来了代码开发量更可怕的是处理相应的复杂逻辑

   经常会想，是不是存在闭门造车问题，是否存在过度设计？客户到底想要的什么？我们做出来的东东是不是客户最需要的、最想要的？我们做到什么程度是客户可以满意的，最低做到什么程度又是客户能忍受的，哪些功能是非不做不可的，必须要达到客户的要求？

 

  把这几年总的感受简单写下来如下：

  1. 相对复杂的页面、用C/S做，比做成B/S的功能至少要快上1倍甚至更多，有些复杂的页面用B/S做非常折腾，特别是操作比较复杂的页面，B/S更适合展示类的、新闻类的、覆盖面广的定位、频繁更新的东西用B/S做是方便，操作复杂业务流程复杂，页面管理复杂的，还是C/S强大一些，意思是说，你若是开发B/S的，那更需要水平一些。

 

  2. 做Oracle数据库的项目，特别是C/S的项目很折腾人锻炼人，可能要多付出几倍，需要严格分层的B/S项目，也照样能锻炼人，工作量也大，因为你不可能每个客户端都装个Oralce，那真的会搞死人，你不想在客户端装Oracle，那就要进行严格的客户端/服务器端分2个部分写程序，一切是面向服务的理念去写程序了，不像控制SQLServer那样，不在客户端装数据库也照样可以访问数据库，可以写个胖客户端，这样工作量很少，代码的量也很少，各种处理都相对简单一些。

 

  3. 采用树型结构的数据、各种页面上的处理、权限上的处理、大数据的动态加载等等，也需要多付出几倍的工作量，有些人做软件效率很快，有些人把问题想得过于复杂，把软件也做得很复杂，那种设计简简单单的，往往各种处理更简单一些。

 

  3.1 按组织机构部门管理来讲，列表型的是最简单的，若考虑到集团公司下有分公司、分公司下有子公司、子公司下有部门、部门下有工作组，这样的处理，还有相应的权限处理、移动、拖动的逻辑的处理等等加起来，估计要比简单的列表型的处理要复杂4-8倍。

  
上面控制代码（1392行代码，写得还算比较精一些，也不少了）

    

  3.2 按模块菜单管理来讲，同样考虑到无限树形结构的情况，权限的处理，添加、删除、移动、拖动的处理，还需要控制树型结构上的右键菜单等等，总体的复杂度也比列表型的处理会复杂很多很多，我也比较过代码量的区别，至少差距5倍的代码量。

  
上面控制代码（1119行代码，写得还算比较精一些，也不少了）

 

  3.3 按操作权限配置管理来讲，同样考虑到无限树形结构的情况，考虑到权限的子权限，父权限等等，总体的复杂度也比列表型的处理会复杂很多很多。

   

上面控制代码（1117行代码，写得还算比较精一些，也不少了）

 

   3.4 一个列表型窗体的代码量对比一下，看看有多少。  

   

  上面控制代码（只有672行代码，而且权限什么的也考虑了很复杂，

   相对来说代码量是1:2，

   程序处理上的难度差别估计至少有1:4，

   将来的扩展性、维护型方面的差距也是巨大的）

 

   若只是有一个列表型的东西，没有树型结构的处理，那是相对来说，比较简单一些，都好处理一些，意思是想说明，只要能不用树形结构就尽量不要用，不要给自己带来没必要的麻烦，很容易变成包袱，你为了比较完好的处理这些，付出的代码代价、细节上的处理代价是 5-8 倍的付出，你的领导未必认可你的付出，你的客户也未必认可你的付出，尽量做得越简单越好，越省事一些。