但是好景不长啊，好日子还没有过上两个星期，公司去年做的一个比较大的项目开始了2期开发，我也被一下拖入了项目中。说起那个项目，公司好多人还心有余悸，据说去年那个项目开发的时候，大概50多号人干了好几个月，每天都是11点以后才有可能回家，周六是铁定加班，周日是看情况，晚上就算加班加到凌晨3点也不是什么奇怪的事情。当时大家都说多来几个这种项目大家就要死了，这次这个项目的2期过来了，大家精神又一次紧张起来咯。一开始照例是项目会议，听完项目经理描述以后，大家也放心了不少，这次虽然说是二期，不过规模不大，只需要15个人左右干一个月就能搞定。主要是把项目一期里面一些地方进行改修，当然也有需要新的画面的开发，不过相对于去年的那块不是很多而已。对我来说这次是个很大的考验，因为项目是二期，项目组内除了我，其他的人都做过1期开发，所以对项目结构都很清楚。这次项目开始并没有什么培训，所以我只能单独看1期的源代码来熟悉项目结构什么的。这个时候项目经理把我叫去要我办理护照，准备这个项目派遣我去东京现场维护。
这个项目是个比较全面比较大的项目，服务器采取了集群的方式，数据量也是千万乃至上亿级别的，所以性能要求特别高。在技术方面用到了很多，使用EJB来控制Transaction，使用了ORM工具来操纵DB数据等等等等。而且由于比较庞大，所以服务器初始化的那块为了Load上去大批配置信息，代码量极其庞大，在权限控制的那块地方，代码非常难以读懂。这也给我一开始的学习代码带来了很大的一块麻烦。不过总算静下心来后把整个项目框架以及实现手法基本摸清楚了，这个时候觉得非常开心，而且对Web应用程序的构造心里面也非常充实，觉得自己已经具备写Framework的初步能力了。
项目是紧张的，基本上每天晚上都要加班到11点，然后打车回家，哈哈，公司报销。而且临近过年，这么加班也一点都感觉不到过年的气息。不过我也不能因此放松了自己的学习。我觉得自己的基础应该算比较好了，便开始啃起另外一本大部头——《Java与模式》。一直以来我对设计模式的感觉就是一些已经成型的，久经考验的代码框架，具有非常好的可扩展能力以及非常好的代码健壮性。不过初学者最好不要看设计模式，因为你接触的代码不多，如果贸然看设计模式的话，会造成不明白为什么这种设计模式好，究竟好在什么地方的情况下就在代码中乱套设计模式，对自己的以后编码发展带来不利的影响。每一种设计模式都有每一种设计模式的特点，自然也有他们自身的适用范围，比如拿最基本的单例模式（Singleton）来说，适合于做配置信息读取器，主键产生器等全局唯一的东西。如果初学者不明白这些，拿单例模式乱套，什么都用单例模式，比如把普通传递数据用的JavaBean也做成了单例模式，带来的恶果就严重了。这本《Java与模式》我是从头到尾认认真真看了，每看完一个模式都会仔细回想以前看的代码哪里用到过这个模式，总会自己想想这些模式适用于哪些地方。因为这个时候我自己编写的代码行数也已经很多了，所以看见这些模式就会特别有感觉。经过50多天的认真研读，所有模式都被我消化了下去，并且使得我的对程序开发上面的认识提升了非常大的一步。顺路说一句，这本书写得非常好，例子很多，但是不复杂，有一定代码编写经验的人就可以看懂了。不过看懂并不是最重要的，重要的是消化下去，用来理解以前看过的代码的精华，这样自己才能得到提高。
这个项目虽然很紧张很忙，不过我还是适应了下来，而且对整个项目结构什么的都有了比较好的整体的把握。项目横跨了整个过年期间，所以在过年的那几天都必须开着手机，怕有什么突发事件要求去加班。签证在2月4日左右送过去签，Leader跟我说因为在过年期间，所以签证可能会比较缓慢，比较难签，不过一般情况下1个月应该足够了。原计划我是跟另外两个同事3月6日去东京，这样算算也差不多。不过中国有句话叫好事多磨，呵呵，用在我身上的确不过分，我的签证3月3日日本领事馆才签，三月四日送到南京。3月5日和3月6日是双休日，所以3月7日签证才送到我手上。由于计划是3月6日派人去东京，所以只好派另外一个身上有签证还没有过期的人代替我过去，这次的机会就算泡汤咯。不过我并不是很在意，因为公司这里去东京出差的机会狠多，特别对于开发人员，据说工作几年后一听到去日本出差就不乐意，毕竟也背井离乡么。
在这个项目的途中，大概在2005年1月底2月初的时候公司也开始进行了制作详细设计的培训，我虽然在项目中，不过也成为了其中一员。这次培训总共大概6次课，每次2个多小时，虽然时间不长，不过把详细设计的要点以及思路和容易出错的地方都说了出来，感觉很是不错，这几次课的培训后，虽然可能要我立即进行详细设计编写还有点困难，不过心里面已经有了不少底，我觉得经过一段时间后的锻炼，我应该可以有进行详细设计的能力了。
3月初这个大项目结束后，本以为可以休整下，不过很快通知我3月7日加入另外一个项目，其实也不算一个正式的项目，属于公司知识库的一个信息查询模块。由公司的一个技术专家负责，那人也就是我进公司时候第一个项目中带着我的那个技术专家，说起来我和他还真有缘，现在我这个项目还是跟着他，而且公司里面唯一一个和我同月同日生的人，真是很巧的巧合呢。他人挺好，很热心，所以我也从他那学到了很多东西。这次由于不是正式项目，所以并没有什么基本设计书，而是他给我们开会议的时候大致说了下项目的内容，每个画面的具体功能以及数据库表格的设计。由于这次项目规模很小，总共就12个画面的量，所以不采取Struts等Framework，而是采用比较原始的JSP + JavaBeans的构造。我们每个人根据他所跟我们讲解得功能写每个人自己分配到的画面的详细设计，其实也不算真正的详细设计，就是每个人把自己操作的那块的具体逻辑设计写出来，然后和他一起review一次，再开始编写代码。详细设计这里我做的很快，当天下午就把自己分配到的两个画面业务逻辑什么的都写好了，星期一布置得任务，我星期三的时候全部编码自测完毕提交，所以我的感觉就好像这个小项目一瞬间就结束了。
日本每年财务结算是在3月份，所以我们历来的习惯就是每年1月和2月很忙，3月开始清闲，一直可以到5月左右会接到个大项目昨。所以接下来就真正到了我的空闲时期，没有项目的压力，我可以自由学我自己喜欢的东西。很久以前买了本《精通EJB》第二版，可是一直以来我觉得自己功力尚浅，所以没有看，这次我想认真学学EJB。虽然大家公认EJB并不是很好，不过历来受到批评的都是EJB中的Entity Bean部分，这部分我觉得可以借助Hibernate来弥补，而会话Bean和消息驱动Bean则还是挺不错的。这次也当学一门技术，学习其好的东西，不是很好的东西就当作以后开发时候的借鉴。《精通EJB》这本书我的感觉是书质量比较好，不过翻译的水平稍微差了点，特别是有不少错误，而且很低级的错误居然校对的时候都没有发现，不能不说是个比较大的瑕疵。但是它不失为一本EJB的好教材。从一开始的JNDI开始，然后讲解了对象序列化，RMI-IIOP等等。这些以前都模模糊糊，或者是看过了但是还不知道究竟有什么用。但是经过这次的学习以后，对这些分布式系统比较需要的东西有了进一步的了解，感觉头脑中比较清晰，究竟RMI是什么样的工作原理，怎样实现一个远程方法调用等等。接下来的EJB学习，自己用Eclipse + Weblogic边看书边动手，写了一个个自己的学习小程序。我个人感觉看书最好就是边看边自己动手写小学习程序，这样比光看不练能学到多得多的东西。学了EJB后觉得脑子又清晰了很多，看见一个案例后头脑中就会有好几种如何解决的方法，几种方法互相在头脑中自己比较，经过这样，大大提高了自己的思维活跃性。
3月中旬开始由于公司比较清闲，大部分人处于没有项目的状态，所以公司举办了第一届全公司范围的编程竞赛。公司只指定了题目为一个日历系统，要求具有日程记事等功能，其余功能自由发挥。这次不再采用团队形式了，而是采取各自为战的策略。自从培训过详细设计以后，我头脑一直有如何写详细设计的思路，这次我自己首先指定了开发计划，保证自己控制自己的进度。接着进行了需求分析，确定了我有哪些功能。然后在自己的基本设计中开始进行数据库结构设计。这次我决定采用Hibernate+Struts的结构进行编写，这样我的数据持久层操作大大简化，而且功能上也增强了许多。DB设计好以后我开始DEMO画面的制作。说实话，我美工水平实在不怎么样，可以说虽然一般网页的效果我都会自己做出来，不过具体网页设计成什么样我还真是一窍不通。还好Dreamweaver我还算算是比较熟练，自己捣鼓捣鼓也想摸象样把DEMO画面给设计出来了，不过美观不美观我就觉得不怎么样了，只是我能力有限，也没办法设计的更好看，这个时候我感受到了一个项目中美工是多么重要啊。下面的详细设计自己写得很开心，把需要的功能都用文字反映了出来，这也算我写成详细设计样子的第一份详细设计了，做完挺有成就感的。接下来首先构筑自己这个小项目的Framework，经过公司两个正式项目的洗礼后，那两个项目的Framework我都认真研读过源代码的，所以我自己有了自己心里一套Framework的构造方法，特别是如何把Struts和Hibernate结合起来的结构，自己有自己的一些想法。在这次Framework构造中，我没有复制任何公司以前的代码段，都是凭着自己对以前看的代码理解后写出来的。这次项目我觉得对自己的提高也很大，首先锻炼了自己详细设计的能力。其次，自己虽然学习过Hibernate，不过从来没有这么样应用过Hibernate，这次让自己大大提升了实践运用的经验。公司由于知道这时也没有一个真正的项目使用Hibernate，所以这时的我也算公司内部Hibernate使用经验最丰富的人了，这也为了后来我协助别的使用了Hibernate的项目解决问题的原因。再次，我这次自己写了Framework，特别在批处理方面，运用了许多刚学会理解掉的设计模式，这些模式让我的程序更具有健壮性和可扩展性，让我在设计方面的能力大大提升了。
这次的编程竞赛我写得比较认真，代码量的确也很大，总代码行数超过了3万行，有效代码行数也在1万行以上。经过公司专家们的评定后，我得到了第一名，虽然没有什么奖品，不过肯定了我这段时间以来的努力，我还是很开心的。而且这次的编程竞赛让我大大增加了编码的熟练度，而且也在其中演练了许多自己想出来的编程技巧，为以后的发展带来很大的好处。
从4月份开始，公司由于比较清闲，所以部门内部开始进行各种培训。我们部门开展了3项培训，第一项就是编程能力培训，第二项是Oracle数据库技术培训，第三项是测试技巧培训。在编程能力培训中，主要就是把原来没有注意的细节采取大家讨论，轮流讲课的方式进行的，虽然其中很多东西我原来都是知道的，不过也有原来不清楚的地方。而且经过了这次互相讨论，更加加深了印象。在Oracle培训中我觉得收获很大，这个Oracle培训采取了传统的上课的模式，由我们开发小组中一个取得OCM的老员工给我们讲解。对于Oracle，我原来基本上就只会写写SQL语句，具体Oracle有什么特别的功能，可以做什么我也不是很清楚。但是这次上课从Oracle的启动原理开始，让我知道Oracle中究竟有什么，Oracle数据库各部分在磁盘上是如何存放的，Control File，Redo File究竟是什么意思，在数据库中起什么作用，数据库是怎么依赖他们运行的，还有如何对Oracle进行系统管理员级别的管理，如何在不停止数据库运行的情况下进行数据库的更新、升级、备份等等。这些东西虽然非常有用，但在平时的开发是学不到的，这次趁着这个机会大大提升了自己Oracle的水平，感觉非常开心。数据库一向是我的弱项，在上大学的时候我SQL语句能力只是一般，数据库管理配置什么基本一点都不懂，通过这次集中的培训，我觉得自己的能力又进一步增强了，弱项也在慢慢退却。在三项培训中最后进行的测试培训我承认我没有怎么认真去学，所以学会的也就是些测试概念，具体的测试技巧什么的还是不怎么会。现在开发和测试的结合性越来越高，看来要下下功夫，以免给淘汰咯。
提了这段时间在公司的进展，还没说自己的学习呢，这段时间正好看见中文版的《JUnit in Action》出版了，在书的背后写着“如果没有看过这本书，就不要对J2EE进行单元测试”这句话。我早在去年就了解了JUnit的强大功能，再加上Ant的话对于回归测试是非常便利的。趁有时间，我便于3月底4月初的时候开始看这本书。当时的我看《精通EJB》第二版看了一半，发现其中错误越来越多，而且文字也有些地方不知所云了，所以扔下不再浪费时间看那本书，专心攻读《JUnit In Action》。凭良心说，Manning的这套In Action丛书的确很不错，从我先前看的《Hibernate In Action》英文版就能看出来，其中对代码的编排非常方便读者，感觉可以很顺利的看到你所想看到的代码片断。这套《JUnit In Action》也是一样，博文视点的纸张还是很好的，排版使用了Manning的风格，阅读起来很舒服，所以我读得很快，大概就两个多星期就读完了这本400多页的书。感觉的确收获不浅，首先，原来的自动化配置工具中只会使用一个Ant，其他的基本没听说过，在这本书上详细介绍了Maven。听过书中的讲解以及自己的试验，的确觉得Maven功能很强大，不过感觉起来配置比Ant要麻烦，所以我自己的感觉是Ant在项目中还是会广泛应用，不过Maven在大型项目，特别是整个Site中有很大的用武之地，对于我们来说，使用的方法都是很简单的，掌握如何编写配置文件才是我们的关键。
书对JUnit与Cactus在J2EE的测试手法上给了大量的事例，给人的感觉非常好，In Action这套丛书最大的优点就在这里，用实例代码片断让你迅速了解一样东西。在实际工作中其实JUnit应用也是比较广泛的，特别如果采取测试驱动开发的话，JUnit是必不可少的一部分。在TagLib测试，JSP单体测试，数据库测试和EJB测试都是我以前根本没有看过的东西。其实这次虽然学是学会了，不过真正做的时候还是要有个代码例子依葫芦画瓢。我想大家肯定也都有这种感觉，写程序的时候先找一段有点相似的代码片断Copy过来，然后看看要修改什么地方，真正从头到尾自己用手写的代码片断是不多的，除非你已经烂熟于心。不过这本书快看完的时候，项目又来了。
这次做一个企业的MIS系统，与以往不同的是，这次客户给了一个比较庞大的基盘，封装了近100个Tag，基本上把各种各样有可能遇到的操作都封装到Tag里面了。而且所有的画面显示等信息都是放在数据库的Table中，所以这次要求不写任何程序代码，只是学会使用好这些Tag，然后利用这些Tag写出Jsp页面。一开始的时候还真是头疼，这些Tag一个都不明白，而且文档不是非常齐全，Tag的Source中注释也比较少，学习起来不是很方便。我们一共3个人投入到这个项目的前期准备中，在第一个星期的学习中大家互相分配好个人学习的模块，随时互相交流。在后来的深入中发现这个项目的业务逻辑操作会使用PL/SQL以及存储过程来进行，对于我来说，PL/SQL是从来没有做过的东西，就叫做一窍不通，于是我需要从头开始学习PL/SQL，以及如何编写存储过程。我从网上下了一个PL/SQL的电子书籍，然后在公司花了一天时间进行学习，个人用的是Toad来调试PL/SQL的，虽然别人喜欢用PL/SQL Developer来进行开发，不过我还是比较钟爱Toad，而且Toad的确功能也很强大，使用起来也很方便就是了。经过第一天的PL/SQL的学习，基本掌握了全部语法以及存储过程的书写格式等等，开始能够写写非常简单的PL/SQL。接下来的两三天不断巩固熟练，客户那里也发过来几本详细设计让我们练习着做一下。有了实际的详细设计，再加上我们之间互相交流，我们提高的都很快，大概过了三四天，大家就把基本详细设计代码编写完毕了，而且经过实际锻炼，我的PL/SQL编写存储过程的水平也大大提升，已经可以满足开发中的需要了。
这个项目因为如果我们一开始做的能让客户满意的话，后续的项目将会比较庞大，所以Leader决定把我们Group比较空闲的其他人也先培训一下，让他们有点感觉，到以后正式开发的时候也能迅速进入状态，负责给他们培训的任务也就交给了我。说起来是培训，其实也就是把大概流程以及方法通过一次会议的形式告诉他们，然后把我前面已经作好的那个画面作为他们的作业，要他们看着设计书自己把画面制作出来。这个时候也要放劳动节了，黄金周可以休息一个星期，想想就觉得很Happy。劳动节的时候基本没有怎么学习，只是先把XML-RPC仔细看了下，学会了如何去写一个XML-RPC的应用，接着稍微看了点SOAP，看得也不错，只是些简单的SOAP的例子而已，那些SOAP的复杂东西都没有看。
很快就五一黄金周七天放假放完，八号开始上班，上班后就开始正式做节前就定好的那个项目，这次性质属于试做，也就是人家先发一批设计书过来，我们然后开始Coding，大概做了一周后，我自己害了急性结膜炎，只能回家休息，这次可真的是只能休息了，眼睛觉得特别涨，不要说电脑了，连书都不能看，看了眼睛就疼。所以在家就只能睡大觉，过了一周眼睛大概才复原，可以去公司上班了。回到公司以后，Leader通知我说我不用去做上次那个项目了，要我加入我们Group的一个新的项目，这个项目比较大，当时还处于东京刚刚做好基本设计，我们从东京把任务接下来，准备发回来做详细设计。我进去的时候项目才开始三四天，基本上还没有做什么，这次我进入了详细设计制作小组，开始进行这个项目的详细设计的制作。
由于我属于第一次在正式的项目中参与详细设计，所以很多东西都不明白，特别是业务上面的东西，许多日语中的业务术语我根本不明白，比如什么卖切，切替，仕入什么的。看着基本设计书，感觉跟以前看详细设计书有很大的不同。具体的东西写的少了，业务流程逻辑框架什么的比较多，所以需要首先把业务内容都熟悉了，才可能写出详细设计来。这次的详细设计我也不是孤军奋战，而是有一个进公司4年的老员工带着我一起做，我的任务很轻，不过重点是学会如何去写详细设计，也许下次再有一个比较大的项目，就没有别人再带着我，而是我自己一个人去完成详细设计了。大概详细设计写了20天左右，我被通知当天把手上的一份详细设计写完，第二天进入方式设计小组进行方式的设计。
进入方式小组以后，接到的任务就是好几个编写DB操作方面的代码自动化生成工具。由于这次DB方面并没有非常强制性的那种规约，所以SQL语句的编写可以说比较随意，这就给我工具的编写带来了很大的难度和挑战。这次负责管理方式小组的人仍然是进公司以后经常带着我的那位技术专家，所以也真算很巧呢。写工具其实很对自身代码编写的提高也很有好处，因为首先客户那里资料会不断修改，这些工具你为了以后客户更新资料后你能顺利更新工具，你需要设计一个优良的Framework，不一定需要多么复杂的Framework，不过一定要尽量把程序各方面的耦合度尽量降低，这样才有利于自己对工具进行扩展。紧接着很快，项目代码编写开始了，我的任务算中等偏上，有2个画面和一个批处理需要编写，复杂度还算比较繁一点。这次项目需要编写JUnit程序，每天都要进行回归测试，保证代码Method的正确性。JUnit虽然自己会用，但是从来没有在真正的项目中使用，所以在真正用的时候感觉有点手足无措。以前做JUnit从来都是觉得给个参数，检测一个返回值就好了，其实不是那么回事，业务逻辑复杂了，自己需要做大量的Stub来模拟真实的Class的返回值。设计一个好的Stub是比较困难的，特别在数据库内容比较丰富的时候，一张数据库Table就有上百个域，工作量可见一斑了。项目要到05年9月中旬才会结束，所以现在还在紧张的开发阶段。我写了JUnit的感觉就是难点不在如何去写JUnit程序，而是如何去设计测试用例。对于我们这样不是以测试出身的程序员来说，设计测试用例是很痛苦而且很艰难的事情，估计有过相似经验的人肯定会表示赞同。
当然我一边在紧张的做项目，对于书本的学习也没有闲着。这段时间抓紧把侯捷的Word排版艺术扫了一遍，看完觉得收获颇丰。虽然我以前觉得我在Word上用得挺不错，日常的一些操作什么的我都会，不过看这本书的中间我发现我还是有很多地方不会的，也学到了不少东西，在以后的Word排版中会很受到好处。由于项目用到了Spring知识，所以我也看了网络上那个流传广泛的Spring开发指南的PDF看了一遍，感觉长了见识，对IOC以及DI有了进一步的了解，也理解了为什么需要采用IOC以及DI。不过这个也没有深入下去仔细看，以后等项目稍微空闲一点的时候一定再把Hibernate和Spring好好看一下，学习人家的设计理念，提高自己能力。对了，也许最重要的是我最近在看一本书，就是《J2EE核心模式》的第二版，我当时原来准备看电子版的这本《Core J2EE Patterns》的，不过突然在书店发现这本书的中文版出来了，而且译者有熊节的名字，也就是跟侯捷一起翻译《重构——改善既有代码的设计》的那个译者，我比较相信他翻译的水平，于是买回来看，虽然项目非常紧张，我一个月算上周末需要加班在100个小时左右的样子，但是我相信时间是海绵里的水，只要去挤，肯定会有的。所以我到现在大概看了2周的样子，已经看了300多页，而且感觉自己的设计视野也开阔了许多，这本书的确很好，把J2EE中常用的一些模块原理都说了出来，说明了为什么这么做好，这么做如何减少了耦合性，提高了可维护性等等，总之，有1年以上J2EE开发经验而且觉得自己对J2EE有了比较好的了解的开发人员我强烈推荐看这本书。看了这本书以后我都在回想以前设计的一些框架，一些模块，觉得自己有很多地方当时设计的时候觉得很精巧，不过却属于弄巧成拙，加大了模块的耦合性，所以在修改的时候比较难于下手。
4716
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
