2. 概要 ABD—— 基于架构的开发模式，在微软， ADOBE 等公司中被使用，在 ACTIONSCRIPT ， JAVA 语言中作用非凡。奇怪的是在 PHP 界却相当落后。 有人说，掌握了 ABD ，就能够轻松项目管理，掌握了 ABD ，就离真正的架构师不远了。那么，你想了解 ABD 吗？ 本话题为你揭开基于架构的开发模式的秘密，解决代码可读性，可维护性，可扩展性，与程序员的无关性等问题，使你的项目管理技术更上一层楼，让你走上架构师之路。 3. 两种截然不同的结果 …… …… 统一标准的架构，人人清楚哪个目录是什么，每一个源码文件都是 class 有多少个应用，就有多少种架构 无论大小，架构永远不变 应用越是庞大，架构是越是混乱 抄袭，原创，结果只有一个 高手，新人，质量相距甚远 程序员风格对程序结构的影响力几乎为零。独立开发，团队如同一人。 程序员风格对程序结构存在较大的影响。结伴编程，仍是正草隶篆。 代码可读性高，与程序员无关性高。 代码不具有可读性，与程序员无关性差。 用最简的《编程规范》，但代码仍相当规范 有极为详细的《编程规范》却代码仍不规范 我们最想要的 我们最不想要的 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? 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 Editor's Notes #8: 首席软件架构设计师 雷 · 奥兹 #12: 自从需要开发团队来完成开发软件开始，架构管理就产生了。但它早期只属于大公司的技术，而不是可用来卖钱的概念。大公司将其做到了产物之中
