码迷,mamicode.com
首页 > 其他好文 > 详细

我的软工之路——2013.9到2014.9总结

时间:2014-09-21 19:50:31      阅读:396      评论:0      收藏:0      [点我收藏+]

标签:年终总结   soa   esb   项目总结   oracle   

每次写年度总结,也就是更新自己简历的时候。把有意义的项目加在简历后面,把自己新学到的技术加在后面。在感叹岁月流逝的同时,总想抓住点什么,留住点儿什么。这时候,需要做的就是做总结。不总结就是竹篮打水,就是狗熊版棒子。总结下来才会沉淀下来。书阅读越薄,就是这个道理。


技术学习

Maven

Maven的学习,是从一套Maven视频开始的,视频看完之后还是云里雾里的,什么中央仓库啊,私服库啊,已经依赖关系啊,都没有一个清晰的理解。不过在项目中应用,这些已经足够了。就是很多东西,不是很理解。

然后在GCT入学那几天,以及回来的几天,我研究仔细了一下《maven权威指南》,由于在项目中已经有了应用,再次理解很多概念,就容易了很多。此外,Maven的中文资料也很多,比如争光师兄的博客,就有对Maven的详细讲解;那期间,经常去他那里偷学现成的。还是吃现成的舒服啊!他已经总结好了革命果实,我们直接窃取就好了。

有了Maven,Jar包的管理就方便多了。不用拷过来拷过去,还担心着Jar包冲突的问题。


Oracle

已经有了几年数据库开发的经验,但是在TKY项目中,我同时负责后台服务接口。各种各样的需求要求,需要我们了解Oracle很多特性的东西。尽管我们不会去做DBA,多了解一些还是好的。

比如之前,我们系统测试中,发现备份的数据库,还原后总是缺失一些表,由于是远程调试,我们找了好久才发现,原来是数据的问题(表都没有了,去哪找数据去?)。学习了Oracle我才知道,原来是数据库备份的时候,需要清空Oracle的回收站,这是Oracle的删除机制,回收站有东西,备份的时候就会导致一些相关表无法正常复制。

Oracle的学习也是通过一个视频。由于数据库的内容大部分内容都是相似的,对比MySql和Sql Server,大部分都是学过的东西,过一遍就好了,我们只需要着重关注一下新的知识,也就是Oracle特性的东西。


bubuko.com,布布扣

                                                             (技术这东西,就好像这片竹林,盲目的乱窜很容易迷失方向。要掌握学习的方法)


Ejb

最开始认识到Ejb,是在最开始接触JavaEE规范的时候。那时认识到的是Ejb2.0,感觉就是:繁琐。要想实现一个最简单的Ejb应用:业务类需要继承SessionBean,业务接口继承EjbObject,Home需要继承Ejb的Home接口。这些繁琐的操作,内部逻辑是非常复杂的。而我们想使用Ejb2.0实现自己的业务逻辑,我们就必须委曲求全,默许它的侵入性。

人们对Ejb2.0的怨声载道,给了SSH一个大好机会。而SSH的易学易用,轻量级弱侵入性的特点,非常适合中小级web项目的研发。不过,大和小都是相对的。SSH的缺点还是因为Spring在分布式上的缺陷。


不过,随着Ejb3.0的出现,它极大的改进了Ejb2.0。Ejb3.0重量级,弱侵入性,几行注解就能配出Ejb应用。Spring为了抢占市场,在分布式上做了很多工作。现在,可以说Ejb能够完成的事,Spring也同样能够完成。

我们继续来说Ejb。对于这门技术,我还是选择了Ejb3.0,来进行深入研究。因为它基于自身特点,并借鉴Spring的长处,开发出来的产品。它集成了Ejb2.0的所有功能,却比Ejb2.0更加易用。


为了从宏观上了解分布式开发,我找了一本《JavaEE高级开发》翻了翻,因为书中用到的绝大多数东西,都是GXPT项目中用到的技术和工具,所以,学起来很快,同时它能更使用你用到的那些知识更加系统化。此外为了更加深入的学习Ejb3.0,我又找了一本《Ejb3.0 In Action》,这本将近八百页的英文文章,耗费了我两个月左右的时间。尽管看完了,但是书中好多东西,还是不太懂。只是对于应用过的东西,理解更加深刻了。

