- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
关于本书
这是一本强调实践、注重实效、轻量级、面向开发者的软件架构指南。你将从中学到:
软件架构的本质;
为什么软件架构角色应当包含编码、指导与合作;
开始编码前真正需要思考的事情;
如何用简单的草图让你的软件架构可视化;
为软件生成文档的轻量方法;
为什么敏捷和架构并不冲突;
“恰如其分”的预先设计是什么意思;
如何通过风险风暴来识别风险。
这部短文集推倒了传统的象牙塔,模糊了软件开发和架构在流程中的界限,将教会你软件架构、技术领导力以及它们与敏捷之间的平衡。
本书写作初衷
跟很多人一样,我的职业生涯从软件开发开始,从前辈那里得到指导,和团队一起工作,交付软件系统。久而久之,我也开始设计软件系统中的一小部分,最后我的职务变成了这样:承担我现在认为是设计软件架构的任务。
我的职业生涯多数是为IT咨询机构工作,这意味着我参与过的大多数项目要么是为客户构架软件系统,要么是和客户一起完成构建。IT咨询机构要发展壮大,就需要更多的人和团队。要组建更多团队,又需要更多的软件架构师。这就是我写这本书的理由。
1.软件架构应该容易理解。第一次设计软件架构时,尽管有一些优秀的导师,但我还是搞不清自己该干些什么。的确,有很多软件架构方面的书籍,但它们的写作视角不一样。我发现其中大多数都偏研究方向,甚至完全是学术派,而我是一个寻求现实建议的软件开发者。我想写一本对我职业生涯的那个阶段有用的书,即面向软件开发者的软件架构书。
2.所有软件项目都需要架构。我真心喜欢敏捷方法,但其中很多方法缺乏对软件架构的明确重视,这让我如坐针毡。敏捷方法不是说不应该做任何预先设计,但它们通常也不明确探讨这一点。我发现这会让人们得出错误的结论,我也看到了缺乏预先思考可能造成的后果。我非常清楚大型预先设计也不能解决问题。我感觉适当地做一些预先思考能提供一种愉快的中间状态,而这特别适合与不同经验和背景的团队一起工作的情形。我更喜欢轻量的软件架构方法,这样我就可以尽早让一些结构单元到位,从而提高成功率。
3.传播轻量级软件架构实践。这些年我学习和实践了很多对设计软件架构很有帮助的做法。这些实践涉及软件设计流程,并通过发现技术风险来沟通和记录软件架构。我总是认为这些实践都合理,但情况并非如此。过去几年,我向上千人教授这些实践,并见证了他们的变化。写书可以帮助我把这些想法传递给更多人,希望其他人也能从中受益。
软件开发的新方法
这本书不谈创造软件开发的新方法。传统软件开发经常会过度地预先思考,而初次接触敏捷方法的团队往往又缺乏架构思维,本书就是想要在这两者之间找到一个很好的平衡点。最终要告诉大家,预先设计与演化架构是可以共存的。
关于软件架构,每个开发者都应该知道的五件事
为了帮助你大致了解本书的内容,这里有每个开发者都应该知道的五件有关软件架构的事。
1. 软件架构不是大型预先设计
软件架构历来被认为跟大型预先设计和瀑布式项目有关,团队要周全地考虑软件设计的所有细节,然后才开始编码。软件架构就是关于软件系统的高层次结构,以及你如何理解它。它是影响软件系统形态的重要决策,而非理解数据库每个字段应该有多长。
2. 每个软件团队都需要考虑软件架构
不论产品的大小和复杂性,每个软件团队都需要考虑软件架构。为什么?简单地说,尚未发生的坏事往往都会发生!如果软件架构是关于结构和愿景的,不考虑这一点就可能产出结构糟糕、内部不一致的软件系统。这样的软件系统难以理解和维护,很可能无法满足一些重要的非功能需求,比如性能、可伸缩性或安全性。明确地考虑软件架构,提供了一种引入技术领导的方式,增加成功交付的胜算也对你有益。
3. 软件架构的角色关乎编码、指导和合作
很多人对软件架构师的印象还很老套,以为就是“象牙塔”软件架构师向毫不知情的开发团队面授机宜。其实并非如此,因为现代软件建构更倾向于成为一种有利于编码、指导和协同设计的方法。软件架构的角色不一定要由一个人来承担,而且要了解得到的架构是否确实行得通,编码是非常好的方式。
4. 无需使用UML
同样地,传统观点还以为软件架构就是试图捕捉每一个细节的庞大UML模型。创造和交流共同的愿景很重要,然而你不见得需要使用UML。实际上,可以说UML并不是一个交流软件架构的好方法。如果要保留一些简单的指导方针,轻量级“框线”风格的草图是一个交流软件架构的有效方式。
5. 好的软件架构是支持敏捷开发的
有一种普遍的误解,认为“架构”和“敏捷”之间是矛盾的。但恰恰相反,好的软件架构是支持敏捷的,可以帮助你拥抱并实现变化。然而好的软件架构并非与生俱来,需要你努力争取。
在微博上分享这本书
请帮Simon Brown 在新浪微博上宣传这本书。
推荐本书的微博以#程序员必读之软件架构#开头。
点击下面这个链接,在新浪微博上搜索其他人对本书的评价: http://huati.weibo.com/k/程序员必读之软件架构
软件架构培训
我开设了一个一到两天的培训课程,进行实用的轻量级软件架构指导,这个课程涵盖了本书全部内容。你将学到:
软件架构的本质;
为什么软件架构角色应当包含编码、指导与合作;
开始编码前真正需要思考的事情;
如何用简单的草图可视化软件架构;
为软件生成文档的轻量方法;
为什么敏捷和架构并不冲突;
“恰如其分”的预先设计是什么意思;
如何通过风险风暴来识别风险。
我将向你教授软件架构、技术领导力以及它们与敏捷之间的平衡。我在2013年软件架构师大会上所做的演讲“Software Architecture & the balance with agility”的视频http://vimeo.com/user22258446/review/79382531/91467930a4] 是对本课程内容很好的概述。我的课程和专题研讨已在欧洲、中东和美国等20多个国家开展。
你可以选择授课方式,包括让我去你们办公室进行内训课程。了解更多细节,请访问http://www.codingthearchitecture.com/training/或发邮件至simon.brown@codingthearchitecture.com。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论