具体描述
《反模式危机中软件架构和项目的重构》从一个新的角度审视模式，提出了反模式的概念，介绍了在软件开发中常常出现的问题。将设计模式错误应用于不适当的上下文环境。首先，定义了软件开发参考模型和文档模板来说明这些反模式。然后，从开发人员角度、架构角度和管理角度三个方面对这些反模式逐一说明，并说明了与特定反模式相关的背景、原因、症状和后果，让读者可以迅速地检验身边的项目是否出现了这些状况，同时也针对每个反模式给出了相应的解决方案。
作者简介
目录信息
第1章 模式与反模式简介 3
1.1 反模式就是揭露假象 3
1.2 反模式的概念 6
1.3 反模式的由来 7
1.4 本书组织结构 10
第2章 反模式参考模型 11
2.1 视角 13
2.2 根源 14
2.2.1 匆忙 14
2.2.2 漠然 15
2.2.3 思想狭隘 16
2.2.4 懒惰 16
2.2.5 贪婪 17
2.2.6 无知 18
2.2.7 自负 18
2.3 原力 19
2.4 软件设计层次模型 25
2.4.1 对象层 28
2.4.2 微架构层 28
2.4.3 框架层 28
2.4.4 应用层 29
2.4.5 系统层 29
2.4.6 企业层 31
2.4.7 全球层 32
2.4.8 设计层次小结 32
2.5 架构规模和原力 33
第3章 模式和反模式的模板 35
3.1 退化形式 35
3.2 Alexander形式 36
3.3 *小化模板(微型模式) 36
3.4 小型模式模板 36
3.4.1 归纳式小型模式 37
3.4.2 演绎式小型模式 37
3.5 正式模板 37
3.5.1 GoF模板 37
3.5.2 模式系统模板 38
3.6 对设计模式模板的反思 38
3.7 反模式模板 39
3.7.1 伪反模式模板 40
3.7.2 小型反模式 40
3.8 完整的反模式模板 40
第4章 对使用反模式的建议 43
4.1 机能不良环境 43
4.2 反模式与变化 44
4.3 编写新反模式 45
4.4 小结 46
第二部分 反模式
第5章 软件开发性反模式 49
5.1 软件重构 49
5.2 开发性反模式摘要 50
5.3 The Blob(胖球) 52
5.3.1 背景 52
5.3.2 一般形式 53
5.3.3 症状和后果 54
5.3.4 典型原因 54
5.3.5 已知例外 55
5.3.6 重构方案 55
5.3.7 变化 58
5.3.8 对其他视角和规模的适用性 59
5.3.9 示例 59
5.4 Lava Flow(岩浆流) 62
5.4.1 背景 62
5.4.2 一般形式 63
5.4.3 症状和后果 65
5.4.4 典型原因 65
5.4.5 已知例外 66
5.4.6 重构方案 66
5.4.7 示例 66
5.4.8 相关解决方案 67
5.4.9 对其他视角和规模的适用性 67
5.5 Functional Decomposition(功能分解) 69
5.5.1 背景 69
5.5.2 一般形式 69
5.5.3 症状和后果 69
5.5.4 典型原因 70
5.5.5 已知例外 70
5.5.6 重构方案 70
5.5.7 示例 71
5.5.8 相关解决方案 72
5.5.9 对其他视角和规模的适用性 72
5.6 Poltergeist(恶作剧鬼) 73
5.6.1 背景 73
5.6.2 一般形式 73
5.6.3 症状和后果 74
5.6.4 典型原因 75
5.6.5 已知例外 75
5.6.6 重构方案 75
5.6.7 示例 75
5.6.8 相关解决方案 76
5.6.9 对其他视角和规模的适用性 76
5.7 Golden Hammer(金锤) 78
5.7.1 背景 78
5.7.2 一般形式 79
5.7.3 症状和后果 79
5.7.4 典型原因 79
5.7.5 已知例外 79
5.7.6 重构方案 80
5.7.7 变化 81
5.7.8 示例 81
5.7.9 相关方案 81
5.8 Spaghetti Code(面条代码) 83
5.8.1 背景 83
5.8.2 一般形式 83
5.8.3 症状和后果 83
5.8.4 典型原因 84
5.8.5 已知例外 84
5.8.6 重构方案 84
5.8.7 示例 86
5.8.8 相关解决方案 89
5.9 Cut-And-Paste Programming(剪贴编程) 92
5.9.1 背景 92
5.9.2 一般形式 92
5.9.3 症状和后果 92
5.9.4 典型原因 93
5.9.5 已知例外 93
5.9.6 重构方案 93
5.9.7 示例 94
5.9.8 相关解决方案 95
第6章 软件架构性反模式 97
6.1 架构性反模式摘要 98
6.2 Stovepipe Enterprise(烟囱企业) 100
6.2.1 背景 100
6.2.2 一般形式 100
6.2.3 症状和后果 101
6.2.4 典型原因 101
6.2.5 已知例外 101
6.2.6 重构方案 102
6.2.7 示例 105
6.2.8 相关解决方案 106
6.2.9 对其他视角和规模的适用性 107
6.3 Stovepipe System(烟囱系统) 108
6.3.1 背景 108
6.3.2 一般形式 108
6.3.3 症状和后果 109
6.3.4 典型原因 109
6.3.5 已知例外 109
6.3.6 重构方案 109
6.3.7 示例 110
6.3.8 相关解决方案 112
6.3.9 对其他视角和规模的适用性 112
6.4 Vendor Lock-In(供应商锁定) 113
6.4.1 背景 113
6.4.2 一般形式 114
6.4.3 症状和后果 114
6.4.4 典型原因 114
6.4.5 已知例外 115
6.4.6 重构方案 115
6.4.7 变化 116
6.4.8 示例 117
6.4.9 相关解决方案 117
6.4.10 对其他视角和规模的适用性 117
6.5 Architecture By Implication(实现主导架构) 120
6.5.1 背景 120
6.5.2 一般形式 120
6.5.3 症状和后果 121
6.5.4 典型原因 121
6.5.5 已知例外 121
6.5.6 重构方案 122
6.5.7 变化 123
6.5.8 示例 123
6.5.9 相关解决方案 124
6.5.10 对其他视角和规模的适用性 124
6.6 Design By Committee(委员会设计) 126
6.6.1 背景 126
6.6.2 一般形式 126
6.6.3 症状和后果 126
6.6.4 典型原因 127
6.6.5 已知例外 127
6.6.6 重构方案 127
6.6.7 变化 129
6.6.8 示例 129
6.6.9 相关解决方案、模式和反模式 131
6.6.10 对其他视角和规模的适用性 132
6.7 Reinvent The Wheel(重新发明轮子) 134
6.7.1 背景 134
6.7.2 一般形式 134
6.7.3 症状和后果 135
6.7.4 典型原因 135
6.7.5 已知例外 135
6.7.6 重构方案 135
6.7.7 变化 136
6.7.8 示例 137
6.7.9 相关解决方案 139
6.7.10 对其他视角和规模的适用性 139
第7章 软件项目管理性反模式 141
7.1 管理角色的转变 141
7.2 管理性反模式摘要 142
7.3 Analysis Paralysis(分析瘫痪) 145
7.3.1 背景 145
7.3.2 一般形式 145
7.3.3 症状和后果 146
7.3.4 典型原因 146
7.3.5 已知例外 147
7.3.6 重构方案 147
7.4 Death By Planning(规划致死) 149
7.4.1 背景 149
7.4.2 一般形式 149
7.4.3 症状和后果 151
7.4.4 典型原因 152
7.4.5 已知例外 152
7.4.6 重构方案 152
7.4.7 变化 154
7.4.8 示例 156
7.4.9 相关解决方案 157
7.4.10 对其他视角和规模的适用性 158
7.5 Corncob(玉米棒子) 159
7.5.1 背景 159
7.5.2 一般形式 159
7.5.3 症状和后果 159
7.5.4 典型原因 160
7.5.5 已知例外 160
7.5.6 重构方案 160
7.5.7 变化 161
7.5.8 示例 163
7.5.9 相关解决方案 163
7.5.10 对其他视角和规模的适用性 163
7.6 Irrational Management(非理性管理) 165
7.6.1 背景 165
7.6.2 一般形式 165
7.6.3 症状和后果 166
7.6.4 典型原因 166
7.6.5 已知例外 166
7.6.6 重构方案 166
7.6.7 变化 169
7.6.8 示例 169
7.7 Project Mismanagement(项目管理不善) 172
7.7.1 背景 172
7.7.2 一般形式 172
7.7.3 症状和后果 173
7.7.4 典型原因 173
7.7.5 已知例外 173
7.7.6 重构方案 173
7.7.7 变化 174
7.7.8 示例 175
7.7.9 相关解决方案 176
第三部分 结论和资源
附录A 反模式大纲 181
附录B 反模式术语表 187
附录C 缩略语 191
附录D 参考文献 193
索引 199
· · · · · · (收起)
读后感
无论是普通开发人员，还是各级技术管理人员，都值得一读，并以此总结反省自己。 唯一的缺点是那些模式的名字取得太晦涩。
评分无论是普通开发人员，还是各级技术管理人员，都值得一读，并以此总结反省自己。 唯一的缺点是那些模式的名字取得太晦涩。
评分《反模式》这本书终于出版了 1995年，GoF（以Erich Gamma为首的“四人帮”）所著的《设计模式——可复用面向对象软件的基础》（Design Patterns--Elements of Reusable Object Oriented Software）一书出版了。这本书在面向对象编程/设计领域具有划时代的意义。不夸张地说，...
评分书确实是好书，能开阔眼界。翻译的也还不错，不过由于高级技术人员和普通程序员关注的焦点和领域不同，导致书中谈到的东西和某些术语显得有些陌生，可能这也是一部分读者抱怨翻译的不够好的原因吧。 书买了一段时间了，一直没有看，其实我挺喜欢这种200多页的书的，可以速度读...
评分怎么说呢？书绝对是好书，可惜的是这真的不适合当作自学或教科书，无愧于它的生产效能大奖阿。 如果你没有项目的经验，那么这本书真的不适合你，不要再浪费时间了。每一个反模式，作者都写的简短而有力，如果你有过实际的经验，我相信你读过之后都会有一拍脑袋，醍醐灌顶，恍...
用户评价
本来是满心期待的。这本书也快绝版了，在亚马逊第三方“高价”买的。很失望。一个是空，第一部分典型的中国教科书风格。一个是老，软件开发性反模式很大部分聚焦于非面向对象程序员使用面向对象技术产生的问题。还有就是阅读体验非常差，这部分归咎于翻译的原因。比如可以把Architecture By Implication翻译成“实现主导架构”。最大的价值在于提出了这些模式术语，仅此而已。
评分排除能力问题，反模式有如下原因： 1、由于开发人员追求短期进度，降低了软件的可修改性。 2、开发人员忽略了软件的非功能性需求，导致产品质量低下。 3、利益相关者之间失败的沟通和协作，使得管理过程滞后于开发过程。
评分给我一个感觉,对于我们这种没有实际生产经验的人,真的是没什么大的作用,留着以后看
评分少了点儿，开头废话多，细节少
评分印象比较深刻的反模式： 手把手教你如何制造一颗原子弹（从头做起只需7天【重新发明车轮模式】）； 一个超级大类（混球模式）； 这些10年都没动过的代码天知道会有什么表现，保留吧（岩浆流模式）； 我们有一个计划，这个计划能拯救我们（一切都会按计划模式）； ……
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有