尤其是对Ejb的发布订阅模式,有了更加深刻的理解。这对我后来研究Shuttle ESB,很有帮助,这是后话。


现在,我深刻的体会到了一点:我们搞技术的,一定要懂英语。一些比较前沿的技术,只有我们阅读官方网站的官方文档,或者一些技术的英文原著,你才会真正懂得作者的意图,你才会感觉到什么是地道。按照官网上的去做,不敢说一定是最正确的,但肯定是最权威的。

同时,你看官网的资料多了,你都不太想看中文的。因为人家讲的更加系统,很有规律。不像中文资料,杂七杂八。

然而,看官网当然没有搜中文资料来的快捷。如果项目紧任务中,你当然是要以解决问题为首要的,下班之后再自己去逛官网。


Jbpm工作流

现如今,流程管理,几乎在任何一个大型项目中,都必不可少。我选用Jbpm的原因很简单:API比较完整,资料也比较健全,还有一套守宏师兄录制的视频。最开始接触Jbpm,是在OA项目中,项目中使用的Jbpm3.2版本。完成了一套比较简单的公文审批流程。

Jbpm3已经是一个很成功的产品。一方面它支持嵌入式,降低了工作流的门槛;另一方面,对开发人员友好,它有易读的jPDL、流程可测试性和节点行为的可扩展性。我们能够很容易的在流程运行中加入自己定制的行为。Jbpm3面向开发人员,解决了程序的自动化问题。

然而,Jbpm3的作者Tom Baeyens,对该产品的定位就是工作流系统,所以Jbpm3并没有实现BPMS特性。另外就是Jbpm3不支持流程语言规范,它采用了自定义的jPDL。节点的运行期间行为与jPDL里面的定义的节点类型一一绑定,造成了流程引擎与特定流程语言绑定,难以再支持其他流程语言。

所以,我有学习了Jbpm4.3,也就是《jBPM4工作流应用开发指南》这本书。Jbpm4在Jbpm3的基础上,进行了质的改变。为了实现流程引擎与流程语言的解耦合,Jbpm4引入了PVM(流程虚拟机)的概念。解决了Jbpm3中流程引擎与特定流程语言绑定的问题。

此外,Jbpm4还增强了BPMS特性,支持了BPMN流程建模标准。并且,引入了SignavioWeb建模器。

现如今,Jbpm5,和Jbpm6都已经出来了,这些只是了解过一些相关,没有进行深入研究。据说Jbpm5又完全抛弃了Jbpm4的代码,这些还没有时间研究,等项目中需要在深入研究。


ESB(Mule、Shuttle)

ESB是面向服务架构中,必不可少的一部分。GXPT项目中,使用Mule ESB完成了系统间的交互。不过,由于自己没有参与到这一块儿的开发,对Mule没有一个实战的经验。此外,GXPT项目中,只是比较单纯的使用了Mule,并没有使用到它比较复杂的功能,所以我对Mule的理解,比较肤浅。不过,跟着官网,做一些Demo,实现一些实例,基本上也就够用了,接下来的就是在具体项目设计时,应用的问题了。

Shuttle ESB是最近一个项目中使用到的ESB产品。正好我负责这一块儿的研发。项目中把Shuttle ESB作为一个消息路由器使用,用到了Shuttle的全部核心内容,让我对ESB又有了更深入的理解。具体细节我就不介绍了,我会在我的系列博客中继续介绍:Shuttle ESB系列博客

可喜可贺的是,现如今,Shuttle已经能够正常在系统中运行了。


Java开源框架的研究

又是SSH?? 呵呵,没错!在Java Web开发中,SSH是最基础的。所以我们不仅要会用,还要做到精通!所以我们需要深入研究。因为之前做的项目大部分都是基于SSH的,自己也是应用比较多,理论比较少。鉴于这种情况,我选择了看书的方式。由于一直觉得XX In Action系列不错,所以我就选择:《Struts2 In Action》、《Spring3 In Action》和《Hibernate In Action》三本书。根据王鹏师哥讲解的SSH,结合这三本书进行研究。

由于一直是下班时间进行研究。每天也就只有两个小时的学习时间。导致占线拖得很长。《Struts2 In Action》没有什么特殊的东西,基本上就是MVC那一套流程,Struts2内部很多功能,都是扩展拦截链完成的。我们可以自定义拦截器,完成面向方面的编程。

