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