对于一个软件公司而言，在做项目或产品的过程中，为何要应用一定的技术框架呢？相信有一定规模一定历史积淀的软件公司里，都存在着自己特有的技术框架，我们应用框架开发无外乎是本着提高代码的重用性、降低开发应用模块的技术难度，增强软件的维护性，进尔达到提高工作效率、降低生产成本的目的。这也是技术框架存在的根本和意义所在。

本人是个对技术的推崇者或者说是有些图腾崇拜的人，从学习和使用 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, 同时也欢迎大家拿出自己应用的框架来一起进行交流和探讨。

本人经历过小到 3-4 人，大到 140 人以上的项目开发，现就个人做 PM 的一些经验和体会与大家一起交流和探讨。个人认为做为 PM 应具备如下几个性格特点：自信、执著、果敢、细心、公正、迭代。一、自信：自信源于实践经验积累的宝贵财富，在一个项目进行过程中，各种各样的问题和不可预知的困难将贯穿项目始终，身为三军统帅的 PM 如果自己都没有信心把项目做好，那吗项目的最终结果也就可想而知了。二、执著：不能轻易放过任何暴露出来的问题点，这里不单指技术层面的，包含各种可利用的资源。失败的项目或者说垃圾的项目不是一下子就被定性的，它是由于在一个个的问题点上处理不当积累起来的，最终导致项目失败的恶果。三、果敢：当项目处在某个关键的三岔路口时，应该做出及时准确的方向判断，切忌优柔寡断，这是需要相当的勇气的，也是敢于承担责任的一种气魄。四、细心：当项目达到一定规模的时候，由于精力有限，不可能细化到每个人每个点，肯定会出现管理的盲区，这样不但需要划分好层次、层层监督，同时也需要对个别点进行抽查抽测，不能亲历亲为只靠一些小范围的会议交流总结，往往不能准确的定位到问题的关键点上。五、公正：不管在什吗样规模的开发团队里，维系团队精神、使团队更加具有凝聚力最根本的原则就是做事公正，很难想象一个人心涣散、充满怨言的团队能够做出高品质的产品。六、迭代：我在这里所说的迭代不单单指程序代码的迭代，它是一个 PM 在项目进行过程中不断总结经验教训不断完善的一种迭代。只有勇于批评和自我批评的人才能够不断的完善自己，不断的进步，成为一名合格的项目经理。

这里定义的项目经理是狭义的，单指软件项目经理。既然说到软件行业的项目经理，当然就不得不说一下软件行业，个人认为当今的软件行业公司大体可以分为三类：一流软件公司开发标准如 Sun 公司、微软等（开发当今主流的语言如 java 、 C# ）；二流软件公司在遵循标准的前提下开发规范、定制流程如 IBM 、 BEA 等（开发各种中间件，定制业内遵守的流程规范）；三流软件公司在遵循标准、依托规范的前提下做应用，如。。。（太多了不赘述了）。当然我的这种划分单指就软件领域而言，并不代表公司的综合实力及财富排名的位置。（大家不要用鸡蛋扔我哦，要扔就用人民币吧，嘿嘿）

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