具体描述
软件架构，可以说是为特定的应用软件创建一个蓝图设计。软件架构中存在两大挑战：首先，软件架构与需求必须保持一致，对尚未发现的需求或者发生演化的需求都是如此；其次，尽管常常发生架构实现的变更，但软件架构与其对应的架构实现必须保持一致。本书包含很多示例和用例，通过这种直观的方法来帮助你获取成为一名成功的软件架构师所需的一切。本书将帮助你了解Python的来龙去脉，以便可以用Python来构建和设计高度可扩展的、健壮的、简洁的、性能强大的应用程序。
作者简介
Anand Balachandran Pillai是一名工程技术专家，在软件企业有18年以上的工作经历，在产品工程、软件设计、架构设计和相关研究方面具有非常丰富的经验。他曾获得印度理工学院机械工程专业的学士学位。曾在Yahoo!、McAfee和Infosys等公司任职，担任产品开发团队的首席工程师。他的主要兴趣在于软件性能工程、高可扩展性架构、安全和开源社区等方面。他也经常在Startups工作，担任首席技术专家或顾问。他还是班加罗尔Python用户联盟的奠基人和Python软件协会（PSF）的会士。Anand现在是Yegii公司的首席架构师。
(评审人)Mike Driscoll从2006年开始使用Python。他喜欢写一些关于Python的博客，见http://www.blog.pythonlibrary.org/。他曾合著了《the Core Python refcard for DZone》一书，并参与了《Python 3 Object Oriented Programming》、《Python 2.6 Graphics Cookbook》、《Tkinter GUI Application Development Hotshot》的评审工作和其他几本书的撰写工作。他最近刚完成《Python 101》的编写，目前正在写作他的下一本书。
目录信息
关于作者
关于评审人
前言
第1章 软件架构原理 1
1.1 软件架构定义 2
1.1.1 软件架构与设计 2
1.1.2 软件架构相关的几个方面 3
1.2 软件架构的特征 3
1.2.1 用架构来定义一种结构 3
1.2.2 由架构来挑选一组核心元素 4
1.2.3 由架构来捕获早期的设计决策 4
1.2.4 由架构来管理利益相关者的需求 5
1.2.5 架构影响着组织结构 5
1.2.6 架构受到环境的影响 6
1.2.7 架构是对系统的文档化 6
1.2.8 架构通常会遵循某个模式 7
1.3 软件架构的重要性 7
1.4 系统架构与企业架构 8
1.5 架构的质量属性 10
1.5.1 可修改性 11
1.5.2 可测试性 13
1.5.3 可扩展性 14
1.5.4 性能 15
1.5.5 可用性 16
1.5.6 安全性 17
1.5.7 可部署性 18
1.6 本章小结 19
第2章 编写可修改可读的代码 20
2.1 什么是可修改性 20
2.2 与可修改性相关的几个方面 20
2.3 理解可读性 21
2.3.1 Python和可读性 21
2.3.2 可读性–反模式 22
2.4 增强可读性的各种技术 24
2.4.1 文档化代码 24
2.4.2 遵守编码和风格规范 30
2.4.3 审查和重构代码 31
2.4.4 注释代码 31
2.5 可修改性的基础——内聚和耦合 32
2.5.1 测量内聚性和耦合性 33
2.5.2 字符串和文本处理 35
2.6 探索提高可修改性的策略 37
2.6.1 提供显式接口 37
2.6.2 减少双向依赖 37
2.6.3 抽象出公共服务 38
2.6.4 使用继承技术 38
2.6.5 使用延迟绑定技术 42
2.7 度量——静态分析工具 43
2.7.1 什么是代码坏味道 43
2.7.2 圈复杂度——McCabe度量 44
2.7.3 度量结果测试 45
2.7.4 运行静态检查器 47
2.8 重构代码 53
2.8.1 降低复杂度 53
2.8.2 改善代码坏味道 55
2.8.3 改善风格上和编码上的问题 57
2.9 本章小结 57
第3章 可测试性——编写可测试的代码 58
3.1 理解可测试性 58
3.1.1 软件可测试性及相关属性 58
3.1.2 架构级的方方面面 59
3.1.3 策略 60
3.2 白盒测试原理 65
3.2.1 单元测试 65
3.2.2 操作中的单元测试 66
3.2.3 单元测试模块nose2 69
3.2.4 用py.test进行测试 70
3.2.5 代码覆盖 72
3.2.6 仿制一些东西 74
3.2.7 文档中的内联测试——doctest 78
3.2.8 集成测试 81
3.2.9 测试自动化 83
3.3 测试驱动开发 84
3.4 有回文的TDD 85
3.5 本章小结 90
第4章 好的性能就是回报 92
4.1 什么是性能 93
4.2 软件性能工程 93
4.3 性能测试和度量工具 94
4.4 性能复杂度 95
4.5 度量性能 96
4.5.1 使用上下文管理器度量时间 97
4.5.2 使用timeit模块来计时代码 99
4.5.3 使用timeit度量代码的性能 100
4.5.4 揭示时间复杂度——各种图 102
4.5.5 使用timeit度量CPU时间 106
4.6 剖析 107
4.6.1 确定性剖析 107
4.6.2 使用cProfile和profile进行剖析 108
4.6.3 收集和报告统计数据 111
4.6.4 第三方剖析器 113
4.7 其他工具 119
4.7.1 objgraph 120
4.7.2 pympler 121
4.8 程序设计性能——数据结构 123
4.8.1 可变容器——链表、字典和集合 123
4.8.2 不可变容器——元组 124
4.8.3 高性能容器——集合模块 125
4.8.4 概率数据结构——布隆过滤器 131
4.9 本章小结 134
第5章 开发可扩展的应用 136
5.1 可扩展性和性能 137
5.2 并发性 139
5.2.1 并发性与并行性 140
5.2.2 Python中的并发性——多线程机制 141
5.3 缩略图产生器 141
5.3.1 缩略图产生器——生产者/消费者架构 143
5.3.2 缩略图产生器——使用锁的资源约束 147
5.3.3 缩略图产生器——使用信号量的资源约束 150
5.3.4 资源约束——信号量和锁比较 153
5.3.5 缩略图产生器——使用条件的URL速率控制器 153
5.4 多线程机制——Python和GIL 160
5.4.1 Python中的并发性——多进程机制 160
5.4.2 质数检查器 161
5.4.3 排序磁盘文件 163
5.5 多线程与多进程比较 168
5.6 先入为主的与合作的多任务处理 170
5.7 Python中的asyncio模块 173
5.8 等待future对象——async和await 175
5.9 concurrent.future——高级并发处理 178
5.9.1 磁盘缩略图产生器 179
5.9.2 并发选项——如何选择？ 181
5.10 并行处理库 182
5.10.1 joblib 182
5.10.2 PyMP 183
5.10.3 fractals —— Mandelbrot集 184
5.11 Web扩展 189
5.11.1 扩展工作流——消息队列和任务队列 189
5.11.2 Celery —— 一种分布式任务队列 190
5.11.3 在Web上使用Python服务——WSGI 194
5.12 可扩展架构 197
5.12.1 垂直可扩展架构 197
5.12.2 水平扩展架构 198
5.13 本章小结 201
第6章 安全性——编写安全代码 202
6.1 信息安全架构 202
6.2 安全编码 203
· · · · · · (收起)
读后感
用户评价
不得不说，《软件架构》这本书的视野之开阔，是我读过的技术类书籍中罕见的。作者并没有将自己局限于某一种特定的技术栈或领域，而是从更宏观的层面，对软件系统的本质进行了深入的探讨。他对“系统演化”的论述，让我看到了软件从诞生到成熟，再到被淘汰的整个生命周期，以及在这个过程中，架构所扮演的关键角色。尤其让我印象深刻的是，作者在分析某些经典架构模式时，不仅仅是介绍了其“是什么”，更深入地挖掘了它们“为什么会被创造出来”，以及在当时的历史背景下，它们是如何解决当时所面临的问题的。这种“追根溯源”的分析方式，让我对这些模式有了更深刻的理解，也更容易将其迁移到新的场景中。书中对“技术债务”的讨论，也让我警醒。我过去常常为了快速交付而牺牲一些“长期”的考虑，留下了不少“技术债”。作者用生动的语言和翔实的案例，阐述了技术债务积累的危害，以及如何通过合理的架构设计来规避和偿还技术债。这本书让我意识到，一个真正优秀的软件架构，不仅仅要满足当前的需求，更要为未来的发展奠定坚实的基础。它让我从一个“战术型”的开发者，逐渐向一个“战略型”的架构思考者转变。
《软件架构》这本书，给我带来的最大收获，是对“权衡”的深刻理解。作者以一种极其精炼和深刻的笔触，剖析了软件架构设计中无处不在的权衡。书中对“速度与质量”、“灵活性与简单性”、“成本与性能”等经典权衡的讨论，让我对许多曾经困扰我的问题有了清晰的答案。我曾经为了追求系统的“完美”而陷入过度设计的泥潭，也曾经为了追求“快速交付”而牺牲了系统的可维护性。作者用大量的案例和深入的分析，为我展示了如何在不同的场景下进行合理的权衡，以及如何找到那个“最佳的平衡点”。我尤其欣赏作者在分析“遗留系统”的改造时，所展现出的 pragmatism。他并没有简单地提出“推倒重来”的解决方案，而是为读者提供了多种切实可行的改造策略，帮助我们在复杂的现实环境中找到最有效的路径。这本书让我明白，软件架构的设计，是一门艺术，更是一门科学，它需要在理性分析和经验判断之间找到最佳的结合点。
这是一本让我“相见恨晚”的书。作者的写作风格非常独特，他能够将非常复杂的技术概念，用一种极其通俗易懂、甚至带点哲学思辨的方式娓娓道来。阅读这本书，我感觉就像是在与一位经验丰富的智者进行对话，他引导我一步步地探索软件架构的奥秘。书中对“选择”的反复强调，让我印象深刻。作者指出，在软件架构设计中，每一次选择都意味着放弃其他可能性，而这些选择的质量，直接决定了系统的未来。他通过大量的对比分析，展示了不同选择所带来的不同后果，让我对“权衡”有了更深刻的理解。我尤其欣赏作者在讨论“分布式系统”和“微服务架构”时，所展现出的前瞻性和批判性。他并没有盲目地追捧这些新兴的架构风格，而是对其潜在的挑战和复杂性进行了坦诚的剖析，并为读者提供了应对这些挑战的实用建议。这让我意识到，学习架构不仅仅是学习“模式”，更是学习“思考”和“判断”。这本书不仅仅提升了我的技术能力，更重要的是，它重塑了我对软件工程的认知，让我明白了架构设计是一门需要持续学习和实践的艺术。
《软件架构》这本书，在我阅读过的众多技术书籍中，无疑是独树一帜的存在。作者的洞察力让我惊叹，他能够触及到软件设计中最核心、最根本的问题。书中对于“一致性”和“异质性”的讨论，让我对如何构建一个既能保持整体协调，又能允许局部差异的复杂系统有了更深入的理解。我曾经在项目中遇到过这样的难题：如何在满足多样化的业务需求的同时，保持系统的整体性和可维护性？作者提出的多种解决方案，如通过定义清晰的接口和契约来管理异质性，以及利用领域驱动设计来统一业务语言，都为我提供了宝贵的启示。此外，书中对“技术选型”的分析，也让我受益匪浅。作者并没有简单地给出“应该选择什么”，而是引导读者去分析“为什么选择”，以及不同的技术选型所带来的“长期影响”。这种“思考驱动”的学习方式，让我能够更理性地评估新技术，避免盲目跟风。这本书不仅仅是技术知识的传递，更是一种思维方式的启迪，它让我明白，优秀的软件架构，是技术、业务和人共同作用的结果。
阅读《软件架构》的过程，就像是在进行一次深入的“思想体检”。作者以一种极其敏锐的洞察力，揭示了许多我长期以来在软件开发中习以为常，但却可能隐藏着隐患的“潜规则”。书中对于“抽象层级”的探讨，让我对“解耦”和“封装”有了全新的认识。我之前一直认为，越多的抽象层级越好，可以提供更大的灵活性。但作者通过精辟的论述和鲜活的案例，让我看到了“过度抽象”可能带来的复杂性和维护成本的增加。这就像是给我的思维打了一剂“清醒剂”，让我开始审视自己过去的设计中是否存在这种“过度设计”的倾向。此外，书中对“状态管理”和“数据流动”的讨论，也让我茅塞顿开。我以前常常在不同的模块之间传递大量的数据，却很少思考这些数据的生命周期和状态变化带来的潜在风险。作者提出的各种解决方案，如事件驱动、消息队列等，都为我提供了新的思路，让我能够更好地设计出清晰、易于理解和维护的数据处理流程。让我尤为赞赏的是，作者在书中并没有回避那些“灰色地带”和“模糊边界”。他坦诚地承认，在软件架构设计中，很多时候都没有绝对的“正确”答案，只有“最适合”的解决方案。这种坦诚的态度，反而让我感到更加亲切和信服。这本书让我看到了软件架构的“艺术”一面，它不仅仅是技术堆砌，更是智慧和经验的结晶。
这本《软件架构》彻底改变了我对软件开发的认知。作者以一种极具启发性的方式，引导我深入思考软件系统之所以能够稳定运行、持续演进的根本原因。书中对“模式复用”和“反模式”的剖析，让我对“ DRY (Don't Repeat Yourself)”原则有了更深的理解。我过去常常在项目中重复地编写相似的代码，却很少意识到这会带来的维护成本和潜在的错误。作者通过对各种模式的应用和对反模式的警示，为我指明了如何构建更加优雅和可维护的代码。我尤其喜欢作者在探讨“可测试性”和“可观测性”时所表现出的前瞻性。他强调了这些非功能性需求对于软件质量的重要性，并提供了多种在架构设计阶段就考虑这些需求的具体方法。这让我意识到，构建一个高质量的软件系统，需要的是一种“全局观”和“前瞻性”的思考。这本书不仅提升了我的技术能力，更重要的是，它重塑了我对软件工程的价值观，让我明白了“工程”的本质在于“创造价值”和“持续改进”。
这本《软件架构》给我带来的震撼，远超乎我最初的预期。它并非是一本“食谱”式的技术手册，告诉你“如何做”，而是更像一本“哲学书”，引导你思考“为什么”。作者在开篇就抛出了一个核心问题：什么是真正意义上的“好”架构？这个问题看似简单，却触及了软件设计最本质的层面。书中对各种架构风格的解读，与其说是对模式的罗列，不如说是对不同设计思想的深入剖析。我尤其喜欢作者在探讨某些“争议性”架构模式时所表现出的审慎和辩证。他不会轻易地否定或推崇任何一种模式，而是引导读者去理解其背后的权衡与取舍，以及在不同约束条件下的适用性。这种“不带偏见”的分析方式，让我得以跳出固有的思维模式，更客观地评估和选择适合自己项目的解决方案。书中对“可维护性”、“可扩展性”、“可靠性”等非功能性需求的阐述，也让我醍醐灌顶。这些看似“软性”的指标，在实际的项目推进中往往被忽视，但作者却将其提升到了与功能性需求同等重要的位置，并深入分析了它们是如何通过架构设计来保障的。我甚至开始反思，自己过往在项目中，是不是过于关注“功能实现”，而忽略了这些决定项目生死存亡的“隐形”要素。这本书不仅仅提升了我的技术认知，更重要的是，它塑造了我对软件工程的价值观，让我明白了构建一个可持续、有生命力的软件系统，需要的是一种更加全面、更加审慎的思考方式。
这是一本让我“大开眼界”的书。作者以一种极其宏观的视角，为我们展现了软件架构的广阔天地。他不仅仅关注具体的代码实现，更是将软件系统置于更广阔的商业和社会背景下进行审视。书中对“企业架构”和“业务架构”的探讨，让我明白了软件架构与业务战略之间的紧密联系。我之前一直认为，架构设计是纯粹的技术问题，但这本书让我看到了，一个成功的软件架构，必须是能够支撑和驱动业务发展的。作者在分析不同架构模式时，往往会结合其在实际业务场景中的应用案例，让我能够更直观地理解这些模式的价值。我尤其喜欢作者在探讨“架构演进”时所表现出的远见卓识。他指出，软件架构并非一成不变，而是一个不断演化的过程，需要随着业务的发展和技术进步而不断调整和优化。这让我意识到，架构设计并非一劳永逸，而是一个持续的、动态的过程。这本书不仅提升了我的技术视野，更重要的是，它让我看到了软件架构在更广阔的商业世界中所扮演的关键角色。
《软件架构》这本书，给我的感觉就像是在探索一座巨大的、精密的机械迷宫。作者以其严谨的逻辑和生动的语言，为我揭示了软件系统内部错综复杂的运行机制。书中对“消息传递”和“事件驱动”的讨论，让我对如何构建松耦合、高内聚的系统有了全新的认识。我之前在项目中，往往倾向于采用直接的函数调用来处理模块间的通信，却很少考虑到这种方式带来的紧耦合和潜在的依赖问题。作者提出的各种异步通信机制，如消息队列、发布/订阅模式等，都为我提供了新的思路，让我能够更好地设计出更加灵活和可扩展的系统。我尤其欣赏作者在分析“状态共享”和“数据一致性”时所展现出的深度。他不仅指出了这些问题所带来的挑战，更提供了多种解决这些挑战的有效策略，如分布式事务、最终一致性等。这让我意识到，构建一个健壮的分布式系统，需要的是对复杂性的高度掌控能力。这本书不仅提升了我的技术深度，更重要的是，它让我看到了软件架构的“精巧”与“智慧”，以及它们如何在复杂的世界中发挥作用。
一本引人入胜的书，读起来就像是在进行一场思维的探险。作者以其精妙的笔触，勾勒出了一个宏大的软件世界，从最基础的构件搭建，到复杂系统的精妙协同，无不展现出其深厚的功力。书中对于不同架构模式的剖析，不仅仅是理论上的阐述，更是通过生动形象的案例，将抽象的概念具象化，让读者能够清晰地感受到每一种模式的优势与劣势，以及它们在不同场景下的适用性。尤其让我印象深刻的是，作者并没有将这些模式视为孤立的知识点，而是强调了它们之间的联系与演变，仿佛在讲述一个软件架构的进化史，让我们得以窥见技术发展的脉络。阅读过程中，我时常会停下来，反复咀嚼其中的观点，试图将其与我过往的开发经历联系起来，从中找到共鸣，也发现自己曾经的不足。这本书不仅仅是一本技术指南，更是一本启迪思维的哲学著作，它教会我用更宏观、更长远的视角去审视软件的生命周期，去思考如何构建一个既能满足当前需求，又能适应未来变化的 robust and scalable 的系统。作者的语言风格也十分吸引人，既有严谨的学术态度，又不失风趣幽默的表达，使得原本可能枯燥的技术内容变得生动有趣，让人爱不释卷。这本书无疑是我在软件工程领域的一次重要学习经历，它拓宽了我的视野，深化了我的理解，也激发了我不断探索和学习的热情。
很一般，还是读流畅的Python吧 20190505【在读20181220
第五章 第八章还可以，带实例讲解分析，关于安全性，模版%s被hack利用，也有点意思，其他都是总结比较浅
直接看3578章就行，几乎都是调试的东西，给小白看，他看不懂，可是又浅尝辄止，啥都不深入。
了解一下python 工具箱里有哪些东西
了解一下python 工具箱里有哪些东西
