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

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
• 不必要的用一些实例变量