本次作业是在本周写立项书时一个不懂得问题加上在书上选的一道题：
P171：
8.8.4：在一个软件项目中，软件团队预计每天的进度为 30 小时（即，完成了30小时的工作量）。当项目完成了一半的总工作量的时候，大家发现实际的进度为15小时/天，问：在余下的时间中, 团队的进度要到多少，才能在项目结束时让整个项目的平均进度恢复到每天30小时工作量？
答：假设这个团队的工作量为1，那么按照预计的工作进度，需要工作时间为1/30，在工作完一半的时候，进度为15小时一天，那么所消耗的时间为（0.5）/15为1/30，就相当于在完成总工作量一半的时候已经将预计时间消耗完毕。也就没时间可以剩余了吧！
项目中的问题是：技术选型（只指采用java开发的web项目）
答：在网上找了不少的说法，感觉说的都不错，但说多了就和没说一样，不过感觉其中一个说的不错，简洁易懂。
- 操作系统，操作系统的选择一般要根据项目的规模、客户的特定要求以及自身的熟练程度来进行考虑，尽管可能你的客户不会干预你对操作系统的选择，但你还是应当把你的项目开发成支持多种平台，因为Java语言本身就是跨平台的，因此在写程序时需要了解不同操作系统之间的差别，例如路径分隔符的差别等等。
- 数据库，在考虑选择数据库时更多的不是一些技术因素，很多时候数据库的选型受到了客户的限制，另外还包括项目的数据规模、开发者的熟悉程度、所采用的操作系统、项目预算等等。
一般情况上面的两个选型不会存在太多的分歧，虽然各自都有多种可供选择的产品，当往往跟项目相关的所有人员在此二点上都能很好的达成共识。真正的问题都是跟Java语言本身相关的一些内容，而且不同的看法皆来自于开发者本身。
- 开发环境。开发环境的选择更多的受项目经理的个人喜好所决定，当然有时候也与一些特定的应用平台有关系，例如Oracle的OAS如果用JDeveloper开发比较方便，同时好比WebSphere对于WSAD。除去这个因素之外主流的开发环境无非就是Eclipse & JBuilder。二者实在没有什么好比较的，最大的区别就是JBuilder是需要花钱去买的，因此如果仅在这二者中作选择的话，两个因素是你所需要考虑的，第一是钱（因为我想你肯定也不希望以后收到BORLAND公司的律师函），再有一个是项目组开发人员的习惯，看看多数人更喜欢用哪一个环境，不过这第二个因素也不要考虑太重。
- 应用服务器。企业用户一般不太可能选择一些免费开源的产品，商用的应用服务器最主流的还是WebSphere以及WebLogic，而且这两个服务器也相应推出了绑定不同功能的版本，例如不支持EJB以及一些高级特性的Express版本，价钱当然也相应的比较便宜。免费的产品经过大浪淘沙最流行的还是Tomcat、Resin以及符合J2EE规范的JBOSS。不管选什么服务器，你的项目都应该是使用J2EE的标准，而不是只能运行于某个服务器的程序。
以上四点是涉及到程序的开发以及运行环境，而开发技术本身关系不是太紧密，在开发的过程中应该尽量避免跟这些环境过于紧密的联系。接下来的内容就是一个开发人员非常关心的问题，包括表现层采用的技术、采用何种MVC的框架以及何种数据持久层的实现，是否采用EJB或者J2EE其他的一些特性等等。
- 表现层。使用Java开发web项目在表现层上有很多可选的技术实现，例如JSP、velocity、FreeMarker，同时你也可以自己定义一种模板实现。所有的这些东西当然还是JSP占的比例最大，毕竟每个开发人员在学习J2EE的时候肯定会接触到的，而且绝大部分的web项目也都是采用JSP开发。JSP的功能超级强大，你可以在JSP上做任何你想做的事情，整个项目的资源都可以被JSP轻易的访问到。因此我们也会经常看到很多糟糕的JSP代码，例如在页面上连接数据库执行SQL语句等操作。而最近在国内开始流行的模板技术例如Velocity、FreeMarker就比较好的解决了这个问题，功能上的限制避免了在JSP可能带来的弊病。
尽管JSP有很多弊病，但是作为JSP的附带产物——标签库的功能确实无可替代的，而且也可以找到很多开源的标签库，可大大的加快开发的速度，如果你决定采用JSP来编写页面，你应该从制度上限制不应该在JSP页面上编写业务逻辑代码。
一旦你的开发小组对JSP已经是轻车熟路了，那不妨试试Velocity或者FreeMarker，在我看来Velocity更加简单，容易上手些，而且可以是页面的代码更加清晰易理解。 - 控制层。争论比较多的也就在控制层，因为有很多可以选择，而且各有千秋，例如Struts、WebWork、Turbine、Tapestry以及Spring等等，或者说Spring应该不属于这个范畴，不管仁者见仁。关于这几个框架的应用比例从书店里卖书的情况便知一二，多数都是Struts开发方面的书，其他的零星一两本而已。也就说明Struts有着非常广泛的群众基础，用得多了，批评也就接踵而来，于是很多技术牛人开始推崇Struts外的其他控制框架。的确有些框架确实比较好的弥补了Struts本身的一些不足，但是推崇者往往只提一点、不及其余。
大家或许可以看出我一定是倾向Struts框架，是的。选择它的原因不外乎几个：1、功能比较全面；2、可供参考的资料非常之多；3、普及程度非常高，容易招到熟悉的开发人员。但是Struts中的Action机制让我有点反感，因为直接导致大量的Action类，虽然可以使用DispatchAction来避免这个问题，但总感觉不太漂亮，因此我在Struts中引入Turbine的做法，自动实现eventSubmit_Xxxx -> doXxxxx的映射关系，也就是根据提交按钮的名称自动映射到一个Action类的相应方法，实现的办法也仅仅是在原有Action类上继承一个子类覆盖了execute的方法，并采用反射机制执行对应的Method。这样做可以将相同模块的功能集成在同一个Action类中。例如UserAction可以包括登录、注销等等用户相关的操作。
取长补短是我在应用框架上的一些建议，因为每个框架都有自己的长项与不足，把这些长项都结合起来就可以大大的提高开发的效率以及优化代码的层次结构。 - 数据持久层。使用一些数据持久层的实现框架的好处是自动化，可以大大减少程序的代码行数，避免编写大量重复冗余、无趣的数据操作语句。在这层中我不知道除了Hibernate还有什么其他更好的选择，要么是一些需要付费的产品，要么就是不够轻量级。当然同样存在的问题就是其他的产品很难找到沟通交流的渠道。
出自：http://blog.itpub.net/175988/viewspace-798400/