工作上的一些感悟和困惑,向benq赐教

  在J道时间呆得久了,就越发得对公司现在的开发现状感到痛心和无奈。对自己得前途也不自觉得感到非常的担心。

  我在一家专门从事电信行业开发的软件公司的工作。公司开发的项目主要采用得架构是前台用JAVA做开发,后台服务用pro C做开发,通过weblogic,tuxedo作中间件。到今天入职已经有快半年得功夫。自己对面向对象的编程思维特别得感兴趣。刚入职时因为也不知道公司的架构还有工作安排,只知道或者选择作前台JAVA或者作后台服务,做C方面的开发。凭着自己的兴趣,选择作前台JAVA的开发,希望可以多去积累在面向对象领域开发的经验。项目参与了不少,但在公司这半年,项目参与得越多,就越发得感觉离面向对象的编程走的越发的远了。项目参加得久了,多半一个项目下来都感觉很痛苦,每个项目都没有任何扩展性,重用性可说,自己看着自己开发得东西,只能感觉揪心的痛。即便只是去作两个省同样得一套系统,需求可能只是些微得区别,但从底层架构到上层的业务逻辑都只能是在无止尽得CTRL+C,CTRL+V完成,加班那是家常便饭,因为客户需求一旦变化,小则重改代码,大得话一群高工就开始重新设计表结构。最令人头痛的事是最近参与得一个项目,公司因为安排不过来人手,把我调去作C开发,可能因为骨子里十分抵触作C的开发,怎么弄都打不起精神,因为我实在不想让自己编程思维在面向过程开发的这个泥潭里陷得更深,但没有办法工作总要继续,所以硬着头皮也要向泥潭深处走去。而且公司一直都是认为做pro C后台服务做久了,才能对电信的业务有很深的认识。但我怎么都觉得,那种需求感觉就像是他们自己凭空创造的,一些高工坐在一起,就客户的某个描述得模糊得需求在琢磨该用哪些字段,该去关联哪些表,如此反复,尽管不可否认,他们对业务确实相当熟悉,该用哪些表特别清楚,SQL写得真的很溜。

  现在的我感觉脑子总是在进行搏击,面向对象和面向过程成天相互折腾,主观意识上在极力排斥面向过程得开发思维,但被动得又得去搞一些面向过程开发得工作。尽管每天都尽可能挤一些时间出来学习设计模式,学习领域建模。我现在特别困惑,不是特别清楚该如何让自己能够在正确的路上继续走。每天也很着急,可以拿来学习得时间总是不多,每天都看着自己在用JAVA做面向过程得编程,想运用面向对象的编程的机会少之又少,倘若一下调去做C开发,就更是反道而行。可我自己想借着电信行业的开发能够深入了解这个领域,但我难道真的也要回到以数据库为中心编程的老路,像他们一样做一个写SQL得老手借以了解业务吗?真的不想,因为我很不希望离面向对象的道路渐行渐远。Banq请告诉我如何能够在这样的公司积累项目经验,同时又能在面向对象的道路上继续坚持走下去。

  我热爱软件开发,但看着周围得很多朋友就是因为在不合理得路子上走得深了,成天都被一个个项目加班(11,2点真的是家常便饭)拖得精疲力竭,然后选择转行,大家都只有一个观点“软件开发做不长久,顶多做到30岁,一碗年轻饭”。但我觉得软件开发是一个可以做很长久的行业,可我似乎也无力去说服我的朋友。

首先必须肯定,你工作的系统是一个复杂大型系统,是一次难得的对你的锻炼和挑战机会,所以要珍惜。

OO不一定要采取OO语言,OO是一种思想,所以,采取OO思想还是可以对过程性系统进行改造和设计,打个比喻Javascript是一个过程性脚本语言,但是AJAX诞生后,就采取组件封装等OO思想对其改造,以至于编程JS可能写得代码都不多,完全是组件积木式的拼装,这实际也部分达到了OO目的。

在这方面做得比较切实可行的就是EJB2.0技术,EJB2曾经被Spring之类新OO派指责带有很多过程性编程思路,包括它的Session Facade以及实体Bean等等,但是EJB2很早就提供了一种连同数据表打包在一个jar包中的组件构件实现方式,从而能够实现大型数据库系统的组件化积木拼装开发,虽然EJB2这种组件开发还存在各种问题,但是它顽强地启动了一个新时代的开始:构件化时代。

