应用程序框架设计资料.pdf

应用程序框架设计之前言 要做一个应用程序框架的念头Bigtall 在几年前就有了，因为在工作中发觉很多方面非常的 不顺手，几乎每一个环节都存在这样或者那样的问题：  公司不同项目组做的设计是完全不同的风格，而且设计做不细，导致项目计划越来 越流于形式  各层代码凌乱，从后台的java 或者c#到前台的html，天马行空，随心所欲  数据库结构和文档不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的 名字 如果深入到设计方面，就会发现虽然做过很多的项目，但是几乎没有可以参考的成功案例， 所有的设计哪怕是同类型项目，也几乎要重头开始；编码方面就更加麻烦了，我最深刻的印 象就是从业以来我编制了无数的字符串处理函数，有c/c++版本的，有C#版本，有java 版 本的，还有delphi 和早已忘记的vb ，当然，更少不了时下流行的js 了（这还是好的呢）。 一旦到了项目规模较大的时候，我们甚至会在代码流程中迷路，不知道调用从哪里来，不知 道逻辑要往哪里跳。 这么多的问题，是广大的处于CMM 1 级的软件企业共同存在的问题，当然也会出现在那些 CMM2345 实际还是CMM1 的软件企业中。加入管理手段（比如真正去实施CMM 规范） 可以解决大部分的问题，准确地说是可以解决几乎所有的管理问题并缓解大部分的技术问题， 但是解决不了所有的问题。 以前bigtall 在的公司曾经出现过这种论调“技术是不重要的，市场和管理才是最重要的”，最后公 司走入了低谷，好不容易聚集的人才也散了。别人的教训就是自己的经验，bigtall 后来进行深刻 的反思，认为这里有一个“度”的问题，我们先看两个极端“只有市场和管理但是没有技术”“只有技 术没有市场和管理”的后果，一个是“守不住”，一个是“推不了”。其实两者是相辅相成的，技术可 以把市场的门槛推高，市场和管理可以让技术更顺利地发展。所以一个公司没有“最好”的技术， 只有“最适合”的技术。一个公司的技术目标应该也只应该是“不断降低公司的成本”。 最明显的就是项目系统设计的重用问题，无论你是CMM 多少级，如果没有一个统一的软件 架构，重用就会打折扣甚至根本就无法重用。就像南方人北方人沟通要用普通话，今人和古 人沟通就必须用相同的文字（顺便鄙视并可怜一下朝鲜、韩国和越南）一样，前后的项目要 能够沟通交流，他们就需要一个相同的结构。所以“程序框架”就是公司项目之间的“普通话”， 也是项目内部的“润滑剂”。 这里要明确一下“程序框架（Framework）”和“软件架构（Architecture ）”之间的区别，简单地说， 程序框架是一个可以实际应用的代码集合，而软件架构可以看作是一种抽象的设计。另外，两者 的关注面也不一样，程序框架热衷于解决实际运行过程中的问题，甚至会提供工具包或者辅助模 块（比如权限系统、日志系统等），而软件架构则集中精力在各个部分（模块、组件等）之间的 关系。两者其实是关于同一个事情的不同层次的东西。 我们可以来看一下如果存在程序框架会让文章开头的几个问题解决多少： 1. 如果有程序框架，因为项目的WBS 几乎是一致的，所以上一个项目的项目计划可 以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越 来越实用。 2. 设计过程中，除了需求之外，概要设计、详细设计的重用性会很高。 3. 因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的 大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码 逻辑简单有序，所以测试起来会很容易。 4. 降低管理成本，除了项目计划之外，测试计划，QA 计划等等都可以重用，如果用 CMM 规范，项目评审的速度和质量都会有提高。 要做一个应用程序框架并不是一件容易的事情，一是这方面发展很快，而且水平相对较高， 如果没有独到的解决方案，可能自己的框架一出来就过时了。二是应用程序框架涉及的方面 较多，考虑清楚并不是一件容易的事情。三则是开发一个应用程序框架需要耗费大量的时间， 也就是意味着公司需要花费（你的工资×开发时间+其他）这么多的金钱。 对于小公司来说，除非有着清醒的认识，否则开发自己的应用程序框架可能是自寻死路。bigtall 建议小公司如果.net 开发，则直接用Petshop4 的框架，如果java 开发，则直接使用appfuse 进行开发，如果想要一个新的语言，则直接用Ruby On Rails 开发吧。对于php 没有建议，不