最近项目中的一些简单的想法

1.       开发前统一开发工具、开发环境
千万不要各自为政,导致同一个开发小组有的用Jbuilder,有的用Eclipse,并且源码的目录结构要初始定义,基本的要求是每个人的IDE里面的目录结构都是一样的。初始定义模板文件,java文件头(包名上面的那些注释)应该有一个统一的样式,里面包含的信息应该有创建时间、文件名、作者、以及公司名称、注意事项、版权信息等,注释方式如下:
/*——此处只有一个星号
 * 创建时间:2003-12-30
 * 文件名:abc.java
 * 作者:author
 * 版权所有 ? 公司名称
 */
而在类名前面的注释则为
/**——此处两个星号
 * <code>abc</code>…
 * @author author
 * @version 1.01, 2003-12-30 ——由于模板功能无法定制出 1.01.yyyy.mmdd样式,故使用此种方式代替
 */
一般的IDE都有模板功能,可以将上述信息制作成模板形式,使开发小组达到统一。
推荐使用Eclipse,功能不比Jbuilder弱,而且占用资源更少,尤其难能可贵的是免费,至少你不用担心接到律师信;如果你一定要用Jb,那么别忘了开个防火墙。

2.       使用统一的ant文件
如果你用的Eclipse,那么我推荐使用其插件myEclipse,这个插件是用来配合Eclipse做J2EE开发的,但其中的自动发布功能值得称道,只有环境配置完毕,以后每次对类文件或是jsp等文件修改之后做保存操作时,它会替你自动将修改后的文件发布到Server目录下。
当然如果你没有使用myEclipse,那么ant也许是你最佳的选择了(即使你使用了myEclipse,ant也应该是必备的工具),你应该在项目初始时就将ant相关文件编写出来。

3.       vss或cvs里面的目录结构一定要清晰
不要惊讶,很多项目的目录结构杂乱无章,现在你可以回头看看你的目录结构。各个公司一般都会有自己的一套管理方式,那么就照你们公司的规范执行吧,不要再随便建一些自己将来注定会忘记其作用的目录及文件了。

4.       使用的技术一定要在开始做好规划及相关培训
有的人喜欢使用新技术(我就是这样),那么请你在下一个项目的开始提出来,而不要在现有的项目中随便使用,除非你对那个东东达到源码级了解。
项目组培训非常重要,如果你打算使用某个东西,那么请你先抽出两天时间来培训你的组员,这个时候的培训不能光让他们“了解”这项技术,而是要让他们学会“应用”这些技术,你现在花点时间,后面你会省更多的时间。开发工具的使用同样需要培训。
再说了,像struts、hibernate这些东东,你能保证你的组员都会吗?

5.       提高对测试的重视
这个问题再怎么唠叨都不算过分,可是再怎么唠叨还是有人会忽略,测试不光是测试人员的事情。

6.       你会单元测试吗
这个问题并不简单,同样还可以问:你单元测试了吗?不要回答说你是做项目的、你的时间太紧了、有专门的测试人员呢。要知道,单元测试是你自己的事情。

7.       你的系统是参照原型做的吗
一个系统除了功能的完成之外还应该注意点啥呢?风格。对,统一的风格同样重要。如果美工已经给你制定好了系统的门面,那么就不要自己去油漆了。开发人员喜欢个性化,说实话,我也喜欢,可是系统要的是统一的风格。如果你不喜欢原型的风格,那么你应该在实际开发之前提出来,让美工去修改原型,而不是在开发中自作主张,给页面加一些自己的元素。千万不要这么做,即使只是一个按钮!

8.       你的代码注释了吗
对,你确实只是写了一些简单的添加、修改、删除的方法,谁都看的懂,可是,你注释了吗?同样,你的jsp页面注释了吗,你告诉别人你的页面需要哪几个传入参数了吗,你告诉别人你的页面的功能了吗,你告诉别人你的页面会跳转到哪里了吗?你好像没有。

9.       把你的设计意图告诉组员
不要每人告诉一块,而是将组员集中在一起,将你的设计思路完整地告诉所有人,让你的每一个组员都对系统有个整体的思路,而不是只了解局部。

10.    详细设计应该和例子程序设计同时,而且要让对整个系统最熟悉的人(一般是项目经理或开发经理)设计例子程序,这样才能保证最后做出的系统不会违背初衷。

11.   软件工程有个说法就是不要实现那些客户不需要的功能。我认为它应该再加一句:用户需要的功能,一定要很完善的实现。单纯的实现很简单,可能让用户真正顺手地去用,就是学问了!

你可能感兴趣的:(项目)