《Spring3 In Action》全面介绍了Spring的注入方式,以及AOP的应用。当然,还介绍了一些Spring很多扩展的功能。我觉得这本书中介绍的东西还是偏实现,想要更加深入学习的话,需要结合官网,看Spring的源代码。说白了,内部也就是配置文件+反射+几个设计模式的应用,没有什么更新鲜的。

《Hibernate In Action》目前正在看,主要介绍的内容也就是Hibernate的各种关系映射、Hibernate的缓存、延迟加载和性能优化等。


项目

OA系统

从技术架构上讲,OA系统是以SSH为基础,主要包含两大块:ACL权限管理和Jbpm工作流引擎。

无论多么复杂的权限管理,无论采用什么技术实现,无非就包括两大部分:授权和认证。本项目中直接基于位运算进行操作。使用ACL能够控制的更加细粒度,可以对角色进行控制,也可以对单个用户进行控制。

另外,这里不采用框架,而是直接使用位运算也有很大的好处:快速、直接和一劳永逸。无需框架那些乱七八糟的配置,直接使用位运算进行控制,速度很快。对于很多相同的东西,你都可以抽象成模板,然后根据需要,直接改造使用就好了。

对于授权,必须由系统提供授权界面,对系统各个模块的访问权限,进行权限设置。而认证就更简单了,包括登陆时的认证和即时认证。登录认证就是登陆时,判断哪些模块儿有权限,需要加载哪些模块儿;即时认证,比如,系统中某一界面的权限认证,就属于即时认证。

对于权限系统,有多种类型的权限,你需要根据具体需求,选择更加合适的模式。同时,你可以使用权限框架,如Shiro。


OA中工作流部分,是使用Jbpm3.2进行实现。完成的主要功能是一个公文审批的流程。无论是版本几,使用起来也就是那么个基本流程:定义流程、部署流程、启动流程实例以及相关操作。这一部分由于业务流程比较简单,没有什么更深入需要介绍的。虽说工作流产品每一个版本,都是基本上推翻原来的设计,从新架构设计。但是它们都是为了解决实际项目中的工作流程而设计实现的,不同点在于内部设计的理念和实现。对外使用的基本步骤是不变的。


bubuko.com,布布扣

                                                            (光说不练假把式,实践才是检验真理的唯一标准)


Jbpm项目

这个项目是我带队从需求部分开始做的。我前前后后翻了好多遍那本《Jbpm4.3工作流开发指南》,研究了工作流的前端设计器,并且用Maven搭建了Jbpm的开发环境,并且跟工作流大牛守宏师兄沟通了开发疑惑。

我定的开发计划是这样的:我们现在众多工作流需求中,选取一条经典的。然后设计出一套流程。整个项目组共同实现这个流程。完成之后,再在此基础上进行扩展,再把工作流做的独立,通用。此外,我们还想实现JIRA中工作流的效果。将工作流嵌入到项目业务中,具体流程由用户自己定制。……

可是,还是自己的原因吧!因为Jbpm工作流开发要求较高,组内成员花费了比较长的学习时间。再到后来,项目还是以失败告终。现在,已经将项目交给九期了,希望他们继续把项目做好吧。我们的遗恨,就交给九期去创造奇迹吧!


GXPT

这是我第一次参与分布式开发,分布式的开发让我受益匪浅。

如今,是拥抱高并发、大数据的互联网时代。诸多传统行业的转型也是顺应时事,以至于很多人说:纯粹的传统行业已经是穷途末路。按照这样的逻辑,对我们程序猿来说,Hadoop、分布式、集群、多线程等等这些技术,已经是我们的基础技能了。如果你还在公司,天天干着枯燥、重复的工作,那我只能说:您真需要给自己充充电了。

写着写着就又有点跑远了,我们来继续谈项目体会。GXPT项目一共包括六个子系统:权限系统(集成单点登录)、jc系统、pj系统、ks系统、Jbpm工作流系统和日志系统。权限系统采用shiro框架。在权限系统中,将每个子系统均看做是一个组织,一个组织中又包含多个资源(多个业务)。每个访问系统的用户都配有自己的角色,角色绑定资源、操作,以做到对按钮级别的控制。

