转载

JSP项目设计中的方法论(1)

在设计JSP项目的时候，现行的方法学提供的更多是限制而不是帮助。按照Casey Kochmer的观点，成功的运行一个JSP项目的关键是项目管理而不是设计。

与一般的想法相反，在运行一个项目的时候，最好的设计方法学并不是那种正式的方法。多数设计方法学都是臃肿而不切实际的。如果一种设计方法需要200页的手册才能说明，那只能说明它在实际应用的时候显得太复杂了。我认为，设计方法的本质应该是简单和整体的。实际上，对于一个成功的设计方法，最关键的甚至可以说是与设计无关的东西，而是项目管理策略。如果管理不当，即使你有最好的设计也有可能失败。在设计方法中，最重要的一点是必须提供一个简单的框架，这个框架要能把任何成功设计中广泛存在的对立和矛盾包容在一起。

在下面的指南中，我们将解释这个问题，讲述项目管理中最基本的组成原则。

项目管理原则

有几个主要的因素可以导致项目失败。我们在下面列出最主要的10个，还包含对每个因素的简单解释。

项目过于死板，不能按照用户需要进行必要的改动。

项目毫无原则，经常因用户的意愿进行改变，因而无法在合理的时间内完成。

在编程人员和客户之间缺乏沟通或者沟通很差。

有不切实际的预期目标。

时间表是不切实际的。

项目过大，无法进行成功的管理。

没有测试或者测试过多。

使用错误的工具。

项目使用的技术对于项目和用户来说太过先进，超前。

项目进行不尊重项目成员。

下面的多数原则就是为了解决这些问题而提出的。当然，每个项目都有其自身的平衡点。因此每个项目经理和主程序员都要按照自己项目的内部特色进行调整。

在项目的设计过程中，必须允许用户提出改变设计的要求。但是同时一个项目又要有一定的“刚性”，要使设计的改变尽量少。平衡这个矛盾需要非常好的设计艺术，而且每个项目的平衡点都是不一样的。

在项目进行过程中，团队需要直接与客户沟通，至少也要保证最低限度的项目回顾和问题澄清/分析过程。

一个项目的时间不要超过一年，以6到9个月为最佳。任何更大更长的项目最好切割为小的子项目。

项目经理与程序设计主管一定要是不同的两个人。将者两个角色合一使一个人的负担过大，两个角色都作不好。

一个项目的人数不要超过7个，以5个为最佳。

一个项目小组最好能混合资深的和年轻的开发者

我发现，如果一个开发小组全是资深的开发者，那么小组很容易陷入陈腐和习惯化的情况。而一个完全又年轻的开发者组成的队伍又明显的缺乏经验。团队中的年轻成员可以消除老的资深人员的惰性，年轻的新手可能经常会问，这个为什么要这样作？这种问题经常带来良好的改进。同时，资深的开发者可以训练新手，让他们经常对设计进行检查，这也可以带来改进。 7.项目所使用的工具对项目成员来说必须是容易使用和控制的，或者在这方面能够提供帮助的人必须是容易找到的。

开始的时候就要制定比较现实的时间表。如果时间表在开始后发现是不合理的，就要尽快对人员或者是时间表进行调整。多数项目的错误在于一味的增加资源以加速进度。这通常都是错误的。如果发现一个时间表是不合理的，其错误之处多数不仅仅是缺乏资源。在检查时间表的同时也要检查一下项目目标，方法和选择。确保你在可靠的前提和信息下工作。在完成这种重新审查后，按照自己的想法重新调整项目。

内容导航

第 1 页：项目管理原则

第 2 页：设计原则

项目中的主要参与者必须感觉舒适，可以自由的提问，自由的进行沟通。缺乏有效沟通的项目通常会迅速失败。出现问题的第一个信号通常就是在交换信息的时候有问题。沉默并不是项目要完成的信号，而是说明你的成员在无法沟通的真空中工作。

