作者:
[美] 格雷戈尔·霍培 (Gregor Hohpe)
出版社: 人民邮电出版社
原作名: 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey,1E
译者: 许顺强
出版年: 2020-5-1
页数: 180
定价: 69
装帧: 平装
丛书: 图灵程序设计丛书·程序员修炼系列
ISBN: 9787115534651
出版社: 人民邮电出版社
原作名: 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey,1E
译者: 许顺强
出版年: 2020-5-1
页数: 180
定价: 69
装帧: 平装
丛书: 图灵程序设计丛书·程序员修炼系列
ISBN: 9787115534651
内容简介 · · · · · ·
本书汇集了一名架构师20多年来在全球各大企业任职的经验,共分为5个部分,分别对应在帮助大型企业进行IT转型的过程中,首席架构师必须高效处理的5个方面:企业或IT架构师的角色和能力、架构工作在大型企业中的价值、与各种干系人的沟通、对组织结构和系统的理解、对传统组织进行转型。本书科学而系统地归纳出软件架构师应该具备的完整能力模型,不仅帮助软件开发人员系统地学习如何掌握这37项技能,而且还能让他们进一步理解软件架构师的角色和本质,使他们最终突破技术“天花板”,成为一名合格的软件架构师。
作者简介 · · · · · ·
格雷戈尔·霍培 (Gregor Hohpe)
ArchitectElevator CXO云转型顾问,并为新加坡政府科技局提供技术决策咨询。曾任谷歌(新加坡)技术总监兼CTO、谷歌(日本)高级软件工程师、Allianz公司首席架构师、ThoughtWorks集成架构师。在IT领域有20多年的经验积累,拥有3项美国专利。与人合著《企业集成模式》一书。
【译者简介】
许顺强
资深软件系统架构师、产品负责人。擅长设备协同互联、物联网和云平台等技术领域,精通敏捷软件开发流程,有十多年的跨国项目经验,拥有1项美国专利和4项中国专利。喜欢编写易懂易测、高效优美的软件代码。译有《C#敏捷开发实践》等书。
目录 · · · · · ·
IT 的50 种形态 1
第1章 架构师 6
1.1 架构师电梯 9
1.1.1 缺失的一环 9
1.1.2 架构师电梯 9
1.1.3 有些组织的层级比其他组织要多 10
· · · · · · (更多)
第1章 架构师 6
1.1 架构师电梯 9
1.1.1 缺失的一环 9
1.1.2 架构师电梯 9
1.1.3 有些组织的层级比其他组织要多 10
· · · · · · (更多)
IT 的50 种形态 1
第1章 架构师 6
1.1 架构师电梯 9
1.1.1 缺失的一环 9
1.1.2 架构师电梯 9
1.1.3 有些组织的层级比其他组织要多 10
1.1.4 不是单行道 10
1.1.5 高速电梯 11
1.1.6 其他乘客 11
1.1.7 搭乘电梯的危险 12
1.1.8 将大楼扁平化 13
1.2 电影明星架构师 14
1.2.1 黑客帝国——规划大师 14
1.2.2 剪刀手爱德华——园丁 15
1.2.3 粉身碎骨——导游 15
1.2.4 绿野仙踪——魔法师 16
1.2.5 超级英雄还是强力胶 17
1.2.6 做决定 17
1.3 企业架构师与企业里的架构师 18
1.3.1 企业架构 19
1.3.2 业务和IT 是平等的 19
1.3.3 企业里的架构师 20
1.3.4 哪些楼层 20
1.4 架构师用三条腿立足 22
1.4.1 技能、影响力、领导力 22
1.4.2 良性循环 23
1.4.3 重复良性循环 24
1.4.4 要当一辈子架构师吗 25
1.5 决策 26
1.5.1 我们真的那么容易上当吗 27
1.5.2 小数法则 27
1.5.3 偏见 28
1.5.4 启动效应 28
1.5.5 决策分析 29
1.5.6 微亡率 29
1.5.7 模型思维 30
1.5.8 避免决策 31
1.6 刨根问底 32
1.6.1 五问法 32
1.6.2 反复追问才可以揭示出决策和假设 33
1.6.3 处理所有问题的研讨会 33
1.6.4 不存在自由通过 34
第2章 架构 35
2.1 咖啡店不使用两段式提交法 38
2.1.1 请给我一杯热拿铁 38
2.1.2 关联 39
2.1.3 异常处理 39
2.1.4 事务 40
2.1.5 反向压力 41
2.1.6 会话 41
2.1.7 规范化数据模型 41
2.1.8 欢迎来到现实世界 41
2.2 这是架构吗 42
2.2.1 定义软件架构 42
2.2.2 (建筑)架构决策 43
2.2.3 关键决策无须复杂 45
2.2.4 符合目标 45
2.2.5 通过测试 45
2.3 每个系统都是完美的 46
2.3.1 加热器系统 46
2.3.2 反馈回路 47
2.3.3 有组织的复杂性 47
2.3.4 系统效应 48
2.3.5 理解系统行为 48
2.3.6 影响系统行为 49
2.3.7 系统抗拒改变 50
2.3.8 组织和技术系统 50
2.4 别有代码恐惧症 51
2.4.1 代码恐惧症 51
2.4.2 好的初衷 52
2.4.3 抽象层次 52
2.4.4 简单化与灵活性 52
2.4.5 抽象打包 52
2.4.6 配置 53
2.4.7 代码还是数据 53
2.4.8 运行时与设计时 54
2.4.9 工具化 54
2.4.10 配置化编程 55
2.4.11 配置还有用武之地吗 55
2.5 如果从不杀死任何系统,你就会被“僵尸”包围 56
2.5.1 遗留系统 56
2.5.2 变更恐惧症 57
2.5.3 版本升级 57
2.5.4 运行与变更 58
2.5.5 按计划报废 58
2.5.6 如果疼,就多做几次 59
2.5.7 拥抱变更的文化 59
2.6 平面的IT世界 60
2.6.1 失真的供应商地图 61
2.6.2 在你的地图上标绘产品 61
2.6.3 绘制版图 62
2.6.4 产品理念 63
2.6.5 制图标准 63
2.6.6 版图迁移 64
2.7 永远不要派人去干机器的活 65
2.7.1 让一切自动化 65
2.7.2 这不只和效率相关 65
2.7.3 可重复性能够提振信心 66
2.7.4 自助服务 66
2.7.5 超越自助服务 67
2.7.6 自动化不是单行道 67
2.7.7 显性知识才是好知识 68
2.7.8 人的用武之地 68
2.8 如果软件吞没了整个世界,最好使用版本控制 69
2.8.1 SDX——软件定义一切 69
2.8.2 纺纱工的暴动 70
2.8.3 像软件工程师一样思考 71
2.8.4 使用构建管道 71
2.8.5 质量检验自动化 72
2.8.6 合适的语言 72
2.8.7 软件吞没世界,一次一个修订 73
第3章 沟通 74
3.1 诠释技术主题 77
3.1.1 给高管们的高性能计算架构 77
3.1.2 搭建斜坡,而不是峭壁 77
3.1.3 留意间隙 78
3.1.4 首先,创造一种语言 79
3.1.5 一致的细节层次 79
3.1.6 我本来想要的,但又不敢 80
3.2 写给大忙人 81
3.2.1 写作可以延伸到更多受众 81
3.2.2 质量与影响 82
3.2.3 “在手中”——第一印象很重要 82
3.2.4 好文章就像电影《怪物史莱克》 83
3.2.5 让读者轻松些 83
3.2.6 写作曲线——线性化 84
3.2.7 简洁明了 85
3.2.8 作家研讨会 86
3.2.9 笔杆子比枪杆子更强大,但仍敌不过企业政治 86
3.3 重点突出胜过面面俱到 87
3.3.1 3 秒测试 87
3.3.2 声明 88
3.3.3 突击测验 88
3.3.4 言简意赅 89
3.3.5 技术备忘录 89
3.4 给孩子们看看海盗船 90
3.4.1 获取关注 90
3.4.2 兴奋 91
3.4.3 聚焦目标 91
3.4.4 展示环境 92
3.4.5 里面的内容 92
3.4.6 考虑受众的身份 92
3.4.7 寓“作”于乐 92
3.5 给银行劫匪画像 94
3.5.1 每个人都看到罪犯 94
3.5.2 刑侦肖像专家 95
3.5.3 系统隐喻 95
3.5.4 视点 96
3.5.5 可视化 96
3.5.6 架构疗法 97
3.5.7 错了!重新做 97
3.6 图驱动设计 98
3.6.1 演示技巧——图 98
3.6.2 绘图技能 99
3.6.3 作为设计技术的绘图 100
3.6.4 没有银弹(点) 101
3.7 绘制连线 102
3.7.1 注意连线 102
3.7.2 元模型 103
3.7.3 语义学的语义 104
3.7.4 元素-关系-行为 104
3.7.5 架构图 105
3.7.6 UML 105
3.7.7 警惕过度应用 106
3.7.8 元素风格 106
第4章 组织 107
4.1 控制只是假象 110
4.1.1 假象 110
4.1.2 控制回路 111
4.1.3 智能控制 111
4.1.4 双行道 111
4.1.5 反馈中的问题 112
4.1.6 普鲁士人并不笨 112
4.1.7 实际控制 113
4.1.8 预警系统 113
4.2 他们不再那样构建了 115
4.2.1 为什么IT 架构师钟爱金字塔 115
4.2.2 组织金字塔 115
4.2.3 没有法老,就没有金字塔 116
4.2.4 建造金字塔 116
4.2.5 生活在金字塔里 117
4.2.6 总能变得更糟 118
4.2.7 构建现代结构 118
4.3 黑市并不有效 119
4.3.1 靠黑市来拯救 119
4.3.2 黑市很少有效 120
4.3.3 你不能把黑市外包出去 120
4.3.4 打击黑市 121
4.3.5 反馈和透明度 121
4.4 扩展组织 123
4.4.1 组件设计——个人生产力 123
4.4.2 避免同步点——会议无法扩展 124
4.4.3 中断打断——电话 124
4.4.4 堆积而不是退避 125
4.4.5 异步通信——电子邮件、聊天,等等 125
4.4.6 提问无法扩展——构建缓存 126
4.4.7 设置不当的域边界——过度对齐 127
4.4.8 自助服务是更好的服务 127
4.4.9 保持人性 128
4.5 缓慢的混乱并不是有序 129
4.5.1 快速与敏捷 130
4.5.2 速度和纪律 130
4.5.3 又快又好 130
4.5.4 缓慢的混乱 131
4.5.5 靠ITIL 来救援吗 132
4.5.6 目标和纪律 32
4.5.7 解决办法 133
4.6 通过盗梦治理 134
4.6.1 制定标准 135
4.6.2 通过行政命令治理 135
4.6.3 通过基础设施治理 136
4.6.4 盗梦 137
4.6.5 皇帝的新衣 137
4.6.6 按照需求治理 138
第5章 转型 139
5.1 没有痛苦,就没有改变 141
5.1.1 转型的各个阶段 141
5.1.2 数字化转型的各个阶段 142
5.1.3 一厢情愿地兜售“万灵油” 142
5.1.4 发动机调优 143
5.1.5 沿途求救 143
5.1.6 不变革的痛苦 144
5.1.7 摆脱困境 144
5.2 引导变革 145
5.2.1 拖拉机超过了赛车 145
5.2.2 设定航向 146
5.2.3 去大陆外冒险 146
5.2.4 破釜沉舟 146
5.2.5 理智之岛 147
5.2.6 臭鼬工程 147
5.2.7 局部最优 148
5.2.8 盲人乡 148
5.3 速度经济 149
5.3.1 旧的规模经济 150
5.3.2 关注流程 151
5.3.3 延迟成本 151
5.3.4 可预测性的价值和成本 152
5.3.5 避免重复的价值和成本 152
5.3.6 如何转变思维模式 153
5.4 无限循环 154
5.4.1 构建-衡量-学习循环 154
5.4.2 数字化转速 155
5.4.3 传统组织的阻碍 55
5.4.4 在外部循环 156
5.4.5 加速反馈 156
5.4.6 保持凝聚力 156
5.5 你不能假装已经数字化 158
5.5.1 奠定基础 158
5.5.2 反馈循环 159
5.5.3 按承诺交付 159
5.5.4 以客户为中心 159
5.5.5 共同打造IT 服务 159
5.5.6 吃自家狗粮 160
5.5.7 数字化思维 160
5.5.8 栈谬论 161
5.6 金钱买不到爱情 163
5.6.1 创新者的窘境 163
5.6.2 留意最高薪人士的意见 164
5.6.3 开销和被容忍的低效率 164
5.6.4 外部依赖 164
5.6.5 付出得越多,可能收获越少 165
5.6.6 文化变革要由内而发 166
5.7 有谁喜欢排队吗 167
5.7.1 留意活动间隙 167
5.7.2 一些排队论知识 168
5.7.3 查找队列 168
5.7.4 插队 169
5.7.5 让队列可见 169
5.8 在四个维度上思考 171
5.8.1 在一条线上生活 171
5.8.2 质量与速度 171
5.8.3 更高的自由度 172
5.8.4 改变曲线的形状 173
5.8.5 反转曲线 173
5.8.6 质量是什么 174
5.8.7 少了一个维度 174
第6章 架构IT转型 175
· · · · · · (收起)
第1章 架构师 6
1.1 架构师电梯 9
1.1.1 缺失的一环 9
1.1.2 架构师电梯 9
1.1.3 有些组织的层级比其他组织要多 10
1.1.4 不是单行道 10
1.1.5 高速电梯 11
1.1.6 其他乘客 11
1.1.7 搭乘电梯的危险 12
1.1.8 将大楼扁平化 13
1.2 电影明星架构师 14
1.2.1 黑客帝国——规划大师 14
1.2.2 剪刀手爱德华——园丁 15
1.2.3 粉身碎骨——导游 15
1.2.4 绿野仙踪——魔法师 16
1.2.5 超级英雄还是强力胶 17
1.2.6 做决定 17
1.3 企业架构师与企业里的架构师 18
1.3.1 企业架构 19
1.3.2 业务和IT 是平等的 19
1.3.3 企业里的架构师 20
1.3.4 哪些楼层 20
1.4 架构师用三条腿立足 22
1.4.1 技能、影响力、领导力 22
1.4.2 良性循环 23
1.4.3 重复良性循环 24
1.4.4 要当一辈子架构师吗 25
1.5 决策 26
1.5.1 我们真的那么容易上当吗 27
1.5.2 小数法则 27
1.5.3 偏见 28
1.5.4 启动效应 28
1.5.5 决策分析 29
1.5.6 微亡率 29
1.5.7 模型思维 30
1.5.8 避免决策 31
1.6 刨根问底 32
1.6.1 五问法 32
1.6.2 反复追问才可以揭示出决策和假设 33
1.6.3 处理所有问题的研讨会 33
1.6.4 不存在自由通过 34
第2章 架构 35
2.1 咖啡店不使用两段式提交法 38
2.1.1 请给我一杯热拿铁 38
2.1.2 关联 39
2.1.3 异常处理 39
2.1.4 事务 40
2.1.5 反向压力 41
2.1.6 会话 41
2.1.7 规范化数据模型 41
2.1.8 欢迎来到现实世界 41
2.2 这是架构吗 42
2.2.1 定义软件架构 42
2.2.2 (建筑)架构决策 43
2.2.3 关键决策无须复杂 45
2.2.4 符合目标 45
2.2.5 通过测试 45
2.3 每个系统都是完美的 46
2.3.1 加热器系统 46
2.3.2 反馈回路 47
2.3.3 有组织的复杂性 47
2.3.4 系统效应 48
2.3.5 理解系统行为 48
2.3.6 影响系统行为 49
2.3.7 系统抗拒改变 50
2.3.8 组织和技术系统 50
2.4 别有代码恐惧症 51
2.4.1 代码恐惧症 51
2.4.2 好的初衷 52
2.4.3 抽象层次 52
2.4.4 简单化与灵活性 52
2.4.5 抽象打包 52
2.4.6 配置 53
2.4.7 代码还是数据 53
2.4.8 运行时与设计时 54
2.4.9 工具化 54
2.4.10 配置化编程 55
2.4.11 配置还有用武之地吗 55
2.5 如果从不杀死任何系统,你就会被“僵尸”包围 56
2.5.1 遗留系统 56
2.5.2 变更恐惧症 57
2.5.3 版本升级 57
2.5.4 运行与变更 58
2.5.5 按计划报废 58
2.5.6 如果疼,就多做几次 59
2.5.7 拥抱变更的文化 59
2.6 平面的IT世界 60
2.6.1 失真的供应商地图 61
2.6.2 在你的地图上标绘产品 61
2.6.3 绘制版图 62
2.6.4 产品理念 63
2.6.5 制图标准 63
2.6.6 版图迁移 64
2.7 永远不要派人去干机器的活 65
2.7.1 让一切自动化 65
2.7.2 这不只和效率相关 65
2.7.3 可重复性能够提振信心 66
2.7.4 自助服务 66
2.7.5 超越自助服务 67
2.7.6 自动化不是单行道 67
2.7.7 显性知识才是好知识 68
2.7.8 人的用武之地 68
2.8 如果软件吞没了整个世界,最好使用版本控制 69
2.8.1 SDX——软件定义一切 69
2.8.2 纺纱工的暴动 70
2.8.3 像软件工程师一样思考 71
2.8.4 使用构建管道 71
2.8.5 质量检验自动化 72
2.8.6 合适的语言 72
2.8.7 软件吞没世界,一次一个修订 73
第3章 沟通 74
3.1 诠释技术主题 77
3.1.1 给高管们的高性能计算架构 77
3.1.2 搭建斜坡,而不是峭壁 77
3.1.3 留意间隙 78
3.1.4 首先,创造一种语言 79
3.1.5 一致的细节层次 79
3.1.6 我本来想要的,但又不敢 80
3.2 写给大忙人 81
3.2.1 写作可以延伸到更多受众 81
3.2.2 质量与影响 82
3.2.3 “在手中”——第一印象很重要 82
3.2.4 好文章就像电影《怪物史莱克》 83
3.2.5 让读者轻松些 83
3.2.6 写作曲线——线性化 84
3.2.7 简洁明了 85
3.2.8 作家研讨会 86
3.2.9 笔杆子比枪杆子更强大,但仍敌不过企业政治 86
3.3 重点突出胜过面面俱到 87
3.3.1 3 秒测试 87
3.3.2 声明 88
3.3.3 突击测验 88
3.3.4 言简意赅 89
3.3.5 技术备忘录 89
3.4 给孩子们看看海盗船 90
3.4.1 获取关注 90
3.4.2 兴奋 91
3.4.3 聚焦目标 91
3.4.4 展示环境 92
3.4.5 里面的内容 92
3.4.6 考虑受众的身份 92
3.4.7 寓“作”于乐 92
3.5 给银行劫匪画像 94
3.5.1 每个人都看到罪犯 94
3.5.2 刑侦肖像专家 95
3.5.3 系统隐喻 95
3.5.4 视点 96
3.5.5 可视化 96
3.5.6 架构疗法 97
3.5.7 错了!重新做 97
3.6 图驱动设计 98
3.6.1 演示技巧——图 98
3.6.2 绘图技能 99
3.6.3 作为设计技术的绘图 100
3.6.4 没有银弹(点) 101
3.7 绘制连线 102
3.7.1 注意连线 102
3.7.2 元模型 103
3.7.3 语义学的语义 104
3.7.4 元素-关系-行为 104
3.7.5 架构图 105
3.7.6 UML 105
3.7.7 警惕过度应用 106
3.7.8 元素风格 106
第4章 组织 107
4.1 控制只是假象 110
4.1.1 假象 110
4.1.2 控制回路 111
4.1.3 智能控制 111
4.1.4 双行道 111
4.1.5 反馈中的问题 112
4.1.6 普鲁士人并不笨 112
4.1.7 实际控制 113
4.1.8 预警系统 113
4.2 他们不再那样构建了 115
4.2.1 为什么IT 架构师钟爱金字塔 115
4.2.2 组织金字塔 115
4.2.3 没有法老,就没有金字塔 116
4.2.4 建造金字塔 116
4.2.5 生活在金字塔里 117
4.2.6 总能变得更糟 118
4.2.7 构建现代结构 118
4.3 黑市并不有效 119
4.3.1 靠黑市来拯救 119
4.3.2 黑市很少有效 120
4.3.3 你不能把黑市外包出去 120
4.3.4 打击黑市 121
4.3.5 反馈和透明度 121
4.4 扩展组织 123
4.4.1 组件设计——个人生产力 123
4.4.2 避免同步点——会议无法扩展 124
4.4.3 中断打断——电话 124
4.4.4 堆积而不是退避 125
4.4.5 异步通信——电子邮件、聊天,等等 125
4.4.6 提问无法扩展——构建缓存 126
4.4.7 设置不当的域边界——过度对齐 127
4.4.8 自助服务是更好的服务 127
4.4.9 保持人性 128
4.5 缓慢的混乱并不是有序 129
4.5.1 快速与敏捷 130
4.5.2 速度和纪律 130
4.5.3 又快又好 130
4.5.4 缓慢的混乱 131
4.5.5 靠ITIL 来救援吗 132
4.5.6 目标和纪律 32
4.5.7 解决办法 133
4.6 通过盗梦治理 134
4.6.1 制定标准 135
4.6.2 通过行政命令治理 135
4.6.3 通过基础设施治理 136
4.6.4 盗梦 137
4.6.5 皇帝的新衣 137
4.6.6 按照需求治理 138
第5章 转型 139
5.1 没有痛苦,就没有改变 141
5.1.1 转型的各个阶段 141
5.1.2 数字化转型的各个阶段 142
5.1.3 一厢情愿地兜售“万灵油” 142
5.1.4 发动机调优 143
5.1.5 沿途求救 143
5.1.6 不变革的痛苦 144
5.1.7 摆脱困境 144
5.2 引导变革 145
5.2.1 拖拉机超过了赛车 145
5.2.2 设定航向 146
5.2.3 去大陆外冒险 146
5.2.4 破釜沉舟 146
5.2.5 理智之岛 147
5.2.6 臭鼬工程 147
5.2.7 局部最优 148
5.2.8 盲人乡 148
5.3 速度经济 149
5.3.1 旧的规模经济 150
5.3.2 关注流程 151
5.3.3 延迟成本 151
5.3.4 可预测性的价值和成本 152
5.3.5 避免重复的价值和成本 152
5.3.6 如何转变思维模式 153
5.4 无限循环 154
5.4.1 构建-衡量-学习循环 154
5.4.2 数字化转速 155
5.4.3 传统组织的阻碍 55
5.4.4 在外部循环 156
5.4.5 加速反馈 156
5.4.6 保持凝聚力 156
5.5 你不能假装已经数字化 158
5.5.1 奠定基础 158
5.5.2 反馈循环 159
5.5.3 按承诺交付 159
5.5.4 以客户为中心 159
5.5.5 共同打造IT 服务 159
5.5.6 吃自家狗粮 160
5.5.7 数字化思维 160
5.5.8 栈谬论 161
5.6 金钱买不到爱情 163
5.6.1 创新者的窘境 163
5.6.2 留意最高薪人士的意见 164
5.6.3 开销和被容忍的低效率 164
5.6.4 外部依赖 164
5.6.5 付出得越多,可能收获越少 165
5.6.6 文化变革要由内而发 166
5.7 有谁喜欢排队吗 167
5.7.1 留意活动间隙 167
5.7.2 一些排队论知识 168
5.7.3 查找队列 168
5.7.4 插队 169
5.7.5 让队列可见 169
5.8 在四个维度上思考 171
5.8.1 在一条线上生活 171
5.8.2 质量与速度 171
5.8.3 更高的自由度 172
5.8.4 改变曲线的形状 173
5.8.5 反转曲线 173
5.8.6 质量是什么 174
5.8.7 少了一个维度 174
第6章 架构IT转型 175
· · · · · · (收起)
原文摘录 · · · · · ·
丛书信息
· · · · · ·
图灵程序设计丛书·程序员修炼系列(共72册),
这套丛书还有
《软件开发与创新》《代码的未来》《程序员超强大脑》《实例化需求》《编程珠玑II》
等
。
喜欢读"架构师应该知道的37件事"的人也喜欢的电子书 · · · · · ·
支持 Web、iPhone、iPad、Android 阅读器
喜欢读"架构师应该知道的37件事"的人也喜欢 · · · · · ·
架构师应该知道的37件事的书评 · · · · · · ( 全部 4 条 )
前两章不错,之后的……
从图书馆借的书,第1章架构,第2章架构师,这两章还是有不少干货的,总结的不错,阅读完有“就是这样”的即视感。 譬如: “换句话说,架构师能理解公司的经营战略,并且能将其转化为技术决策”; “强力胶架构师既懂得架构,又了解技术细节,还明白业务需求,而且还能将大型组...
(展开)
> 更多书评 4篇
论坛 · · · · · ·
在这本书的论坛里发言这本书的其他版本 · · · · · · ( 全部2 )
以下书单推荐 · · · · · · ( 全部 )
- 法学nerd的偏冷读书世界 (李初一)
- 公司图书馆说要买技术书 (李斯特杨)
- 软件架构 (木子三水)
- 数字化抓手----EA/企业架构生命周期管理 (小毛叔)
- 书单|IT专业 (相逢何必曾相识)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
- 在豆瓣转让 有328人想读,手里有一本闲着?
订阅关于架构师应该知道的37件事的评论:
feed: rss 2.0
1 有用 mcjiffy 2020-10-19 17:08:26
书名应该改成:《架构师应该看的那些书和电影》,总体非常不错,旁征博引,丰富的从业经验。
0 有用 AAAA 2023-03-12 22:40:54 北京
全书讲的并没有get到任何想法,一直在讲故事做类比,但实际应该怎样涉及到的很少
0 有用 天平上的尘埃 2021-01-20 20:40:45
写得非常实在
3 有用 肥嘟嘟様 2020-10-24 14:21:45
“让一切自动化。不能自动化的,就做成自助服务。”作者一方面经验丰富,另一方面又能用一些生动形象且令人信服的类比来解释很多现在DevOps下“显而易见”的作法;没有赋能的压力会导致项目没有任何进展,同时还会带来很多挫败感;没有压力的自治无法让团队认真对待项目;而没有自治的压力又会扼杀创新。赋能+自治+压力,一同成就组织。
0 有用 栀子飘香 2023-09-23 16:30:15 广东
收获很多,的确是内功心法
0 有用 余告非 2024-03-04 13:28:05 广东
没有晦涩难懂的技术名词,没有说教口吻,以心法与感悟居多,不错
0 有用 stonecold 2023-10-15 02:24:30 北京
散 乱 核心主旨不连贯 发发微博的意思
0 有用 栀子飘香 2023-09-23 16:30:15 广东
收获很多,的确是内功心法
0 有用 贝乐 2023-03-31 23:05:46 北京
理解片面,以后再读
0 有用 AAAA 2023-03-12 22:40:54 北京
全书讲的并没有get到任何想法,一直在讲故事做类比,但实际应该怎样涉及到的很少