一个软件项目从开始到结束，由于资源、人员、管理、方法学等等各方面的因素，往往不可避免的会存在一些问题，如需求不明确、项目管理失败、沟通问题等等，今天无意中看到老外写的关于这方面的一篇文章，总结的比较全面，翻译过来结合自己的一些经验做了点补充和修改，存档以备时常可以告诫一下自己。

1. 不能很好的理解用户的需求，缺少与用户之间的沟通。
2. 错误的预估项目的大小和难易度。
3. 没有计划就匆匆开始编码。
4. 没有在项目初期就开始做测试，一直拖到项目后期才做，或者根本不做什么测试。
5. 选择时下最cool的技术还是已经被团队使用比较成熟的技术，往往不能做出很正确的选择。
6. 不采用任何软件过程或者方法学。
7. 没有一个真正的项目经理，让开发人员无计划的主导项目。
8. 拖延计划，把进度压力留在后期。
9. 不做版本控制，混乱的代码库和开发环境。
10. 在项目过程中随意的更换开发工具和环境。
11. 客户的任何需求都答应下来，需求会永无止境，记得学会说“不”。
12. 只有一个大的计划，没有把计划分割成一个个更小的任务，要知道，大的计划如果不分割成任务很难落实和具体实施。
13. 对开发团队的管理不足。
14. 在项目后期增加人员来加快开发速度，很多时候往往适得其反。
15. 开发人员不做单元测试。
16. 一旦项目中遇到问题，就把压力抛给开发人员。
17. 不关注软件实际的运营环境和硬件条件。
18. 没有命名规范和代码规范。
19. 到处都用全局变量。
20. 遇到问题的时候往往不请教别人，而是一个人闷头搞，到最后还是不得以还是通过别人来解决。
21. 没有写代码注释的习惯。
22. 对输入输出的数据不做验证。
23. 不做压力测试，到实际环境中往往就会出现更多的跟环境和性能相关的问题。
24. 项目内部沟通不畅，每个成员只是埋头做自己的事情。
25. 没有很好的bug管理规范和系统，往往用word、email、excel等文本方式来跟踪bug，将会导致整个项目的bug管理陷入混沌。

近年来，随着互联网的迅速发展，伴随而来的是各类Web应用的大量普及，Web2.0、SNS这类概念层出不穷，简单的基于HTML的Web应用已 经不能满足用户的需求和体验，随之出现了flash以及这两年很火的ajax技术。但是这些技术有一个通病，就是还是逃不出浏览器这个大框框，在安全性和 应用范围存在着明显的局限性，比如不能直接操作文件系统，处理声音、视频、图像有一定局限性等等。这时候看出web程序不如传统的桌面程序的一些缺点，如 何既能保留web应用程序的跨平台性，又有传统桌面应用的强大功能，同时保准在开发上的相对简单。这就是RCP（Rich Client Platform）平台要解决的问题。

RCP平台应该具有的功能：

1. 跨平台，支持各类主流操作系统，基于RCP构建的应用程序理论上可以在不修改代码的前提下运行在各个操作系统上。
2. 支持插件扩展机制，提供标准的接口或者API，让应用程序开发用户可以很容易的基于平台开发插件或者各类扩展。
3. 具有网络分发和更新功能，支持插件或者扩展的自动更新机制以及网络分发，如Eclipse的“Find and Install”和Firefox的xpi网络安装方式。
4. 嵌入Web浏览器，现在的应用都已经离不开web，嵌入的Web浏览器可以整合外部的web应用，充满利用web的优势。

现有的RCP平台：

1. Eclipse RCP，从Eclipse项目中提取出来的一个平台，底层为OSGI架构，基于Java和Swt，同时提供了很好的plugin机制，可以通过SWT中的Browser对象嵌入安装在操作系统中的Web浏览器。基于Eclipse RCP的程序应用已经非常多，如RSSOwl、Azureus等。
2. Adobe AIR，以前也叫Apollo，主要应用Ajax、Flex、Flash技术，让用户把传统的Web技术应用于桌面开发，现在成熟的应用还不多。
3. Mozilla XULRunner， 这是有Mozilla支持的一个平台，Mozilla的主要项目现在都是基于这个平台开发，如Firefox，支持XUL规范，提供了各种语言的COM接 口，如JavaXPCOM，可以扩展COM，插件和扩展可以通过javascript与COM交互，更便于用户来写插件和扩展，看看针对Firefox的 那么多插件，就知道它在扩展方面的优势了。这段时间炒的沸沸扬扬的Joost客户端就是基于XULRunner开发，还比较有名的应用有 Songbird、Miro。
4. Microsoft Silverlight，微软的东东，没有太仔细研究。

