本人是个对技术的推崇者或者说是有些图腾崇拜的人，从学习和使用 java 的第一天开始，就对这种纯粹的面向对象的编程语言产生了浓厚的兴趣，从早期秉烛夜读《 java 编程思想》、《 java 核心技术卷 I 、卷 II 》到《 J2EE 设计与模式》。。。《深入浅出 Hibernate 》。。。《 Spring in Action 》等，切身感受到当今主流 java 应用技术的发展，也很感谢前辈们为大家开创了应用技术之先河，为我辈指明了发展的方向和前进的道路。

在当今技术潮流日新月异的时代各种各样的技术框架林林总总，很难去评价个中孰优孰劣，个人觉得在项目开发过程中最适合的框架就是最好的，以项目的规模和特点来决定对技术框架的选型。现就个人对于框架的开发的一些体会和大家一起交流一下，前端采用类 Struts 模式做 MVC, 我觉得 MVC 的精华所在就在于请求的汇集和请求的分发，采用 filter+mainservlet 的方式，在 filter 类中可以进行对各种请求的约束和限制处理，同时可以进行对请求合法性的判定和校验，也可以实现达到负载均衡的处理，也可以根据实际的项目需要设置多个 filter 类进行分类过滤。通过 filter 类的合法的请求全部由统一的 mainservlet 主控器接口进行分发处理，在这里可以添加对线程的约束和控制，以保证所有请求可以顺利的分发。业务逻辑层采用 Action+BPO 的模式， Action 作为动作的描述， BPO 作为对于动作进行响应的业务逻辑处理。持久层部分采用 Hibernate 和 DAO+VO 两种模式并存的方式，持久层部分之所以采用两种模式处理，主要是考虑到业务逻辑的复杂度，对于多表及连和复杂的业务查询处理，感觉配置 Hibernate 文件也相当的复杂（也许是本人应用 Hibernate 的深度还不够，对 HQL 语言的认识还比较肤浅），因而还采取传统的 jdbc 访问模式来处理。事务处理用 Spring 框架来进行处理。在表示层的 jsp 中只进行 tag 的属性设置和 java 的表达式的输出，所有的 java 逻辑代码全部用 tag 来进行封装。有兴趣的朋友可以发 e-mail 给我，来进行此框架的交流 E-mail:syangsheep@163.com, 同时也欢迎大家拿出自己应用的框架来一起进行交流和探讨。

下面进入正题，谈谈我对项目经理（ Project Manager 以下简称 PM ）的认识和看法。本人在软件行业摸爬滚打了 6 年，在 PM 的位置上苟活了 2 年，记得有位国外的软件大师（名字记不得了）曾经说过：“没有写过 10 年程序的人就不要说自己是一名程序员。”我汗，勉强只能算半个程序员了。咦，咋又跑题了呢，不好意思哦。个人认为， PM 大体可以分为三类：一、即懂技术又懂管理的 PM ；二、不懂技术懂管理的 PM ；三、懂技术不懂管理的 PM 。第一种我相信是任何软件公司都渴望的，也是比较难求的人才，当然也是本人最为推崇的。它对于一个人的综合素质要求比较高，要有缜密的逻辑思维，准确的判断力、果敢的决策力，卓识的大局观，对编程的浓厚兴趣等等。它应该是多种职业的综合体：软件架构师、软件工程师、测试工程师、风险评估师、会计师、律师、理财师、人力资源师、培训师、翻译、心理咨询师等集大成者，我认为可以定义为刷子型人才（多专多能，哇噻，公司岂不是赚大了）。第二种我相信也是在相当规模的软件公司普遍存在的，往往公司的意图和出发点很好，希望 PM 专管协调组织，控制项目整体进度，不做具体事情，殊不知一个不懂技术的人谈何控制项目进度，在我供职的公司里曾经发生过这样一件真实的事情，测试人员提交的 bug 单， PM 整理后分发给具体负责的开发人员，一个开发人员在对一个 button 属性的修改的工时描述单上注明需要半天的时间修改， PM 不加任何思索的回馈给测试人员，引为笑谈。项目经理对承担项目个体职责如果不够了解，将很难控制项目进度，很难把握项目进展过程中的瓶颈，很难就项目进展过程中出现的问题做出准确地判断并制定出合理的解决方案。第三种我觉得更准确地应该定义为主管开发的 PM 比较合适，这样的人普遍是编程高手，可以解决技术问题，攻克技术难关，但由于个人思维的局限性难以对项目整体进行把控，协调好各个环节的资源，这样的可以成为不错的将才，但难以成为帅才。（待续）