信息系统，分层不要过多，静态方法也可以考虑适当多用

又是很多年前，我们公司第一次用C#.NET 写程序，大家积极性都非常高，研究技术也热火朝天，当时公司里有几个高手，的确不服不行的那种，在当时的环境下什么分层什么的搞得特精通，连WebService等时髦的技术，没几下都搞明白了，公司按最牛X的技术方式，最合理的分层结构，设计了崭新的系统，大家都觉得非常满意，怎么讲都有道理。

 

   结果所有的层加在一起，好像有5-6层吧，一层套一层，中间全部是用WebService桥接，所有的方法，都通过调用WebService来访问，大部分处理逻辑也都写在服务器端，就拿现在的技术准来讲，也不差到哪里去的。

   大家开发了好几个月，东西是出来了，但是中间发生了很多事情：

   1. 大部分程序员，都无法深入理解技术架构，只是照葫芦画漂，根本没深入体会人家的用意。

   2. 当时没有众多成熟的第三方组件好选择，很多页面上的控件都自己做，效率比较低。

   3. 写了N多的接口，每个层都有，有一个地方有变化，至少要修改5-6个地方，累得要死，天天改来改去的。

   4. 中间调用了WebService，程序一运行慢得要死，比原来的VB程序还要慢很多很多。

   5. 崭新用了C#语言，大家用法也不熟练，做出来的东西不稳定，错误很多，一直无法通过测试，修改个没完。

   6. 新开发的东西又无法端时间成熟，上市销售，老的系统又需要维护升级，有限的开发人员又被拆分成了2波队伍，谁都想学新技术，都想放弃VB的老系统。

 

   结果几个月下来，新系统没能成功上线、老系统又没能集中精力持续改进，给公司造成了重大经济损失，几十万以上甚至几百万的损失吧，最终公司元气大伤。

我想说明的意思是

   1：玩新技术是要有代价的、有风险的。

   2：准确的定位决策能让一个公司发展壮大，错误的决策能让一个公司破查。

   3：写程序不要分过多的层，除非是有必要。

   4：客户要啥，我们做啥，只要能满足了客户的要求，越简单越好，虽然是最笨的最简单的饿，但是往往是最见效的。

   5：客户花钱想购买的东西，往往不是开发人员天天在开发的东西，也不是开发人员天天在着迷的完美系统架构，客户就想要个好菜刀而已不是原子弹。

 

   很早的时候，由于对C#的语法，经验也不够深入，都做了很多接口，方法什么的虽然都是可替代的，但是都是动态方法，非Static的，也没有什么单一实例什么的，程序的运行速度总体上来讲就会很慢，我这几年也经常比较，为什么我的系统总是感觉运行速度慢？

   static 的方法，在不影响并发问题、不存在并发冲突的情况，明显会速度快很多很多，反复new一个类，自动回收一个类的整体速度，还是没有Static来得快，以前排斥 static 的方法，整个系统里技术没有一个static的方法，几年后，再看看手上的代码，不时的会碰到 static 方法了，也不怎么排斥 static 了。

 

   工作累了，就想到什么写点儿什么，免得忘记了，烂在肚子里了。

 

   一个公司往往狂热技术研究时往往离走向下坡路不远了，公司里天天都有人在学习技术，离走下坡路也不远了，我们的研究技术应该依附于客户的需求推动时，离客户的实际需求不过分遥远时，才能派上最大的经济价值。

   客户是我们的衣食父母，能满足客户的要求，有客户在需求，技术成果才能变成RMB，有了RMB就可以更安心去研究技术，我们为客户服务，客户为我们支付RMB，也就这么回事，你天天在研究没人愿意购买的，没市场的东西，就像是在月球研究原子弹一样，研究出来了，谁要？干啥用？月球上没潜在客户啊。

   

将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情

。