每个平台深入进去都有很多值得研究的地方，现在还都是起步阶段，彼此之间似乎还不能存在竞争关系，个人看好XULRunner，但是Mozilla实力相对较弱，如果能够被Google收购或者Google能够来支持XULRunner，它的机会将会更大。

在IE环境下，如果要通过innerHTML给select元素附加options，往往会无效，这是ie的一个bug。

所以如果要通过innerHTML来生成select元素，可以在外面加个div，然后把innerHTML附给这个div。或者通过编程的方式来生成select。可以有以下三种方式：

function fill_select1() {
	for(var i=0; i < 100; i++) {
		select1.options[i] = new Option(i,i);
	}
}

function fill_select2() {
	var sOpts = "<SELECT>";
	for (var i=0;i<100;i++)
	{
		sOpts += '<OPTION VALUE="' + i + '">' + i + '</OPTION>\n';
	}
	select2.outerHTML = sOpts  + "</SELECT>";
}

function fill_select3() {
	for(var i=0; i < 100; i++) {
		var oOption = document.createElement("OPTION");
		oOption.text="Option:  " + i;
		oOption.value=i;
		document.all.select3.add(oOption)
	}
}

• JSMin
• Dojo Compressor
• Packer
• YUI Compressor

这类压缩工具主要的原理通过去掉代码中的注释，空格和空行，来缩小文件大小，同时通过分析代码，把局部变量以及function参数的名称换成如1、2或者A、B、C这类短字母。

要注意的是往往这类工具会对原有的Javascript引入一些bug，所以代码在压缩完以后，需要做仔细的测试。

更新：Packer有一种压缩方式是通过base64算法把javascript代码进行编码，其实就是引入了一个正则表达式，被压缩过的代码在load到浏览器中的时候，首先会被decode，这其实也是要耗去一些时间的。

在进行完上述源代码预压缩以后，还可以通过web server对javascript的请求响应进行gzip压缩，这部分的压缩比率会相对比较大，所以建议最好设置该项功能。

看看这几个工具的压缩比较：CompressorRater

常见的一些开发人员在java开发过程中的最差实践：

• 不按要求严格用类型，而是太多的依赖于String和Object这两个类型
• 没有验证用户输入
• 业务逻辑和显示逻辑的代码混合在一起
• 没有清晰的区分各个cases
• catch掉不该catch的异常，然后不做任何处理
• 混合JSTL和JSF
• 用数组来代替ArrayList
• 适当的时候不用Java5的新特性
• 面向class编程而不是interface
• 通过index从ResultSet中取数据而不是根据name
• 不必要的用一些实例变量

Sysdeo Eclipse Tomcat Launcher plugin 是做J2EE开发的时候经常用到的一款插件，可以在Eclipse中启动Tomcat，同时可以把Tomcat进程绑定到Eclipse Java Debugger中，这样可以在运行时进行一些debug操作，当修改或者新增、删除了一些java文件以后，Tomcat Context会自动重新load，这样不用每次做了修改都需要重启Tomcat。

在使用这款插件的时候，往往很多人会遇到这样的一个异 常：ClassNotFoundException: org.apache.catalina.loader.DevLoader，很多人解决的办法往往是禁用DevLoader功能。其实 DevLoader提供的功能是很有用的，它实现和扩展了WebappLoader。我们知道，默认情况下，我们需要把classes和jar文件都放到 web应用所在的WEB-INF/classes和WEB-INF/lib下，但是在实际的开发环境下，往往需要引用到外部的classes和jar文 件，比如另外一个项目中的classes，这个时候如果在没有DevLoader的情况下我们需要把这些classes和jar文件拷贝到web应用所在 的WEB-INF下的相应目录中，而如果启用了DevLoader，则没有了上述的限制，可以加载项目用到的所有classpath中的classes和 jar。

启用DevLoader的方法：

