基于架构的开发模式

1,346 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,346
On SlideShare
0
From Embeds
0
Number of Embeds
194
Actions
Shares
0
Downloads
33
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 首席软件架构设计师 雷 · 奥兹
  • 自从需要开发团队来完成开发软件开始,架构管理就产生了。但它早期只属于大公司的技术,而不是可用来卖钱的概念。大公司将其做到了产品之中
  • 基于架构的开发模式

    1. 1. ABD—— 基于架构的开发模式 上海湃睿信息科技有限公司 Bardo QI ( 祁宏 ) 2010 年 7 月 30 日
    2. 2. 概要 <ul><li>ABD—— 基于架构的开发模式,在微软, ADOBE 等公司中被使用,在 ACTIONSCRIPT , JAVA 语言中作用非凡。奇怪的是在 PHP 界却相当落后。 </li></ul><ul><li>有人说,掌握了 ABD ,就能够轻松项目管理,掌握了 ABD ,就离真正的架构师不远了。那么,你想了解 ABD 吗? </li></ul><ul><li>本话题为你揭开基于架构的开发模式的秘密,解决代码可读性,可维护性,可扩展性,与程序员的无关性等问题,使你的项目管理技术更上一层楼,让你走上架构师之路。 </li></ul>
    3. 3. 两种截然不同的结果 …… …… 统一标准的架构,人人清楚哪个目录是什么,每一个源码文件都是 class 有多少个应用,就有多少种架构 无论大小,架构永远不变 应用越是庞大,架构是越是混乱 抄袭,原创,结果只有一个 高手,新人,质量相距甚远 程序员风格对程序结构的影响力几乎为零。独立开发,团队如同一人。 程序员风格对程序结构存在较大的影响。结伴编程,仍是正草隶篆。 代码可读性高,与程序员无关性高。 代码不具有可读性,与程序员无关性差。 用最简的《编程规范》,但代码仍相当规范 有极为详细的《编程规范》却代码仍不规范 我们最想要的 我们最不想要的
    4. 4. 什么是软件开发模式 <ul><li>软件开发模式的定义包含两方面: </li></ul><ul><ul><li>其一是指软件开发中的管理模式,即在软件开发过程中要管理什么,怎样管理。 </li></ul></ul><ul><ul><li>其二是指软件开发中的操作规范,包括开发流程定义,即按照什么样的步骤来开发软件。 </li></ul></ul><ul><li>有了敏捷,真的还会这么痛苦吗? </li></ul><ul><ul><li>本主题阐述软件开发模式与架构管理模式之间的关系。并以 PHP 应用架构管理为中心,讲述架构管理的沿革, PHP 架构管理现状,以及架构管理中一些必要的原则、 PHP 大型应用的基本架构等。 </li></ul></ul><ul><li>时间有限,内容太多,无法进行实例讲解,敬请谅解! </li></ul>
    5. 5. 新型软件开发模式简介 <ul><li>SCRUM 由 Ken Schwaber 和 Jeff Sutherland 提出和倡导 </li></ul><ul><ul><li>敏捷开发模式 </li></ul></ul><ul><ul><li>sprints 短周期循环, scrum 会议,以及 burn down graph 管理 </li></ul></ul><ul><li>XP (eXtreme Programming) 由 Kent Beck,Ward Cunningham,Ron Jeffries 提出和倡导 </li></ul><ul><ul><li>TDD 与连续性整合 </li></ul></ul><ul><ul><li>结伴编码 </li></ul></ul><ul><li>ASD ( Adaptive Software Development )由 Jim Highsmith 提出和倡导 </li></ul><ul><ul><li>speculate,collaborate,and learn (将项目的历程分成 3 个阶段:思索、合作、学习 </li></ul></ul><ul><ul><li>TimeBoxed 时间盒管理 </li></ul></ul><ul><li>MSF(Microsoft Solutions Framework) 由 Randy Miller,Paul Haynes 提出,微软倡导 </li></ul><ul><ul><li>使用者角色 (Personals) 推行一个从角色到使用方案的设计流程 </li></ul></ul><ul><ul><li>单元测试 </li></ul></ul>
    6. 6. 软件开发模式是否足够? <ul><li>“ 新型”开发模式普遍被接受并广应用: </li></ul><ul><ul><li>基于测试的开发( TDD ) </li></ul></ul><ul><ul><ul><li>先确定测试,以测试为中心。 </li></ul></ul></ul><ul><ul><li>敏捷开发模式 </li></ul></ul><ul><ul><ul><li>如前述的 SCRUM , XP 开发模式 </li></ul></ul></ul><ul><ul><li>代码制质量控制: </li></ul></ul><ul><ul><ul><li>code review </li></ul></ul></ul><ul><ul><ul><li>结伴编程 </li></ul></ul></ul><ul><li>PHP 使用“新型”开发模式产出的软件? </li></ul><ul><ul><li>BUG 依旧 </li></ul></ul><ul><ul><li>可靠性仍然很差 </li></ul></ul><ul><ul><li>最后期限仍不可预估 </li></ul></ul><ul><ul><li>与程序员无关性仍不够理想 </li></ul></ul><ul><ul><li>当需求变更经常仍是牵一发动全身 </li></ul></ul>
    7. 7. 项目管理的两个方面 <ul><li>软件开发模式 </li></ul><ul><ul><li>它是属于管理层的 </li></ul></ul><ul><ul><li>是软件工程管理 </li></ul></ul><ul><ul><ul><li>归口:项目经理 </li></ul></ul></ul><ul><li>软件架构管理 </li></ul><ul><ul><li>它是属于技术层的 </li></ul></ul><ul><ul><li>是软件架构与编码管理 </li></ul></ul><ul><ul><ul><li>归口:软件架构师(注:架构师不只是管软件架构,同时还有系统架构) </li></ul></ul></ul><ul><li>先下个结论: </li></ul><ul><ul><li>只有敏捷(或者某一天来一个更高级的开发模式)——仍然没用! </li></ul></ul><ul><ul><li>因为还有很多问题解决不了! </li></ul></ul>
    8. 8. 基于架构的开发模式 <ul><li>ABD——Architecture-Based Development </li></ul><ul><ul><li>本概念最早产生于 1999 年。 </li></ul></ul><ul><li>基于架构的开发模式 </li></ul><ul><ul><li>目标: </li></ul></ul><ul><ul><ul><li>ABC——Architecture-Based Coding( 基于架构编码 ) </li></ul></ul></ul><ul><ul><ul><li>AOP—— 面向切面编程( JAVA 中的术语) </li></ul></ul></ul><ul><ul><ul><li>ABD 主要面向应用的基本架构 </li></ul></ul></ul><ul><li>再下一个结论: </li></ul><ul><ul><li>架构管理比软件开发模式还要重要! </li></ul></ul><ul><ul><ul><li>原因:架构管理最终是在保证软件质量的前提下,保证工期! </li></ul></ul></ul><ul><ul><li>一个简单场景: </li></ul></ul><ul><ul><ul><li>小团队,小项目,有架构管理,无敏捷,它有可能成功 </li></ul></ul></ul><ul><ul><ul><li>小团队,小项目,无架构管理,有敏捷,它仍不能成功 </li></ul></ul></ul>
    9. 9. 并非新概念——架构的沿革 <ul><li>ABD 基于架构的开发模式 </li></ul><ul><ul><li>这一概念并非新概念。因为,我们一直在为架构奔走: </li></ul></ul><ul><ul><ul><li>DOC/VIEW (文档 / 视图结构) </li></ul></ul></ul><ul><ul><ul><li>UML/MDA ( Model-Driven Architecture ) </li></ul></ul></ul><ul><ul><ul><li>CORBA( 通用对象请求体系架构, IDL ) </li></ul></ul></ul><ul><ul><ul><li>WEB SERVICE (网络服务, WSDL ) </li></ul></ul></ul><ul><ul><ul><li>MVC </li></ul></ul></ul><ul><ul><ul><li>MTS ( Multi-Tier System ) </li></ul></ul></ul><ul><ul><ul><li>REST ( Representational State Transfer 表述状态转移) </li></ul></ul></ul><ul><ul><ul><li>SOA ( Service-Oriented Architecture ) </li></ul></ul></ul><ul><ul><li>我们时刻忙于一个概念,但没有考虑我们应用的架构 </li></ul></ul><ul><ul><ul><li>其它编程语言不需要 </li></ul></ul></ul><ul><ul><ul><li>但 PHP 没有它不行! </li></ul></ul></ul>
    10. 10. 模式管理 VS 架构管理 <ul><li>模式管理 </li></ul><ul><ul><li>你何时完成 </li></ul></ul><ul><ul><li>你做出来 </li></ul></ul><ul><ul><li>实现功能,完成测试,无法保证与程序员无关性 </li></ul></ul><ul><li>架构管理 </li></ul><ul><ul><li>你何时怎样完成 </li></ul></ul><ul><ul><li>你必须这样做出来 </li></ul></ul><ul><ul><li>不仅只要求实现,同时限制了你怎样实现,因而保证了与程序员的无关性 </li></ul></ul>
    11. 11. 都是 PHP 惹的祸!! <ul><li>架构管理随团队产生!随应用的复杂而增强。 </li></ul><ul><ul><li>MFC—— 架构:一切都是类, DOC/VIEW 分离。 </li></ul></ul><ul><ul><li>VB6.0 ,由向导为你产生合理的软件架构。 </li></ul></ul><ul><ul><li>VS.net—— 把架构用到的 WEB 应用之中 </li></ul></ul><ul><ul><li>JAVA——SSH+(JSF 、 Tapestry) 的运用是良好架构的保证 </li></ul></ul><ul><ul><li>ruby——Ruby On Rails 是良好架构的框架 </li></ul></ul><ul><li>很明显,架构管理, 首先要有好的开发框架。 </li></ul><ul><ul><li>PHP ?? </li></ul></ul><ul><ul><ul><li>zend? </li></ul></ul></ul><ul><ul><ul><li>symfony? </li></ul></ul></ul><ul><ul><ul><li>codeigniter? </li></ul></ul></ul><ul><ul><ul><li>yii? </li></ul></ul></ul>
    12. 12. 从现有其它语言看架构管理目标 <ul><li>第一:以往是:要有详细的与源程序一致的开发设计文档。现在的要求是:程序就是文档。即程序的风格一致,具有“最高”的可读性! </li></ul><ul><li>第二:可维护性,可测试性高,开发周期短, </li></ul><ul><li>第三:具有高度的与程序员无关性 </li></ul><ul><li>第四:最少限度的修改。最高限度的代码重用。 </li></ul>
    13. 13. 现有的架构技术 <ul><li>其它编程语言发展,给我们留下了很多的架构技术 </li></ul><ul><ul><li>从 DOC/VIEW 到 MVC </li></ul></ul><ul><ul><li>从三层架构到多层架构 </li></ul></ul><ul><ul><li>从数据库操作封装到 DMM , </li></ul></ul><ul><ul><li>ORM 新技术的流行: ActiveRecord,TableDataGetway </li></ul></ul><ul><ul><li>从面向对象,到设计模式。 </li></ul></ul><ul><li>我们要问,这些技术有用吗?帮助我们解决了什么问题? </li></ul>
    14. 14. 关于 MVC <ul><li>MVC—— 用一个标准实现完全面向对象,从而实现与程序员无关性 </li></ul><ul><ul><li>把用户界面实体和其对应的代码分开。 </li></ul></ul><ul><ul><ul><li>用户界面实体:即是视图 VIEW </li></ul></ul></ul><ul><ul><li>对应界面实体的代码实体,使用事件映射,实现事件驱动模型。这个对应视图的代码即是模型 Modal </li></ul></ul><ul><ul><ul><li>你如果会 JAVA SSH ,或 VS.NET ,你会发现,你只能编写这样的模块 </li></ul></ul></ul><ul><ul><li>而实现事件映射的,则是控制器 Controller 。 </li></ul></ul><ul><ul><li>这就是人们所说的 MVC 。 </li></ul></ul>
    15. 15. 在 MVC 基础上的编程规范 <ul><li>在 MVC 基础上的编程规范——简易的规范能够更进一步实现代码与程序员的无关性。 </li></ul><ul><ul><li>MVC 所有模块均是面向对象模式的类。完全面向对象,则实现了第一层次的代码与程序员的无关性 </li></ul></ul><ul><ul><li>在此基础上,只要规定: </li></ul></ul><ul><ul><ul><li>每个类都是单一职责的 </li></ul></ul></ul><ul><ul><ul><li>每个函数都是单一输入输出的 </li></ul></ul></ul><ul><ul><li>于是,则更加进一步保证了代码与程序员的无关性 </li></ul></ul><ul><ul><li>注意: MVC 可以实现完全面向对象,非面向对象,也可以做到 MVC ,这里不是把 MVC 当成目标,而是把完全面向对象作为目标。同时,成熟的 MVC 架构,应当是符合 IOC 模式的。 </li></ul></ul>
    16. 16. 关于 DMM 、 DDD <ul><li>DMM—— 把纯数据操作与业务逻辑分隔成不同的输入输出单元,进一步简化代码,增强可读性,可维护性,可扩展性 。 </li></ul><ul><li>DMM 是指领域模型 (Domain Modal) 。 DDD 则是 Domain Driven Development ,领域驱动设计 </li></ul><ul><li>MVC 实现了最早的三层结构:用户层,逻辑层,数据层。 </li></ul><ul><li>但数据层仍包括业务逻辑与数据访问。于是人们想到了进一步分开。即有了现在的多层结构。 </li></ul><ul><li>纯数据访问很简单,在 PHP 中,你可以直接使用 ADODB 。 </li></ul><ul><li>但现在人们为什么要用 propel 或者 doctrine? </li></ul><ul><ul><li>因为我们确实需要 DMM , DDD </li></ul></ul>
    17. 17. DDD 提供了什么? <ul><li>DDD 的目标,是处理系统业务逻辑。通常, DDD 把业务逻辑封装为: </li></ul>实体 值对象 规侧 服务 模块 聚合 工厂 资源库 <ul><li>本质上,将复杂的业务领域使用规范的,或遵循一种标准的编码方式来实现。其根本的目标,是可扩展,易变更,易维护。 </li></ul>
    18. 18. 关于 ORM <ul><li>ORM ,抽象数据操作类上面,再增加一层更具体的公用操作代码。 </li></ul><ul><li>数据层实现 DMM 的方式,通常是通过 ORM 实现的。 </li></ul><ul><li>ORM 是指 Object Relation Mapping ,即对数据库数据实现对象关系映射。 </li></ul><ul><li>作为 ORM ,这一技术最早流行是在 JAVA 中, Hibernat 是 JAVA 中用得最多的 ORM 框架。通过 Struts, Spring, Hibernat 即我们常说的 JAVA 的 SSH 构成了 JAVA 面向大型应用的框架。 </li></ul><ul><li>PHP 则是 propel 与 doctrine 最为有名。而 doctrine 属后起之秀。 </li></ul><ul><li>但随着 ROR 冲击, ActiveRecord 与 TableDataGetway 架构被引入到了 PHP 中,但 PHP 仍是相对落后。 </li></ul><ul><li>比如, RUBY 中,现在有更先进的 DrySql, 这在 PHP 中至今仍没有。 </li></ul>
    19. 19. 为什么要 ORM ? <ul><li>数据库操作,需要有大量的 CRUD 。 </li></ul><ul><li>只要有 CRUD ,就需要拼装 SQL 语句。 </li></ul><ul><li>ORM 把 CRUD 变成通用模块,于是,业务逻辑与纯数据操作就能分开。 </li></ul><ul><li>通过这一方式,开发中就可以省去大量的编码。 </li></ul><ul><ul><li>任何开发框架的最基本的目的, 就是让你开发时少写编码 </li></ul></ul>
    20. 20. 关于设计模式 <ul><li>设计模式让核心代码更加松耦合。同时增加易用性与可扩展性。 </li></ul><ul><li>例如,一些 PHP 框架中提供了 APP ,或 APPLICATION 类。实际上它常常是一个聚合模式的类(比如使用 FACADE 模式)。不仅方便使用,同时使得开发的代码规范、简单! </li></ul><ul><li>我们清楚:大型应用必不可少的有: Session , Logger , ErrorHandle , it18n , Validator , Filter </li></ul><ul><li>一些框架中就是用相关模式,将其聚合到了 APP 之中。为用户开发提供了极大的方便。 </li></ul>
    21. 21. 框架——要还是不要? <ul><li>不仅需要框架,而且要的是好框架。证据: </li></ul><ul><ul><li>JAVA 有 SSH + ( JSF 、 Tapestry) </li></ul></ul><ul><ul><li>vs.net 就是框架模式,( VC 最早的 MFC 就是框架) </li></ul></ul><ul><ul><li>RUBY 的成功,就是 ROR 框架的成功 </li></ul></ul><ul><li>对于程序员: </li></ul><ul><ul><li>你说了不算——编程规范太多,他不执行的! </li></ul></ul><ul><ul><li>程序说了算——所有程序,他都是要调通的! </li></ul></ul><ul><ul><ul><li>框架比编程规范还要有效!! </li></ul></ul></ul><ul><li>结论: </li></ul><ul><ul><li>架构管理,如果能借助一个好的框架,则相当方便。 </li></ul></ul><ul><ul><li>但是: PHP 框架选用,则是相当困难的一件事情 </li></ul></ul>
    22. 22. PHP 架构管理中框架的使用 <ul><li>三种方式: </li></ul><ul><ul><li>选用一个 PHP 框架 </li></ul></ul><ul><ul><ul><li>目前没有真正支持 VIEW 的框架 </li></ul></ul></ul><ul><ul><ul><li>SMARTY 不是标准的 VIEW 。( STRUTS 也不是) </li></ul></ul></ul><ul><ul><ul><ul><li>FLEX > .net > tapestry > JSF > struts > smarty </li></ul></ul></ul></ul><ul><ul><ul><li>标准的 VIEW 应当如同 VS.NET( 用过的人一定忘不了它的 WEBFOM , WEBTABLE ) </li></ul></ul></ul><ul><ul><li>DIY 一个适合自己的框架 </li></ul></ul><ul><ul><ul><li>很多 PHP 开源的软件都这样做,如 SUGAR CRM 。 </li></ul></ul></ul><ul><ul><ul><li>因为, ZEND 不可选, sysmfony 也不定完全适用于企业级开发。 PHP 还有什么? </li></ul></ul></ul><ul><ul><ul><li>但 DIY 的结果,仍没有我们想要的 VIEW 。 </li></ul></ul></ul><ul><ul><li>自己写一个框架 </li></ul></ul><ul><ul><ul><li>这是被指责为最不明智的。 </li></ul></ul></ul><ul><ul><ul><li>但如果真的写了,那可是自己享用的最方便的方式。 </li></ul></ul></ul>
    23. 23. 关于 VIEW <ul><li>VIEW 应当是什么样子? </li></ul><ul><ul><li>PHP 的悲剧: SMARTY 照抄 STRUTS , Prado 照抄 Tapestry , log4php 照抄 log4j…… </li></ul></ul><ul><ul><li>ActionScript 的 Flex 的成功:照抄 vs.net </li></ul></ul><ul><ul><ul><li>结论:开源的未必都是最领先的! </li></ul></ul></ul><ul><ul><ul><li>有时,有大公司投入财力研发后得出的结论,要比开源开发者拍脑袋想出来或抄出来的更具有参考价值。 </li></ul></ul></ul><ul><ul><li>真正的 VIEW 是界面部件化,从而实现整个软件使用方式与界面风格的一致性。这是软件易用性的基本保证! </li></ul></ul>
    24. 24. 为什么从 PHP 要转向 RUBY <ul><li>JSP 要编译。并且是强类型的。 </li></ul><ul><li>PHP 是非强类型无需编译就能运行的语言。 </li></ul><ul><li>同时它是开源的。 </li></ul><ul><li>语言本身的简易性是吸引用户的根本。 </li></ul><ul><ul><li>早期 JSP 开发人从 JAVA 走向了 PHP </li></ul></ul><ul><li>但开发者需要的是面对大型应用。 </li></ul><ul><li>ROR 为架构师的架构管理提供了方便。 </li></ul><ul><li>PHP 现状: </li></ul><ul><ul><li>面对大型应用,你只能有以下三种选择: </li></ul></ul><ul><ul><ul><li>降低对框架的要求——选用,或 DIY ,或自己写 </li></ul></ul></ul><ul><ul><ul><li>等待合适的框架出现(不太现实) </li></ul></ul></ul><ul><ul><ul><li>而今 PHP 开发人则转向 RUBY </li></ul></ul></ul>
    25. 25. 你是否会选择框架了? <ul><li>PHP 的 MVC 中没有真正易于架构管理的 VIEW 。如果这一目标放宽。我们可选的也是相当的少: </li></ul><ul><ul><li>symfony, prado, yii </li></ul></ul><ul><li>如果是小型应用,有人使用 </li></ul><ul><ul><li>codeigniter + log4php + htmlpurifer 再加其它应用需要的第三方开源,也是一个好办法。 codeigniter 最差的就是它的 logger 了。 </li></ul></ul><ul><li>官方框架: Zend Framework ,请谨慎选用! </li></ul><ul><li>敏捷开发模式——需要敏捷开发框架的支持! </li></ul>
    26. 26. 软件架构管理的具体目标 <ul><li>可靠性( Reliable )。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。 </li></ul><ul><li>安全性( Secure )。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。 </li></ul><ul><li>可升级( Scalable )。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。 </li></ul><ul><li>可定制化( Customizable )。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。。 </li></ul>
    27. 27. 软件架构管理的具体目标 <ul><li>可扩展性( Extensible )。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展。 </li></ul><ul><li>可维护性( Maintainable )。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。 </li></ul><ul><li>客户体验( Customer Experience )。软件系统必须易于使用。这与部件化 VIEW 是分不开的。 </li></ul><ul><li>市场时机( Time to Market )。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。只有好的框架才能提供最快速的开发! </li></ul>
    28. 28. 软件基本架构设计的一些原则 <ul><li>基本原则 </li></ul><ul><ul><li>分层—— MVC+DMM 多层结构(与框架有关) </li></ul></ul><ul><ul><li>重用——代码类库(与框架有关) </li></ul></ul><ul><ul><li>顺序——先界面,后数据库,最后编码( MVC 才能做到) </li></ul></ul><ul><ul><li>测试——日志管理(与框架有关),代码错误管理。版本管理。 </li></ul></ul><ul><li>团队原则 </li></ul><ul><ul><li>编码规范——限制程序员偏好 </li></ul></ul><ul><ul><li>项目词典——集中管理各类命名 </li></ul></ul><ul><ul><li>独立编码——要求按标准编码 </li></ul></ul><ul><ul><li>集中规范——以规范检查与验证 </li></ul></ul>
    29. 29. 好的架构应当是什么样子 <ul><li>用户界面(视图 view )部件化,实现界面风格与使用方式的一致性。 </li></ul><ul><li>除用户界面(视图 view )和入口文件之外,全部面向对象 </li></ul><ul><li>程序员能够实现 AOP—— 面向切面编程 </li></ul><ul><li>采用设计模式实现松耦合,可扩展。符合 SOLID 原则。 </li></ul><ul><li>所有的类是单一职责的,所有的函数是单一功能的。并且尽可能是单一输入输出处理模式的。 </li></ul><ul><li>所有命名:类、函数、常量、变量有《项目词典》为参照的标准进行规范。 </li></ul><ul><li>安全:输入验证,防 XSS ,防 SQL 注入。错误与日志管理。 </li></ul><ul><ul><li>一句话:实现与程序员无关性,同时实现架构管理目标。 </li></ul></ul>
    30. 30. 只有架构管理也能管好项目 <ul><li>不一定要敏捷。 PDCAR 也行! </li></ul><ul><ul><ul><li>plan 计划, do it 立即实施, check it 实施中检验, action again 吸取教训后再次行动 , record 继续备案供以后借鉴 </li></ul></ul></ul><ul><li>项目管理的关键: </li></ul><ul><ul><li>风险控制——设计阶段:对架构与技术风险的评估 </li></ul></ul><ul><ul><li>质量控制——良好的架构管理,保证编码质量 </li></ul></ul><ul><ul><li>进度控制——与程序员无关性的规范编码,工作量可知,进度可控。 </li></ul></ul><ul><li>结论:不是不要敏捷,而是说:架构管理不可少!敏捷开发模式——需要敏捷开发框架以及架构管理的支持! </li></ul>
    31. 31. 总结 <ul><li>ABD , AOP </li></ul><ul><ul><li>MVC——IOC </li></ul></ul><ul><ul><ul><li>module </li></ul></ul></ul><ul><ul><ul><ul><li>calss </li></ul></ul></ul></ul><ul><ul><ul><ul><li>event map or notation(action) </li></ul></ul></ul></ul><ul><ul><ul><li>view </li></ul></ul></ul><ul><ul><ul><ul><li>componnent-based </li></ul></ul></ul></ul><ul><ul><ul><li>control </li></ul></ul></ul><ul><ul><li>DMM , DDD </li></ul></ul><ul><ul><ul><li>Domain Driven Development </li></ul></ul></ul><ul><ul><ul><ul><li>Domain modal 、 busness modal </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>entity </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>value object </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>factory </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>specification mode </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>resource </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>service </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>aggregation </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>module </li></ul></ul></ul></ul></ul><ul><ul><li>ORM </li></ul></ul><ul><ul><ul><li>Active Record </li></ul></ul></ul><ul><ul><ul><li>Table Data Getway </li></ul></ul></ul><ul><ul><ul><li>DrySql </li></ul></ul></ul><ul><ul><li>Libraries </li></ul></ul><ul><ul><ul><li>database & other </li></ul></ul></ul>
    32. 32. 澎湃进取,睿智从容! Contact information: Hot Line: 400-620-9980 Website: www.pisx.com

    ×