应用程序框架设计之前言 要做一个应用程序框架的念头Bigtall 在几年前就有了，因为在工作中发觉很多方面非常的不顺手，几乎每一个环节都存在这样或者那样的问题： 公司不同项目组做的设计是完全不同的风格，而且设计做不细，导致项目计划越来越流于形式 各层代码凌乱，从后台的jav a 或者c#到前台的html，天马行空，随心所欲 数据库结构和文档不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的名字 如果深入到设计方面，就会发现虽然做过很多的项目，但是几乎没有可以参考的成功案例，所有的设计哪怕是同类型项目，也几乎要重头开始；编码方面就更加麻烦了，我最深刻的印象就是从业以来我编制了无数的字符串处理函数，有c/c++版本的，有C#版本，有jav a 版本的，还有delphi 和早已忘记的v b，当然，更少不了时下流行的js 了（这还是好的呢）。一旦到了项目规模较大的时候，我们甚至会在代码流程中迷路，不知道调用从哪里来，不知道逻辑要往哪里跳。 这么多的问题，是广大的处于CMM 1 级的软件企业共同存在的问题，当然也会出现在那些CMM2345 实际还是CMM1 的软件企业中。加入管理手段（比如真正去实施 CMM 规范）可以解决大部分的问题，准确地说是可以解决几乎所有的管理问题并缓解大部分的技术问题，但是解决不了所有的问题。 以前bigtall 在的公司曾经出现过这种论调“技术是不重要的，市场和管理才是最重要的”，最后公司走入了低谷，好不容易聚集的人才也散了。别人的教训就是自己的经验，bigtall 后来进行深刻的反思，认为这里有一个“度”的问题，我们先看两个极端“只有市场和管理但是没有技术”“只有技术没有市场和管理”的后果，一个是“守不住”，一个是“推不了”。其实两者是相辅相成的，技术可以把市场的门槛推高，市场和管理可以让技术更顺利地发展。所以一个公司没有“最好”的技术，只有“最适合”的技术。一个公司的技术目标应该也只应该是“不断降低公司的成本”。 最明显的就是项目系统设计的重用问题，无论你是CMM 多少级，如果没有一个统一的软件架构，重用就会打折扣甚至根本就无法重用。就像南方人北方人沟通要用普通话，今人和古人沟通就必须用相同的文字（顺便鄙视并可怜一下朝鲜、韩国和越南）一样，前后的项目要能够沟通交流，他们就需要一个相同的结构。所以“程序框架”就是公司项目之间的“普通话”，也是项目内部的“润滑剂”。 这里要明确一下“程序框架（Framew...