1. 选中Activate DevLoader
2. 选中需要加载的类库
3. 在插件包中找到文件DevLoader.zip，解压缩到tomcat/server/classes下

默认情况下，所有的servlet container对于后缀为.jsp的文件作为jsp文件进行解析，其实是servlet container默认注册了一个解析jsp的servlet，如Tomcat默认的处理jsp的servlet 为：org.apache.jasper.servlet.JspServlet，同时注册为名为jsp的一个servlet：

<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
</servlet>

所以如果要自定义或者更改jsp的扩展名，可以在web.xml中加上需要的servlet mapping配置即可:

<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.cc</url-pattern>
</servlet-mapping>

Google高调发布了Google Gears，一个离线 web框架。随着ajax技术的大量应用，web应用程序开始转向Rich Client的方向，这类程序需要从server端获取大量的javascript代码，并且在客户端不能保存太多的状态值，即时要保准这些状态值，当关 闭浏览器以后，这些值就消失了，要真正做到Rich Client，如传统的C/S程序，web应用程序还是有太多来至浏览器的限制。而且客户端的每次影响状态改变的操作需要即时同步到服务器端，导致了客户 端和服务器的通讯量增大。

种种限制必将影响ajax技术的发展。这也是这两年ajax应用增多以后，很多公司都遇到了同样的问题，于是纷纷开始考虑离线web技术。现在可以选择的离线web技术除了google gears外，还有：

• Apollo (Adobe)
• Dojo Offline Toolkit (Dojo/Sitepen)
• Slingshot (Joyent/Magnetk)
• Firefox 3 Offline Support (Mozilla)
• XUL Runner (Mozilla)
• Zimbra

这几个框架或者技术里面，从现有的状态来看，google gears的跨平台能力相对较强。现在支持ie6.0+、firefox1.5+，同时支持windows/mac/linux。

Google Gears已经开源，有心想成为offline web的一个标准，但是从现在的状态来看，还有更长的路要走，毕竟这项技术刚刚起步，其他公司也不可能放弃自己的技术来支持gears，微软还没有发布类 似的技术框架，估计今年内也会有类似的产品出来。如果google真有心把gears做成一个业界的标准，建议向IBM学习，学学Eclipse是如何一 统天下的，首先不要叫Google Gears，去掉google的影子，然后搞个几千万美金成立一个基金会，独立来运作，这样更容易吸引其他公司参与进来。

从程序员的角度来看，如何保准软件的质量或者说代码的质量：

1. 单元测试（unit testing）：单元测试可以保准代码在输入一定的情况下，可以获得预期的输出，在方法级别上保准了代码逻辑的正确性。现在主流的开发工具都集成了单元测试框架，JUnit已经是大多数开发人员能够熟练使用的一个测试框架。
2. 静态分析（static analysis）：通过一个静态分析工具，分析代码中存在的bug或者一些不规范的写法，常用的工具有CheckStyle，PMD，FindBugs。
3. 持续集成（continuous integration）：用持续集成框架，大大简化程序发布、安装的过程，同时可以把单元测试，代码静态分析都集成在里面，这样大大缩短了迭代时间，使潜在的问题可以尽早的暴露。持续集成框架有CruiseControl，Continuum。
4. 代码回顾 （code review）：任何工具的使用都及不上人的眼睛，尤其是设计和架构上的缺陷，用工具是没法发现的，通过代码回顾，就有可能发现设计和架构上的一些问题，同时代码回顾也是团队内部传递知识的一种有效的途径。

两个数据库都是用纯Java编写，多用于桌面应用程序或者小型的web应用程序中。比如BlogMethods Basic的数据库用的就是Hsqldb，用这两个数据库的好处是不用另起进程来启动数据库，而是可以直接在应用程序中直接访问，或者可以理解为内存数据库和文件数据库。这两个数据库有什么区别或者该如何取舍这两个数据库。

Hsqldb的优势：

• 速度超快
• 占用内存小
• 可以用文本编辑器直接查看由sql组成的数据，利于测试
• 有广泛的口碑和应用如openoffice

Hsqldb的劣势：

• 数据库最大容量为8gb，所以如果保存一些大的二进制数据在数据库中，数据库会很快达到上限
• 对于大访问量的服务端应用程序，hsqldb不如derby来的优秀
• Derby比Hsqldb支持更多的SQL标准如触发器，存储过程，视图等