所以,构件化开发对于你们目前系统是一个切实可行的思路,在你熟悉原来的复杂业务核心后,可以进行适当重构和改造,当然不是一定要采取什么语言什么技术,而是象构件封装这个方向去努力。

要做的事情很多,千里之行始于足下,既然你没有生在一个空白的系统环境中,那么就好好利用现有环境的锻炼机会,顺势而为;就算你生在一个空白环境,你有OO和Evans DDD,当时不知如何具体实现,也是空的,Evans DDD其实是一种实践性很强的方法论。



[该贴被banq于2008-03-27 10:49修改过]

assassinph

你的困境和我一样。。。。

恩,谢谢banq的指点,我会向构件封装这个方向去努力。的确是,千里之行始于足下。我也感觉要做的事情很多。。

在您的提示下,一条感觉还算合理的方法就是无论让我去用C还是JAVA做开发,都应该借着开发过程去深入了解核心业务,然后去思考如何以面向对象的思维,以Evans DDD这样的方法论为指导向着构件化+封装性的方向进行适当的改造,以期将这种过程性系统重构具有面向对象的特性,在这个过程中也促进自己在面向对象理解和应用上的积累。
[该贴被assassinph于2008-03-27 23:37修改过]

其实象遇到我这样状况的人应该不少,不过真正去寻求改变的似乎不是很多。

呵呵。留个联系方式,多多交流。。

QQ:823238014

benQ,给我的感觉更像是个教育家,一个聚集了技术与人生哲理的教育家。

其他方面不说,楼主的语文水平得提高下才好。

向Benq“赐教”,赫赫,再斟酌斟酌。

可我自己想借着电信行业的开发能够深入了解这个领域,但我难道真的也要回到以数据库为中心编程的老路,像他们一样做一个写SQL得老手借以了解业务吗?真的不想,因为我很不希望离面向对象的道路渐行渐远。Banq请告诉我如何能够在这样的公司积累项目经验,同时又能在面向对象的道路上继续坚持走下去。
---------------------------------------------
LZ是认为做电信行业只能走以数据库为中心编程的路,还是觉得做电信行业只能在OO的道路上渐行渐远呢?

我不清楚你们是做哪方面,据我所了解的,电信行业的系统并不简单,你上面说的那种系统,也许你并没有清楚其架构,据我估计,它很可能是corba架构(当然也许不是corba,但是异构开发平台的集成是corba的擅长点,否则,如果只需要同一语言开发完成也没必要用corba),而且之所以某些部分用C来开发,是基于与电信网络设备交互的需要,你们的系统需要很全面地管理那些网络设备,这又需要你去深入了解电信领域常用的一些通讯协议比如syslog,snmp,tr069等(这些协议在电信与你们进行研发协调时发给你们的文档上很可能有说明,制定方一般是上研院或者北研院),你们需要实现这些协议来支持你们的某些服务,比如说监听设备在线状态的服务,接收设备操作日志的服务,处理设备业务工单的服务等.

而且如果设备数目比较大,这些服务很可能分布式部署(其他地方我不清楚,像上海,如果一个系统来管理上海市电信网络设备的话,常规需要面临200多万设备的支持和管理,你会不会觉得这样的系统毫无挑战性可言?),我个人觉得,在这样的系统里面,至少对你java多线程的设计能力的要求还是相当高的.而针对数据库的操作,只是一些很常规数据的管理,比如说一些系统管理域和企业管理域数据,设备标识数据,客户资料等.而这些部分绝对不会成为你们系统的重点和核心.

有点乱,想到什么说什么,也许上面的任何猜想都是错误的,只是想劝LZ抱着更为全面的心态去面对自己的工作吧,OO很好,
但是你换个心态想想,你没觉得自己的工作内容更丰富吗? 能用java,也能用C,能OO,也可以不太OO,还能把握那么多通讯协议,还有机会接触分布式应用,还可以有机会掌握高并发环境的设计...别人都羡慕不来噢.

楼主的公司是AMDOCS吧?:)