有句话，失败是最好的老师，的确，失败的学费有时是昂贵的，但带给我们体验也是刻骨铭心的，我们能做的就是尽量避免在同一个地方跌倒两次。个人的一个方式就是通过总结，反思，分析原因， 找出症结.，弄不清症结所在，当相同的境况出现时，可能还会重蹈覆辙 ，下面描述自己曾经所做的一个失败的项目
1.项目类型： j2ee
2.团队： 单枪匹马
3.用时： 4个月
4.个人经验度： 第一次从事j2ee开发， 项目运作情况: 项目做好后，给老板演示，发现一个核心的业务逻辑理解偏差，如要修正，代价是新系统几乎要全部推导，该系统就这样将就用了一年，中间用户又提出了很多的问题，建议，最后随着其它系统的建立，由于系统之间的交互，问题系统像一个瘤子，到了必须铲除的地步，不得已，又花了近3个月的时间重新建设，后来想想，那个项目的确存在很多的问题：
1.虽然平时也老听说编成不单单是写代码，可潜意识中还是把代码作为一个太重的分量来对待，草草做需求，草草做设计； 导致需求没做好，带给自己的直接是对系统的一个切身的体会（不再是口头上的啦），系统不光是写代码，需求，人性化等都很重要喔
2.为什么我做的那个项目到最后才被发现有问题呢，除了老板自身原因外（老板硬件出身，软件方面全权交给了俺），和我的经验不是很多，和老板沟通不够都有关系，但最重要的是要建立一套可行的软件开发管理机制。
3.为什么出现了问题，要修正起来几几乎要推到整个系统，归根究底还是设计的不好，扩展行不够，没有很好的领悟面向对象思想。 鼠标坏了，我们无需更换键盘，硬件如此，原件也是如此，那就是要面向接口设计
4. 当然以上有些东西要想做好光认识到还是不够的，需要技能的提升，经验的积累 朋友们，很想听听你们曾经做过的不是很满意的一个项目，你认为是什么原因造成的呢，欢迎提供，交流，一同学习，毕竟，共性的东西才是真正值得我们注意的
1.项目类型： j2ee
2.团队： 单枪匹马
3.用时： 4个月
4.个人经验度： 第一次从事j2ee开发， 项目运作情况: 项目做好后，给老板演示，发现一个核心的业务逻辑理解偏差，如要修正，代价是新系统几乎要全部推导，该系统就这样将就用了一年，中间用户又提出了很多的问题，建议，最后随着其它系统的建立，由于系统之间的交互，问题系统像一个瘤子，到了必须铲除的地步，不得已，又花了近3个月的时间重新建设，后来想想，那个项目的确存在很多的问题：
1.虽然平时也老听说编成不单单是写代码，可潜意识中还是把代码作为一个太重的分量来对待，草草做需求，草草做设计； 导致需求没做好，带给自己的直接是对系统的一个切身的体会（不再是口头上的啦），系统不光是写代码，需求，人性化等都很重要喔
2.为什么我做的那个项目到最后才被发现有问题呢，除了老板自身原因外（老板硬件出身，软件方面全权交给了俺），和我的经验不是很多，和老板沟通不够都有关系，但最重要的是要建立一套可行的软件开发管理机制。
3.为什么出现了问题，要修正起来几几乎要推到整个系统，归根究底还是设计的不好，扩展行不够，没有很好的领悟面向对象思想。 鼠标坏了，我们无需更换键盘，硬件如此，原件也是如此，那就是要面向接口设计
4. 当然以上有些东西要想做好光认识到还是不够的，需要技能的提升，经验的积累 朋友们，很想听听你们曾经做过的不是很满意的一个项目，你认为是什么原因造成的呢，欢迎提供，交流，一同学习，毕竟，共性的东西才是真正值得我们注意的
楼主总结的不错，收下了
推荐一本书：java设计模式
对于软件工程的流程，我觉得有些时候我们没办法去按常理走下去，比我我所在的环境，基本就我一个负责开发的，周边参与项目的同事都不懂软件，为此我在实际的沟通和操控大局时也出了n多问题，比如文档进度不统一、沟通语言易被误解，为此我也曾想过开个小会，仔细分一下工，完整的走完需求分析、概要设计、详细设计、编码测试等等流程，但基本不可能。公司的规模和客户的性质基本决定了我没法把时间花在文档上，和需求的完全确定上。甚至出现了东西都做好了，客户都没看到一眼这种情况。有些时候真的很无奈，要对一个需求相当模糊的东西进行设计编码，而且作为开发人员还要分心去和所有同事沟通，还要考虑样式的设计与图片的制作（这个问题是因为美工经验差，图片做的不佳，而且完全不会html）。结果呢？？呵呵，我为了能团结大家共同完成目标而成了老好人，成了大家的垃圾桶、、、所有的抱怨和质疑基本都是直接劈头盖脸的直接来，而实际产品还好客户没要求大的改动。实际的效率也很糟糕，经常有无谓的讨论和完全可以避免的程序上的返工。
头疼啊，小公司大多这样，需求分析整理+编码+进度控制+测试+文档+沟通权衡，多职责系于一身、、、、、而且流程不是乱的要死就是压根不按流程走
才默然发觉失败也是一种收获;
我也总结下:
先从最基础的说起:觉得有些非常简单的代码,如果稍微不注意,多打,少打或打错了一个代码
尤其是那种反射,连接数据的字符串,是在双印号里写的,开发工具根本就不会提示你,
还有就是利用开发工具的时候追求速度,导错了包.
感觉编程的大部分时间是在代码的调试上,后来发现
:"慢其实就是快",也不至于特别慢,项目中缺少沟通能力,喜欢单枪匹马,一味的猛敲代码,这不是好事;
记得以前作项目的时候,由于设计需求的设计不是很好,修改是经常的事,再到后来,修改的没有
什么可读性,再加上没有写注释的习惯,可笑的是,代码需求是达到了,但自己都有点看不懂.
后来发觉:一些代码虽然能写出来,但可重用性啊,可扩展性啊都不是很好,才有学习设计模式思想
的意识,难怪项目经验这么值钱;至于上面的朋友说的,按流程走,个人认为:能力达到了一定的程度,不按流程走牛逼,其实还是有流程意识的;
要想做一名优秀的程序员,过硬的技术是基础,并代有突出的沟通和协作能力...
什么项目经理->项目主管->部门经理->公司CEO->还是自己当老板也好指日可待,呵呵.
2.项目组没有此类案子的经验，没有进行深层的技术预研，后面吃了很大的苦头
3.后期项目组人员变动频繁，最后
4.项目死了总结：
1.一定要文档化流程化客户的需求。
2.做好变更的追踪。
3.要提前进行技术预研，虽然一切反动派都是纸老虎，但精神原子弹还是常常失效。
4.开发的相关文档一定要准备好。
5.对手下人一定要好一点。
6.不赚钱的买卖把客户看成婊子就对了，用警察扫黄的语气来做需求。
2.根据整理的功能利用ER图的方法来设计数据库（有时候不能完全按照了，为了性能）
3.选择一个好的数据访问层。当然，这里参考些代码，利用sqlhelper来做是最好的
4.做界面，拖进去gridview，listview，repeater之类的空间，把他们datasource设置成你的sqlhelper取回的数据，就ok。这里不太好说，因为有maseterpage，basepage，还有sqldataprovider之类的东西，最好参考一下基础书籍，照着弄弄。
嘿嘿，自己也是初学者，慢慢摸索，关键是每天都做出点东西，立足实际，每天给自己自信，慢慢就会牛的。
我觉得LZ 第一次能自己独立完成一个项目，确实就是一个收获，随着时间的增长，经验的积累，你的前途不可估量哦 ，慢慢来，想一步登天是不行的