考核系统快结束了，将此项目的经历回忆如下，也小结一下，先谈这个项目中值得提倡的地方：

1、在开发之前进行了完整的需求分析，形成了系统的需求文档，需求文档中最有用的部分感觉就是界面原型，还有系统的菜单，这样给了用户一个初步的直观的印象，同时文档中的一些对于界面原型的描述以及计算规则等内容在后期的开发中也起了指导作用。

2、在需求分析完成之后，进行了概要设计，包括完整的数据库设计，这样在后期的开发中对数据库表结构方面没有大的修改了，只是添加了一些表和视图。

再谈谈项目中的缺点吧：

1、首先就说说需求文档，虽说需求文档写了很多，大概有100页左右（word），但由于一篇文档中集中的内容太多，对于用户来说只是关注了界面原型，系统菜单等部分，对于其它内容用户关注度不高；同时由于篇幅太大，开发人员打开查看或者后续修改也比较麻烦。

对于以后的需求文档是否可以这样编写：首先有一个正文，正文中包括大纲，然后将每一个具体的需求放在单独的一个文档中，最好能类似html链接那样，这样查看也方便，也一目了然。

原来用RobotHelp写过帮助，照此看来，岂不可以用来写需求文档了，呵呵

2、再说数据库设计，还不够细致，很多应用场景由于设计的不够细致，导致数据库表也有所欠缺，因此对于以后的项目设计有两个注意点：

a、加强应用场景设计，具体可以用流程图，甚至序列图描述清晰的业务流程，完善数据库表设计。

b、要求一定先修改模型（这里指PowerDesigner中的数据库设计），然后再去修改POJO类等具体代码，最好不要先改代码，再修改模型，这样难免会有遗漏，时间久了，就会导致模型和代码的不一致，慢慢的，模型文档就没有人看，也没有人维护了。

c、顺便提一下，模型文档的好处一是方便后来者，二是可以方便的导出数据字典。

3、对于命名规范没有在开发前考虑全面，虽然在开发前对命名规范有一定的规定，但是不够全面，造成了后期开发中各人各人的命名有所偏差。

4、分层架构中的dao层和service层处理的不够好，导致service层实际上是混杂了dao和service的功能，业务代码不够清晰。以后的项目考虑dao就是dao，提供数据访问的操作，service层则提供业务处理方法，service与dao的关系应该是多对多的关系。

