敏捷思维-架构设计中的方法学 - read.docVIP

  1. 1、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
目录在这个关于软件工程的专栏里作者将应用敏捷方法学对软件开发过程中架构设计进行研究一从方法论看架构设计方法论重量方法论的艺术敏捷架构设计二架构设计的敏捷视图目标规则抽象架构的一些误解架构设计的过程模式敏捷型架构设计三源自需求针对需求设计架构从需求到架构仅针对需求设计架构模式抓住重点架构设计和领域专家四团队设计避免象牙塔式的架构设计选择你的设计团队团队设计中存在的问题团队沟通标准和风格团队设计的四明确不仅仅是架构五简单设计降低开发的成本提升沟通的效率考虑未来架构的稳定辨正的简单简单并不等于实现简单

目录在这个关于软件工程的专栏里,作者将应用敏捷方法学对软件开发过程中架构设计进行研究。一. 从方法论看架构设计 3 1. 方法论Methodology 3 2. 重量 4 3. 方法论的艺术 5 4. 敏捷 5 5. 架构设计 5 二. 架构设计的敏捷视图 6 1. 目标 6 2. 规则 6 3. 抽象 7 4. 架构的一些误解 8 5. 架构设计的过程模式 8 6. 敏捷型架构设计 9 三. 源自需求 9 1. 针对需求设计架构 10 2. 从需求到架构 10 3. 仅针对需求设计架构 11 4. 模式 11 5. 抓住重点 12 6. 架构设计和领域专家 12 四. 团队设计 13 1. 避免象牙塔式的架构设计 14 2. 选择你的设计团队。 14 3. 团队设计中存在的问题 14 4. 团队沟通 14 5. 标准和风格 15 6. 团队设计的四明确 15 7. 不仅仅是架构 16 五. 简单设计 16 1. 降低开发的成本 17 2. 提升沟通的效率 17 3. 考虑未来 17 4. 架构的稳定 17 5. 辨正的简单 18 6. 简单并不等于实现简单 18 7. 简单设计需要什么样的设计师 18 8. 更深入的理解 19 六. 迭代设计 19 1. 初始设计和迭代设计 20 2. 单次的迭代 20 3. 迭代的交错 20 4. 迭代频率 21 5. 如何确定软件的迭代周期 21 6. 迭代周期和软件架构的改进 21 7. 实例 21 七. 组合使用模式 23 1. 四种模式的着重点 23 2. 需求和迭代 24 3. 简单和迭代 25 4. 团队和简单 25 5. 模式的源头 25 八. 架构愿景 25 1. 架构愿景的层次 26 2. 架构愿景的形成过程 27 3. 使用架构模式 27 九. 分层(上) 28 1. 实例 29 十. 分层(下) 32 1. 何时使用分层技术? 32 2. 如何使用分层技术? 33 3. 如何存放数据(状态)? 33 4. 处理好接口 33 5. 兼顾效率 33 6. 以迭代的方式进行分层 34 7. 层内的细分 34 8. 面向接口编程 34 9. 数据映射层 36 10. 总结 36 十一. 精化和合并 36 1. 实例 37 十二. 重构(Refactoring) 40 1. 防止改变的发生 40 2. 对软件架构进行重构 41 3. 重构到模式 41 4. 测试行为 41 5. 只针对有需要的设计进行重构 42 6. 使用文档记录重构的模式 42 7. 重构并保持模式的一致性 42 十三. 稳定化 42 1. 需求冻结 42 2. 稳定架构 43 3. 保证架构稳定的优秀实践 43 4. 总结 45 十四. 代码验证 45 1. 面向对象体系中的代码验证 45 2. 接口和架构 45 3. 测试驱动 46 4. 针对接口的测试 47 5. 测试网 47 6. 总结 47 十五. 进一步阅读 47 十六. 关于作者 50 从方法论看架构设计 方法论对软件开发而言意味着什么?我们如何看待软件开发中的方法论?方法论能够成为软件开发的救命稻草吗?在读过此文后,这些疑惑就会得到解答。 在第一篇文章中,我们来了解标题中的一些词的含义。 方法学是什么? 敏捷是什么? 为什么讨论架构? 方法论Methodology 方法论的英文为Methodology,词典中的解释为A series of related methods or techniques我们可以把它定义为软件开发(针对软件开发)的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题,我很赞同Alistair Cockburn的一句话,方法论源于恐惧。出于对项目的超期、成本失控等等因素的恐惧,项目经理们从以前的经验出发,制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原因。 在Agile Software Development一书中,作者提到了方法论的十三个要素,基本能够涵盖方法论的各个方面: 角色(Roles) 个性(Personality) 技能(Skills) 团队(Teams) 技术(Techniques) 活动(Activities) 过程(Process) 工件(Work products) 里程碑(Milestones) 标准(Standards) 质量(Quality) 工具(Tools) 团队价值(Team Values) 它们之间的关系可以用一幅图来表示: 图 1. 方法论的十三个要素 很多的方法论,都涉及了上面列举的十三要素中的部分要素,因此,我们可以把方法论看作是一个抽象的、无穷的超集,而现实中的方法论都是指超集的一个有限的子集而已。它们之间的关系就好像有理数和1到100之间的整数的关系一样。

文档评论(0)

wangsux + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档