我写的一些体会

写点我认为的一个 javaEE 项目中应该提倡的做法。

1.       开发流程尽量简化，采用迭代增量的模式，做适合项目需要的文档。很多时候千言不如一图，原型开发我认为也非常重要。

2.       采用成熟的框架， ssh 组合或更多 full-stack 的框架如 seam 等都是不错的选择。如果一定要用公司的框架，至少 SA 要非常熟悉这个框架，在出现问题时要能快速的解决。

3.       对业务的分析做到越细越好，如果有条件让更多的开发人员参与业务的分析，同时形成项目通用的业务语言（实在不行，精简的 user story 也可以）。对于每个达成共识的业务都要能记录下来，并能方便的进行查阅。业务模型和业务规则要始终与当前需求、代码和数据库保持一致。

4.       在团队的建设上，需要更多的投入。不要为了节约成本，让很多程序员老后面才加入团队。一个稳定、团结、有冲劲的团队能比松散而人数更多的团队，完成的更快更好。然后要加强沟通，比如每天开个小的茶话会，大家交流下各自的工作情况，有什么困惑和疑难，提出来大家一起解决，避免大家各自做相同的逻辑（很多东西经过抽象可能就是一个）。在工作之余大家一块吃吃饭，打打游戏等都是增进感情的好方法，大家彼此熟悉了，工作上也能更好的协作。

5.       对程序员要有更高的要求， SA 有责任让程序员了解更多的东西，如面向对象的 5 大原则、一些模式、 junit 、重构等，这些其实并不是什么高深的东西，仅仅是掌握一些方面也能对代码质量和开发中的愉悦度产生很大促进。要激发他们对技术的热爱和对代码质量的追求，因为最终受益的还是他们。 XP 所提倡的结对编程也是快速进行知识传递的好办法。

6.       采用 wiki 进行项目进度跟踪和一些文档的展示。这次用 excel+cvs 的方式感觉很是麻烦，在 spring 翻译中我们采用 wiki 的方式就感觉很好。

7.    面向对象一个很重要的概念是封装，它不仅仅是封装属性和方法，更重要的是封装实现和逻辑。factory模式，strategy模式，command模式等的本质就是通过提供不同的实现类，给外部提供统一的抽象接口，这样保证很好的稳定性、扩展性和可重用性。依赖于抽象而不是具体实现，这句话怎么强调都不为过。

暂时先想到这么多，有更多体会，再来补充！ 新人报道，欢迎大家拍砖。

对业务的分析做到越细越好，如果有条件让更多的开发人员参与业务的分析。如果用户经常修改需求怎么办？

项目组最好要有精通业务的人员参加。

不是最好，是一定要有，要不就等着痛苦挣扎吧。

需求的修改有时无法避免，但同时也需要需求分析人员的能力，并多跟客户交流和反馈。一方面软件架构要设计的能够应对变化，一方面要把握用户真正的需求，避免由于业务理解的差异导致返工。

开饭店的就不怕大饭量的,做开发的就不怕改需求的

这个确实啊

开饭店就是怕饭量大不给钱的，做开发的就怕改需要又不加钱还指望你不延期的。。。

对于这种客户要多多洗脑，洗脑失败的就判定为劣质客户，不接他的单。

我们这边的老板经常让不编程的人写本子，学院派作风十足，结果怎样可想而知！我都想撤了……