最近项目的感想
最近忙着一护照的项目。期间发生了诸多情况，将其列出，作为前车之鉴
相信很多做java的朋友会有相同的境遇
在公司做了n个项目了，每一个项目需求是一成不变的，所有都在Change，有好多情况是我们要在用户的具体需求前完成项目的大部分，在项目实施的时候，或许部分需求也是定不下来的，只能是暂定，因为现实中的项目唯一不改变的就是Change，也就是在人月神话中提到。
当然，现实是残酷的，既然有变动的地方，它肯定有不变的地方，也就是需要整体分析该项目了，从业务、实现、技术、数据结构等多方面考虑，当然不要忘记，做程序最主要的是有想象力，也就是想当年爱因斯坦说过的，最伟大的是想象力。能够完整分析项目，不是一两次就能搞定的。千万不要独自硬啃，那是最没有效率的，除非自己很自负，除非你不想把项目做的最好。
做项目分析的时候，应该主动参与思考，最好是思考成熟再发言，你不说话没人知道你在想什么，你不辩驳你不清楚对方的意图是什么。当多人共同探讨一个问题时，因为每个人的思想、观念、角度会有不同，会发现很多新的需求及解决方案。方案多了，当然就可以对比选择了。
分析问题，一定要Thinking in java 面向对象，不要一位技术很牛就是程序高手了，实际上各个领域的项目，需要的是技术牛，理解能力更牛的人，因为一个项目的成败看的是实现了否，专业领域的业务流程等的要求是相当高的。
再比如说前一段接手的pki项目吧，是一个关于网络安全，通信认证与加密的Ca系统，对ca系统的整体业务理解，远胜于编程，因为当你业务完全理解后，程序流程及结构会有一个概图在脑中，就是不编程序也知道进行某些操作会发生什么状况，当然编程只是把这些给实现了。
对于需求不固定的项目，我尽量给自己留后路，程序设计用接口、抽象。不要想着做完某一项目后，客户因为某些变动而要常常“劳驾”，每次都要去客户那调试改代码，会感到自己的重要性是多么多么的高。实际上那是一种失败的体现，成功的程序，是做完后二次开发、持续集成都应该不需要本人去，其它人照样可以完成。前提是你做好功课了，那就是需求阶段的：需求分析，设计阶段的：概要设计、详细设计文档。这些文档你写的是否合格，是在第一次开发和这个时候体现出来的。

只是泛泛之谈，没想这么多了，再者给大家介绍一个很棒的java网站，www.java2s.com 里面有很多api的源程序及api的方法的使用举例，包容了很多常用的官方及非官方类库，做项目时帮了我很大的忙，尤其是专业领域很强的一些包，需要有些例子来帮助理解，是个英文站，等于说比翻译的中文准确。 1 楼 shgen 2008-11-06 说得很好。
编程只是实现的一环而已，当然也是很重要的一环
但其他的环节也很重要。