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

   又是很多年前,我们公司第一次用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,也就这么回事,你天天在研究没人愿意购买的,没市场的东西,就像是在月球研究原子弹一样,研究出来了,谁要?干啥用?月球上没潜在客户啊。

   

将权限管理、工作流管理做到我能力的极致,一个人只能做好那么很少的几件事情。
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页