5、考核系统中使用了JSF/Richfaces做为表现层，好像不太好使，经常会出现多次重复访问方法的问题，后续还需要加强对JSF的学习，避免类似问题。另外Richfaces在生成大数据量的页面时，一个表格有1440行数据，页面巨慢无比:(，后来没有使用RichaFaces的表格，直接使用jstl+html标签，速度倒是很快。

6、项目中的日志输出、异常处理不够明晰，这个和命名规范一样应该在项目开始时给出清晰的思路，在具体开发中应该经常检查。

具体内容参见如下链接：

http://www.javaworld.com.tw/roller/ingramchen/entry/2005_9_20_JBossSeamKingofStateful_

今天在http://refcardz.dzone.com/上下载了《Getting Started with Hibernate Search》，乍一看标题，以为是讲如何使用Hibernate进行查询操作什么的，下载好以后打开一看，原来是Hibernate集成了lucene，用来对自己的数据库进行全文检索，真是厉害！

没有仔细研究具体内容，先记下一笔，日后有时间时，可以实践一把。

    Template设计模式主要适用于需要按一定的步骤执行的场合，但有的步骤在不同的场合执行的内容有不相同。如下类图中的TemplateClass中的execute()方法会按照如下的顺序进行调用：

public void execute() {
    step1();
    step2();
}

    但由于step1在不同的场合执行的内容不一样，此时就将step1设为抽象方法，在TemplateConcreteClass1和TemplateConcreteClass2中分别实现，这样就形成了Template设计模式，step1()方法也称为模板方式。

    类图如下：

   

1、在菜单中选择“Weblog”，然后选择“Another Weblog Service”。
2、在Weblog Homepage URL中输入你的Blog主页地址。
3、输入用户名与密码。
4、在“Type of  weblog that you are using”中选择“Custom(Metaweblog API)”。
5、“Remote posting URL for your weblog”中输入“http://www.cnblogs.com/用户名/services/metaweblog.aspx”。

具体过程参见：http://coenraets.org/flex-spring/

简要描述一下：
1、首先要继承FlexFactory，实现Spring与Flex的集成，上文中已经提供了具体实现，下载即可。

2、在web.xml中配置Spring，如下：
   

3、在service-config.xml配置文件中添加
   

4、修改remote-config.xml中原有的destination配置，原为：
       
    修改为：

      
1、使用HTTPService
    使用HTTPService可以直接访问ASP.NET、JSP、Servlet、PHP等页面，此种方式最为简单直接。

2、使用WebService
    使用WebService可以直接访问互联网上各大公司提供的WebService服务，该种方式对做互联网应用开发可能用的比较多。

3、使用RemoteObject
    此种方式可以直接访问Java Class的method，可以采用此种方式构建 Flex + Spring + Hibernate的应用。

4、使用Message
    此种方式弥补了WEB应用的缺点，使得浏览器和Server端可以进行双向交互，可以用于构建复杂的C/S方式的企业应用。

不同方式的具体访问方法在BlazeDS的Test中都有样例。

第一、第二种方式不需要服务端有特殊设置，只要客户端能够解析服务端返回的信息即可。
第三、第四种方式需要使用BlazeDS进行配置后方可使用，或者使用ColdFusion。 至 http://opensource.adobe.com/ 可以下载BlazeDS，下载后解压至本地。

BlazeDS includes the following Web Application Archive (WAR) files:

• blazeds.war - The primary BlazeDS WAR file: use this as a starting point for building your BlazeDS application.
• samples.war - Sample BlazeDS applications.
• ds-console.war - Simple monitoring application for BlazeDS deployments.

在访问BlazeDS的Sample前，需要首先运行install_root/sampledb目录下的HSQLDB数据库，运行方式为启动startdb.bat脚本

然后启动tomcat，即可访问http://localhost:8400/，体验BlazeDS了。

如果没有下载tomcat和BlazeDS的整合包，直接安装BlazeDS的话，对于不同的应用服务器需要进行一些额外的配置，具体参见如下链接：

http://opensource.adobe.com/wiki/display/blazeds/Installation+Guide

    今天忽然想到这个题目----快速高效的开发软件项目，将个人的一点体会记下来：

1、需求分析要做的充分，使用原型法和用户进行沟通，这样可以更好的把握用户需求。

2、架构设计一定要做，解决项目中可能遇到的难点问题，其实架构设计也可以看作一个抽象的过程，从系统需求中抽取出共性的内容，然后进行设计。

3、多周期迭代，每次迭代的时间控制在两个星期至一个月，每次迭代结束后一定需要进行测试。要牢记项目经理的职责不是编写代码，不是关注编码的细节，要有全局观，与用户要有良好的沟通。

4、困难的问题、基础的问题要先解决。

5、要有测试人员全程参与，并且测试人员对项目的目标、范围、质量要求与项目主管、用户理解一致。

6、确保开发人员理解需要解决的问题后才进行开发，可采用复述法、提问法确保理解。

7、不要采用大家不熟悉的技术，如果采用，那么需要对该技术尽早预研，并开展培训工作。

8、建立一个强有力的、关系融洽的团队。团队中最好能有一个技术高手，最好能有一个活跃气氛的人。

9、确保能够有效的沟通，尤其是后期测试人员参与集成测试时。

10、不要把项目时间排的很满，要留出机动的时间和资源。

11、对项目组成员能够进行考核奖励。

12、没有完美的产品，只有合适的产品。

13、项目启动前就编码规范、沟通方式、在项目中采取何种管理方式等与项目组成员进行沟通。项目组每周召开简短的例会，讨论完成情况，分析存在问题，交流沟通其他技术问题。

14、不能姑息项目组中犯错误的同事，有问题要指出，方式要恰当。

15、最后一点，不要拘泥于形式，要能够洞悉项目中已经存在、正在出现、即将发生的问题和风险，并采取适当的方法去解决，最近很喜欢孙子兵法中的一 句话“故兵无常势，水无常形。能因敌变化而取胜者，谓之神。”。当然这不是说各项知识不需了解，仅凭感觉，这样是做不好项目的。

1、专注于构建一个强有力的团队，这一团队能够解决困难的问题，并为客户创造真正的价值
    团队的定义：团队就是一群拥有互补技能的人，他们为了一个共同的目标而努力，达成目的并固守相互间的责任

2、领导者鼓舞；管理者授权。要同时成为优秀的领导者和管理者，你需要就愿景进行沟通并理解其细节。

3、对可能出现的障碍有所准备，防微杜渐，在这些障碍尚未壮大时就清除它们。

4、花时间来仔细倾听别人的意见，但不要过于担心其他人的想法。

5、专注于事实。

6、充当一个衰减器，而不是放大器，为团队提供稳定性。

7、永远不要将不能解释的事情归咎于蓄意破坏。

8、培养幽默意识来作为严肃认真的一种平衡；对于工作一丝不苟，对自己轻松自如。

9、除了工作，还应该懂得享受生活，而且每年要读25本书。

10、相信你的直觉：如果你感觉不妙，那么很可能预感就会成真。

摘自《软件开发的边界-管理成功的项目》

如何编写高质量的Java代码：

1、  养成良好的习惯及良好的编码风格，比如当有代码没有彻底完成前，通过TODO、FIXME等方式进行标注，比如良好的命名规则、注释、行间距等

2、  秉承设计模式的一个基本原则：单一职责，一个类不应过于庞大，如果过于庞大，则应分解

3、  避免Ctrl+C、Ctrl+V，当发生这样的事情后，需要进行重构

4、  要敢于重构，敢于重构的一个质量保证手段就是要对代码进行充分的测试

5、  注意异常处理、注意事务控制的范围

6、  遇到问题不能总是求助于Google、其他同事，要自己能够分析问题，解决问题

7、  不能仅仅满足于编码速度快，要时刻牢记需要编写的是高质量的代码，易于维护的代码。一定要深刻理解高质量、易于维护。高质量就是说代码需要在各种情况下都能正常工作，而不仅仅是正常流程no problem，易于维护就是说如果换了一个开发人员来修改代码，是否能够很容易的阅读代码，理解代码，还是他会觉得这段代码无药可救了，重写是最佳选择，如果是后一种状况的话，那么这段代码就是最糟糕的了。

 

以下为摘自IBM <Java代码质量专题>的一段话：

高质量的软件通常具备了这样一些特性：

• 满足用户的需求。
• 合理进度、成本、功能关系。
• 具备扩展性和灵活性，能够适应一定程度的需求变化。
• 能够足够的强壮、足够的鲁棒，能够有效的处理例外的情况。
• 保持成本和性能的平衡。
• 能够可持续的发展。

 

    首先需要明白的是，什么是架构设计，看了以前的培训资料，也google了，也自己想了，总结下来：

    架构设计：软件系统是由组件以及它们之间的连接关系组成的，同时架构设计还要满足软件系统的易变性、可扩展性、可维护性等特性。

    搞清楚了什么是架构设计之后，再想想怎么才能做好架构设计呢？

    架构设计可大可小，回顾一下自己做过的项目，细想再小的项目其实也有一个架构设计，只不过这个架构设计可能很小，三言两语就能描述清楚了，比如一个很小的BS系统，可能也要划分一下，功能模块如何划分，哪些是公用的，目录或package如何划分，这个我觉得也是架构设计。

    但是当系统变大时，架构设计就变得复杂了，因为需要考虑的东西就多了，一方面从系统的功能来说，系统功能点已经上百成千个了，光是搞清楚这些功能点就已经不容易了，如何从这些功能点中发掘共性，划分组件，如何设计组件之间的联系，实现分而治之就更复杂了，另一方面，系统变大了，系统的非功能性需求或约束更多了，一个小系统，可能不需要考虑大用户量、并发、大数据量等问题，但一个大系统，即使用户不提这些约束条件，一个好的项目经理或者架构师，必须替用户考虑这些约束条件，有几年的数据以后，系统会不会变慢，采取什么样的方式可以解决这样的问题，用户如果要求5秒内，系统必须有响应，那么目前的架构设计能不能满足这样的要求呢？

    同时从软件系统的架构与建筑设计的类比来看，一个建筑设计，必定是先把建筑结构定下来，然后再按图施工，如果想有创新性的设计，则必须广闻博见，同时还必须功力深厚，否则怎么设计的出鸟巢呢？呵呵

   同样对于一个软件架构的设计者来说，第一个层次，丰富的实践知识，达到这样，至少在一定的范围内可以依葫芦画瓢了，同时还可以有一些局部性的创新设计。
   第二个层次建立在第一个层次的基础上，广闻博见，精通十八般武艺，无论哪种兵器都能使得很趁手，比如BS架构很熟悉，CS架构很熟悉，银行系统的架构设计做过，电信系统的架构见过研究过，嵌入式系统的架构也熟悉，操作系统、数据库等基础知识那更是不用说，至少熟悉多种主流编程语言，还能紧跟潮流趋势，更要有自己的思想，理解能力深厚，这样的大师我想应该能做出创新性的设计了。

    回顾一下自己，只能是第一个层次了，其实第一个层次也不算很好，第二个层次只能算刚刚入门，看来要成为一个大师，很难，@_@



今天将以前参加的一个架构设计的培训教材拿出来又翻了翻，忽然发现当时培训的教材其实是按照RUP的开发思路来安排的。
首先来看看RUP的核心工作流，分别是：

• 商业建模（业务建模）
• 需求
• 分析与设计
• 实现
• 测试
• 发布
• 配置与变更管理
• 项目管理
• 环境

后面几项与架构设计的关系不大，重点看前面几个：商业建模、需求、分析与设计。
回过头来再看看培训教材的大纲：

• 架构师必备的全局观
• 架构设计导论
• 架构设计过程概览                 
  
• 需求分析                          ---- RUP ---- 需求
  
• 领域建模                          ---- RUP ---- 商业建模
  
• 打通软件需求到架构师设计之墙      ---- RUP ---- 需求、分析与设计
  
• 概念性架构设计                    ---- RUP ---- 分析与设计
  
• 细化架构设计                      ---- RUP ---- 分析与设计
• 非功能需求设计方法论              ---- RUP ---- 分析与设计（重点在非功能需求的架构设计）
• 架构验证                          ---- RUP ---- 分析与设计（重点在验证）
• UML实践指南
• 面向对象架构设计
• 架构模式实践
• 框架技术实践

除了实践部分与前面概要性的部分之外，其余部分基本可以对应起来。

有时候，会觉得写小说是件容易的事情，设计好大纲，一篇一篇往里填充不就行了么，但是换做真的是自己动笔的话，确万万也写不出来。
架构设计也是如此，简单点说是如此简单：熟悉需求、商业建模、分析与设计。但是真的遇到一个需要实现的系统时，确发现千头万绪，要想做一个好的架构，不是一件容易的事情。

要想做好架构设计，重点还在一个分析，学习架构设计也是如此，那就是得分析开源框架、别人的代码为什么要这么做？要分析我从中可以体会到什么？
架构设计师的知识面一定要广，否则应用面就比较窄了。

说了半天，回头一看，乱七八糟，其实最近在琢磨的一个问题是，如何才能搞好架构设计 ^_^

再想想，这是一个长期工程，需要不断的分析积累。


今天假借儿子的名义买了个变形金刚，了却了多年的心愿，哈哈

在startup.sh开始处中增加如下内容：

declare -x CATALINA_OPTS="-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8788"

然后启动Tomcat即可。

windows下是增加如下内容：
SET CATALINA_OPTS=-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8788


在终端中切换到root用户，然后执行如下命令：
yum install scim scim-lang-chinese scim-pinyin -y

安装完成后，注销再登录系统即可。
时间过的真快，上次写随笔已经是四个月前的事情了。

四个月过去了，有什么进步呢？但工作还是要做，不知什么时候是个尽头。

 使用flash.utils.getDefinitionByName()函数可以根据类名创建类的实例，具体可以参照API文档。 今天看了《最后期限》的前几章，好书！ 今天才了解到，Hibernate3.2已经全面支持EJB3.0中的JPA规范。

看来对新技术了解不够，只顾了看EJB3.0的规范了

感觉Hibernate3.2全面支持EJB3.0的规范对于EJB3的推广来说是件好事，至少在ORM这方面，一般程序员积累的经验可以很快速的适应EJB3.0的开发。只要继续加强对EJB容器、事务处理等方面的学习，就可以对EJB3有全面完整的了解。比起以前EJB2.1和常用技术的格格不入而言，真的是很大的进步了。