jc系统为pj系统和ks业务系统提供基础信息和基础服务,jc系统和ks系统为不同需求下的不同业务系统,而工作流系统为整个系统提供流程支持。


由于系统要实现分布式,后台服务使用Ejb提供服务支持,Jboss作为应用服务器,分布式事务没有做更加严格的要求,采用JTA声明式事务交给Ejb容器管理。后台的Ejb服务以业务为单位,作为一个细粒度颗粒jar。每一个颗粒都做到相对独立,以冗余为代价,增加系统的灵活性。

前台使用DWZ+Struts2+Spring架构,使用DWZ是因为它是一个比较成形的国产jquery框架,文档当然都是中文的,学习成本低,上手快;使用Spring框架,只使用到了IOC功能。Spring的主要功能包括两个功能:1、struts2中的action的创建交给Spring管理,这个很常用;2、Spring管理Ejb Bean。将Spring应用程序(也就是war包)部署在Jboss中,Spring通过配置<jee:jndi-lookup>元素标签,它能根据Ejb jar部署在服务器的部署地址,查找上来所需的ejb Bean,进而使用ejb服务。

对于系统间交互的部分,将jc系统的对外服务,分发布称Webservice,中间通过ESB进行通信,完成系统间的通信。


因为系统由细粒度颗粒组成,大量的jar包会泛滥成灾,我们使用进行Maven管理jar包,配置私服,设置远程仓库。添加第三方jar包时,只需要在pom中引用即可。Maven会自动在本地查找,如果没有话,自动从私服上下载。

另外,由于我们采用的是敏捷开发模式,要充分发挥工具的作用。我们还使用了Jenkins进行持续构件,一天中Jenkins能够集成多次,从SVN上下载最新的jar包,部署到Jboss应用服务器中,如果集成失败,发生错误,它会通知Hmail服务器,邮件服务器会给对应的开发人员发送邮件。

另外,为了保证系统的查询效率,还是用了缓存。这里无非就是使用了Hibernate的一级缓存、二级缓存以及查询缓存。二级缓存的实现采用第三方的框架Encache。同时,使用Ejb的JMS保证了缓存的同步。比如:系统间的互操作用到了缓存,当jc系统数据发生变化时,pj系统这边的缓存就成了脏数据,这时候,就可以在pj端起一个MDB Bean,监听jc系统的消息,当有数据变化,它就会监听到消息,然后它会清除缓存,重新从数据库查询数据。


本次开发没有采用传统的瀑布是开发,而是采用另一种开发模式:Scrum敏捷开发。敏捷风已经在国内喊了好几年了,但是落实到企业中,国内企业真正使用敏捷开发的公司,却是少之又少。

刚开始接触敏捷开发,我就觉得这种模式很棒。它主张以工具代替写文档,实现快速开发,这点很让我们兴奋,不用花大量时间写文档。传统开发中,说实话,那后来补的几千页的详细设计文档,你真的回头看过吗?当然,敏捷开发并不是不写文档。敏捷开发主张的是只写有用的文档。

这次开发中,也遇到了一些未解决的技术问题:

1、用Webservice进行传输,返回PageModel类型的方法,无法传输成功。WSDL里面的定义都是正确的,猜测与分布式事务有关系;

2、跨域访问的问题;

……


TKY项目

这个项目,我是最为一个研发人员,中途加进来的。业务流程在之前的博客中有所介绍,这里再重新整理一下


首先,一些硬件设备检测到各种数据信息,用C程序进行接收,然后将这些数据发送给C++端。C++端接收到数据后,按照一定的规则,对数据进行分类、加工、处理。处理后,C++端会将一些特定的数据,以windows消息的形式发送给ESB服务。ESB在本系统中,作为消息中间件使用,对消息进行转发。ESB服务端接收到消息后,它会以Pub/Sub的形式,将消息发送给每个客户端,而每个客户端,都会有多个终端显示器。由于是消息是Pub/Sub的方式发送的,而不是Command的方式。所有的终端显示器在启动后都会接收到消息。


终端显示器接收到消息后,它会根据消息,进行一定的处理。处理完后,它需要通知其他所有的终端显示器,它处理完了。如何实现呢?很简单,只需要让处理完的终端显示器给ESB Server再发送一个消息,然后ESB Server再通知一遍所有的终端显示器。


