换句话说，项目的每一个工作与时间的关系都必须是“线性”的。如果实在不能排除“非线性”的工作，也必须在“可控”的范围内，项目内部不允许有“不可控”的“非线性”因素存在。
一句话： 脑筋动得越多，事情做得越慢!
到底项目中究竟有多少因素是属于“不可控”呢?哪些又是属于“可控”的?哪些属于“线性”因素?要回答这个问题，我们首先来看一下我们目前的软件开发方式和流程吧：
(一)接单签订合同
(二)需求调研、分析
(三)架构设计、概要设计
(四)详细设计
(五)编码、测试
(六)交付、维护
大致六个步骤，其中三四五是和我们谈得开发过程相关联(其他部分我会在以后的系列文章中讨论)。首先我们看第三点和第四点，他们统称为“设计”，参考文献2中给出的“设计”阶段的目标是解决四方面的问题：数据结构，软件体系结构，过程细节，接口性质。
有经验的读者我想已经看出来了，传统的“设计”所解决的问题，有相当一部分应该归纳为现在的“架构”范围内。软件架构涉及的范围主要包括如下：
(一)应用程序的层次划分(比如界面层，存储层等)，
(二)部分应用程序模块的划分(比如初始化模块，配置模块，权限模块等)，
(三)部分应用程序模块的实现(权限、用户、组织机构管理等)，
(四)函数库的实现，
(五)各模块、层之间的相互关系和通讯机制，
(六)相关的部分数据结构定义。
如此可见，上文中的第三和第四点最重要和最基础的工作基本就在“架构”范围内，剩下的工作，基本就是跟具体业务相关的了。
在上文的三个“xx设计”中，架构设计的时间最难控制和估算，概要设计和详细设计因为就是直接从需求条目演化而来，而且容易细化(以后我会有文章专门讨论)，所以虽然也是属于“设计”这种“非线性”工作，但是“可控性”要比“架构”强很多。从个人的项目维护经验来看，维护过程中产生的问题，有相当一部分是因为用户需求突破了原先架构的能力所致，而正是这种问题，才是拖延时间最长，引起客户反映最强烈，也是维护人员最痛苦最头痛的问题。因此，“架构设计”我把它归类到“非线性”工作中，而且是“难点”工作。
我看到很多的公司软件部门都叫做“研发部”，用英文说就是research and development的部门，但是我很少看到有公司把research和development分开做两个部门的。这有什么关系呢?从上文我们可以看到，研究是一种非常耗费资源的工作，而且风险(尤其是技术风险)很大，很可能因为一个小技术难题不能突破而导致整个架构推翻重来，而开发的风险则要小得多，可控得多;另外一个大的区别就是研究并不直接创造价值，而开发则跟公司的收入密切相关。基于这两个理由，就足够把“研究”和“开发”完全分开成两个部门了。其他当然还有许多的区别，比如考核方式等。
分开之后的工作如何分配?很简单，就是把“软件架构”和其他有难度的“非线性”工作统统交给高手云集的“研究”部门去做;具体项目相关的业务和实现(“线性”的工作)交由“开发”部门去做，因为他们对技术要求不高，而且成本较低。说到这里，我是不是在主张每一个公司都需要专人去“研究”技术呢?恰恰相反，我主张大部分公司都不需要设立“研究”部门，至少大部分公司不要去研制甚至试图研制所谓“自己的”软件架构。因为软件架构相比具体业务有一定的独立性，并没有一种“特别适合”于某类业务的“软件架构”存在，即使有，它也是应该经过N个项目的M年考验之后才会出现(N*M>10年)。我相信SAP会有这样的架构，但是国内公司基本不会有(也许有，但是请大家理解我的怀疑)。现在市面上有很多开源的架构存在，选一个吧，然后去培训你的员工，不断地培训，指导他们能够熟练地将这个架构应用到项目中去为止，即使这样，你的总花费也还远远小于请一个“高手”开发一个失败架构的投入。
如何来选择一个现成的架构已经不在文章讨论范围之内了，因为我接下来要谈的是“如何开发一个自己的架构”，不过也不用慌，如果你的开发语言是java的话，那么恭喜你，很多好用的开源架构都是java的，比如spring MVC，struts/webwork，tapestry;如果你用的是.net平台，那么微软已经帮你做了一个浅层的封装，或者干脆用.net的petshop或者Duwamish的架构就可以了。
责任编辑：张瑶
您现在的位置： 