项目小组中的所有成员都要明白这些原则，以便经常对项目情况进行检查。如果一个项目不符合这些原则，那么所有的成员都有义务尽快找出问题之所在。我在项目中也经常弄错点什么，但是也尽量将这些错误迅速找出。当问题在爆发前被发现，或者是在项目的初始阶段被发现，通常解决问题的方法也简单。但是，忽略这些问题则经常导致更严重的问题，导致项目失败。如果有项目不能体现这些原则，我是不会接受这种项目的。

这些原则是我为项目成功总结的一些基本点。我个人的经验告诉我忽视上面任何一个原则都很可能导致严重的结果。

设计原则

虽然在设计上设置过多刚性的原则是有害的，但是这里我们还是提出一些可以遵循的基本原则。

避免成为使用新技术的群体。一定要等到技术和产品的支持信息成熟了再考虑。但是如何判断一个技术是否足够成熟呢？看看在Internet上的支持信息的丰富程度和深度。一个新的工具，只有在你可以很容易地找到其帮助信息的时候才是好的。

如果你不得不使用比较新的技术，记住一定要准备有后备的方案，以便在新技术实施中出现问题的时候使用。我的感觉是新技术在你项目的关键点上有大概50%的机会会出问题。从一开始就准备好后备的方案可以避免日后问题扩大。在使用新技术的时候，一定要在项目的早期使用，以争取更多的时间对其可行性进行评估。

保证用户的技术水平可以使用你的项目中的各种技术，例如如果用户使用的是3.x版本的浏览器，你就不要采用客户端的XML/XSL。当然，你还是可以使用服务器端的XML/XSL，因为用户不会因此受到影响。

以满足最小限度的需求为目的，这样做可以防止项目变的臃肿，同时可以加快程序编写速度，也更容易测试。而用户只应该要求他们真正需要的功能。
在编码的时候，最主要的目标是制作可维护的代码；第二个目标是制作可重用的代码。借助Java，面向对象是我们达到成功的最重要工具。但是也不要完全依赖面向对象技术，借助最简单的模板，函数库或者是良好设计方法也可以很好地对代码进行重用。面向对象只是我们在编程的时候可以选择众多技巧中的一种。

测试和试用是成功的重要部分。试用是非常重要的部分，一定要给以充足的时间以便有机会对发现的错误进行修正。

在主要项目完成后，可以给出一个小的第二阶段，在这个阶段中可以将项目中不够完善，没有完全达到预期水准的部分进行修改。
想想多重项目的概念。一个项目小组经常要面对多个项目。项目人员在不同的项目中，要不断的变换职责，一方面这样的作为为以后的人员使用增加了后备。而且由于每个项目小组成员都不断作新的事情，也减少了人员产生倦怠情绪的可能(这意味着你的项目小组可以长时间保持相对稳定)
预先作好计划，使多个人可能不断对一段代码进行加工。为了作到这一点，我在不同的项目之间进行代码重用。其实，我们做的不仅仅是代码重用。在每个项目中，都可能有个新的人在使用现有的一部分代码。新的人可能会不断的对这些代码进行修正和优化。因此这些代码可以不断的增加效率，同时出现问题的机会也很少。代码的效率可以得到提高，另外文档也可以不断完善。不仅仅是代码本身可以不断被修改，提高，随着新技术的出现，代码也可以不断应用新的技术，从而得到提高。

如果可能，尽量使用公开源码

将JSP的分布式环境变成你的优势。使用客户端脚本来利用客户机的能力。真正依靠数据库的存储进程，将数据处理逻辑集中保存。使用J2EE服务器生成XML和XSL数据模板来产生HTML输出。避免将处理集中在一点，将处理工作分布开来是完成工作最有效的方式。

避免把太多的逻辑放到一个单一的JSP页中。一个JSP页作的事情越多，当你需要升级或者是修改项目时候，影响就越大。尽量使每个JSP页只完成一个最基本的小操作。也可以使用Tag和JavaBean库的优势来建立可重用的模块。这些手段有助于使JSP页便于维护。　

正文到此结束