在参与到这个项目之前,老师就告诉我们:这个阶段,对我们来说,最重要的是给自己一个职业定位。不错,就这几个月的开发来说,变化最大的就是自己的心态。

对大多数程序员来说,看着自己写的软件能够按期交付,并且正常运行起来,才是最满足的事情;对于大多数经理,满足领导的各种灭绝人性的要求应该是第一位的,其次才是协调下面的人好好干活;而对于经理的领导(如XX主任)来说,他要做的就是保持系统的领先性。不管系统现在进展如何,他都会对所有相关人员介绍说,我们的系统绝对是国内的领先标准,我们的开发团队都是从XX来的精英组成。……

有一次,我们在给吉林那边的客户演示的时候,公司的董事跟人家是这么说的:我们的系统马上就会实现全国联网,所有局的系统将实现系统共享;我们使用到了全世界最领先的技术。中间使用ESB消息中间件,实现了系统的灵活性。……

我的想法是:你有多大胆,地有多大产。为什么楚云飞能当师长?因为他并没有仅仅把眼光放在自己的358团,而是放在了中国的国防力量上。而我们程序员呢,比较一头扎到代码里,所以容易坐井观天。所以说,要给自己一个积极的职业定位。


项目中,我负责的主要是ESB这一块儿的研发。我在开发中,遇到的一些比较难对付的问题有:

1、ESB源码研究的少,网上资料也少,结果就是ESB在集成时,报的很多乱七八糟的异常,我只能去按照自己的想法,进行尝试。这个摸着石头过河的过程,比较熬人;

2、大家也看出来了,ESB的研发属于中间层开发。我与两头同时进行开发,一旦有人上传上来有问题的代码,我就得启动一堆服务和工具,一点点调试问题出在哪。有时候寻找问题在哪,就会花费大半天时间;

3、ESB消息中间件的研发,不能按照传统开发的思路进行。你需要转变一些思路。懂Ejb发布订阅模式的,可能会更好理解一点。比如说:服务总线实例启动了之后,他才能发送消息,同时,它才能监听消息队列中的消息。这里,它是如何传输消息的,你要寻思明白;

4、启动一个ESB服务总线实例,是需要很多资源的。所以也很花费时间。其实这儿最好放在容器中启动,或者是放在windows服务中才好。可是系统要求在启动的时候,完成服务总线实例的启动。目前的是在登录中启动实例,缺点显而易见:耗费时间,降低用户体验。这一块儿的思路是采用多线程实现。系统启动时,另启动一个线程去偷偷启动服务总线实例,它不影响系统的启动。这就好像是完成Ajax的内部实现。现在还没做这个工作。


其他

自学考试

现在,自己已经是正儿八经计算机系的学生了(毕业证已经发下来喽)。参加自学考试,多学了十几门课程,在宏观上多软件开发又加深了一层认知。同时,更重要的是,锻炼了自己快速阅读的能力,学会了读书的方法。“读烂前几章,后几张烂读”的方式是要不得的,不然读了半天,只能是:不识庐山真面目,只缘身在此山中。读书必须先宏观再微观。它是一个不断丰富思维导图的过程。图的关系画清楚了,理清楚了,你也就会读懂了。


GCT

另一件喜事就是自己已经是研究生了。入学时,尽管惹的袁老师很不高兴,还是挡不住我们对GCT的热爱。看着自己选的课程列表,正是自己比较薄弱的一些课程。一定要抓住这个机会,好好补习一下。


生活

写到最后了,也来谈谈程序员的感情生活。我要感谢生命中有她的出现。她不是一个事业型的女孩,她崇尚自由。我很爱她,也很感谢她。我要感谢她这么爱我。我相信,我们的爱,会是一个死循环,永远的循环下去。

bubuko.com,布布扣


总结

8真是一个神奇的数字。大家的好消息一个接一个,真是为大家感到高兴,四年的努力真的没有白费。真心希望大家都能够突破自己,再创新高。同时也希望自己能够一鸣惊人。另外,我也接到了阿娟姐好消息。你别以为不告诉我们,我们就永远不知道。这是继海燕姐之后,我们八期的另一大喜讯。值得我们为你庆祝、为你祝福。

我的软工之路——2013.9到2014.9总结

标签:年终总结   soa   esb   项目总结   oracle   

原文地址:http://blog.csdn.net/liu765023051/article/details/39251985

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!