修改软件的艺术

修改软件的艺术 pdf epub mobi txt 电子书 下载 2026

出版者:人民邮电出版社
作者:[美] David Scott Bernstein
出品人:
页数:192
译者:李满庆
出版时间:2017-10
价格:55.00元
装帧:平装
isbn号码:9787115467768
丛书系列:图灵程序设计丛书·程序员修炼系列
图书标签:
  • 软件工程
  • 计算机
  • 编程
  • 软件开发
  • 重构
  • 敏捷
  • [技术.软件工程]
  • 遗漏代码
  • 软件设计
  • 编程艺术
  • 用户体验
  • 代码优化
  • 软件工程
  • 人机交互
  • 开发实践
  • 技术美学
  • 可维护性
  • 创新思维
想要找书就要到 小哈图书下载中心
立刻按 ctrl+D收藏本页
你会得到大惊喜!!

具体描述

本书会帮你降低构建与维护软件的成本。如果你是软件开发者,将学到一套实践方法以构建易修改的代码,因为在应用当中代码经常需要修改。对于和软件开发者合作的管理者来说,本书会向你展示为何引入这九个基本的实践方法,会使你的团队更加有效地交付软件而不至于让软件演变成遗留代码。

《编码的深层理解》 这是一本深入探讨软件开发核心奥秘的实践指南。 在信息技术飞速发展的浪潮中,软件已渗透到我们生活的方方面面,成为现代社会运转的基石。然而,有多少开发者能够真正理解其构建模块的内在逻辑?《编码的深层理解》旨在为所有怀揣精进之志的程序员提供一个更广阔的视野,超越表面的语法和框架,深入到代码的本质,以及支撑这一切的计算机科学原理。 本书并非一本教你如何使用某种特定编程语言的书籍,而是专注于揭示语言背后共通的设计思想和运行机制。我们将从最基础的层面开始,回顾计算机硬件的工作原理,解释二进制如何成为万物之源,进而剖析不同抽象层次的实现方式。通过理解CPU如何执行指令,内存如何管理数据,我们将对程序的性能瓶颈和优化方向产生更深刻的洞察。 我们还将深入探究数据结构的奥秘。从最简单的数组和链表,到复杂的树、图和哈希表,本书将详细解析它们各自的设计理念、时间与空间复杂度,以及在不同场景下的适用性。掌握这些基础工具,能够让你在面对复杂问题时,选择最高效、最优雅的解决方案,而不是陷入低效的 brute-force 尝试。 算法是软件的灵魂,本书将引领你穿越算法设计的广阔天地。我们将不仅仅停留在理解常见算法(如排序、搜索)的实现,更重要的是,将探讨算法设计的思维模式。如何从问题本质出发,抽象出合适的模型?如何分析算法的正确性和效率?我们将通过一系列精心设计的案例,引导你掌握动态规划、贪心算法、分治策略等高级思想,培养你独立解决问题的能力。 编译原理是连接高级语言与机器指令的桥梁。本书将为你揭示编译器是如何一步步将我们编写的易懂代码转化为计算机能够执行的机器码。从词法分析、语法分析到语义分析和代码生成,我们将一起剖析这个复杂而精妙的过程。理解编译器的运作,有助于我们写出更高效、更易于优化的代码,甚至能够洞察一些编译器优化带来的行为变化。 操作系统是软件运行的宏观环境。本书将深入探讨操作系统的核心概念,如进程管理、内存管理、文件系统和并发控制。理解这些概念,对于编写健壮、高效的多线程程序,以及构建可伸缩的分布式系统至关重要。我们将探讨如何有效利用操作系统提供的资源,以及如何避免常见的并发陷阱。 网络通信是现代软件不可或缺的一部分。本书将从TCP/IP协议栈的底层原理出发,解释数据如何在网络中传输,以及HTTP、DNS等常用协议的工作机制。理解这些基础,能够帮助你更好地设计和调试网络应用程序,并理解分布式系统的挑战。 函数式编程的思想正在重塑现代软件开发的范式。本书将介绍函数式编程的核心概念,如纯函数、不可变性、高阶函数和递归。我们将探讨函数式编程如何帮助我们编写更简洁、更易于测试和推理的代码,以及它在并行计算和大数据处理中的优势。 除了技术性的深入,本书还强调了软件设计的哲学和原则。我们将探讨SOLID原则、设计模式的应用,以及如何构建可维护、可扩展的软件系统。理解这些原则,能够帮助你写出结构清晰、易于理解和修改的代码,从而在长期的软件开发过程中保持项目的生命力。 《编码的深层理解》适合: 初学者: 希望在学习编程时就建立扎实的基础,避免日后走弯路。 有一定经验的开发者: 渴望突破瓶颈,从“会写代码”提升到“写好代码”。 希望深入理解软件内部机制的技术爱好者: 对计算机科学的底层原理充满好奇。 系统架构师和技术领导者: 需要对软件的各个层面有全面深入的理解,以做出明智的技术决策。 本书将通过大量的图示、代码示例和思考题,引导读者主动参与,将理论知识转化为实践能力。我们相信,只有真正理解了代码的“为什么”,才能更好地掌握“如何做”。 准备好踏上这段探索代码深层奥秘的旅程吧!

作者简介

David Scott Bernstein

敏捷教练,曾为IBM、微软、Yahoo等企业提供敏捷实践指导。

目录信息

第一部分 遗留代码危机
第1章 有些事情不对劲  2
1.1 什么是遗留代码  3
1.2 顺流直下  4
1.3 孤注一掷  6
1.4 为什么瀑布模型不管用  7
1.4.1 食谱与配方  7
1.4.2 开发和测试分离  8
1.5 当“流程”变成“体力劳动”  8
1.6 坚如磐石的管理  9
1.7 此处有龙  10
1.8 评估未知  11
1.9 一个充满外行人的产业  12
1.10 回顾  13
第2章 逃出混乱  14
2.1 混乱报告  14
2.1.1 成功的  15
2.1.2 遇到困难的  15
2.1.3 失败的(有缺陷的)  15
2.2 驳斥斯坦迪什咨询集团  16
2.3 项目为何会失败  17
2.3.1 情况发生了改变  18
2.3.2 bug泛滥成灾  19
2.3.3 复杂性危机  20
2.4 失败的代价  21
2.4.1 这里十几亿,那里十几亿  21
2.4.2 不同的研究,同样的危机  22
2.5 总结  23
第3章 聪明人,新想法  25
3.1 走进敏捷  25
3.2 小即是好  26
3.3 实现敏捷  27
3.4 艺术与技能的平衡  28
3.5 敏捷跨越鸿沟  29
3.6 追求技术卓越  30
3.7 总结  31
第二部分 延续软件生命(和价值)的9种实践方法
第4章 9个实践  34
4.1 专家知道些什么  35
4.2 守?破?离  36
4.3 首要原则  37
4.4 关于原则  38
4.5 关于实践  38
4.6 原则指导实践  39
4.7 未雨绸缪还是随机应变  40
4.8 定义软件中的“好”  40
4.9 为什么是9个实践  42
4.10 总结  43
第5章 实践1:在问如何做之前先问做什么、为什么做、给谁做  44
5.1 不要说如何  44
5.2 将“如何”变为“什么”  45
5.3 要有一个产品负责人  46
5.4 故事描述了做什么、为什么做、给谁做  48
5.5 为验收测试设立明确标准  50
5.6 自动化验收标准  50
5.7 让我们付诸实践  51
5.7.1 产品负责人的7个策略  51
5.7.2 编写出更好用户故事的7个策略  52
5.8 总结  53
第6章 实践2:小批次构建  55
6.1 更小的谎言  56
6.2 学会变通  56
6.3 控制发布节奏  58
6.4 越小越好  59
6.5 分而治之  60
6.6 更短的反馈回路  62
6.7 提高构建速度  63
6.8 对反馈做出响应  64
6.9 建立待办列表  65
6.10 把用户故事拆分为任务  66
6.11 跳出时间盒子思考  66
6.12 范围控制  67
6.13 让我们付诸实践  69
6.13.1 度量软件开发的7个策略  69
6.13.2 分割用户故事的7个策略  70
6.14 总结  71
第7章 实践3:持续集成  72
7.1 建立项目的心跳  73
7.2 理解完成、完整完成和完美完成的区别  73
7.3 实践持续部署  74
7.4 自动化构建  75
7.5 尽早集成,频繁集成  76
7.6 迈出第一步  76
7.7 付诸实践  77
7.7.1 构建敏捷设施的7个策略  77
7.7.2 消除风险的7个策略  79
7.8 总结  80
第8章 实践4:协作  81
8.1 极限编程  82
8.2 沟通与协作  83
8.3 结对编程  84
8.3.1 结对的好处  85
8.3.2 如何结对编程  86
8.3.3 和谁结对  87
8.4 伙伴编程  88
8.5 穿刺,群战,围攻  89
8.5.1 穿刺  89
8.5.2 群战  89
8.5.3 围攻  89
8.6 在时间盒子中对未知进行调研  90
8.7 定期代码审查和回顾会议  91
8.8 加强学习和知识分享  92
8.9 诲人不倦且不耻下问  92
8.10 让我们付诸实践  93
8.10.1 结对编程的7个策略  93
8.10.2 高效回顾会议的7个策略  94
8.11 总结  95
第9章 实践5:编写整洁的代码  97
9.1 高质量的代码是内聚的  98
9.2 高质量的代码是松散耦合的  99
9.3 高质量的代码是封装良好的  100
9.4 高质量的代码是自主的  102
9.5 高质量的代码是没有冗余的  104
9.6 让代码特质指导我们  105
9.7 今天的代码质量提高会为将来带来速度的提升  106
9.8 让我们付诸实践  107
9.8.1 提高代码质量的7个策略  107
9.8.2 编写可维护代码的7个策略  108
9.9 总结  109
第10章 实践6:测试先行  110
10.1 测试的种类  111
10.1.1 验收测试 = 客户测试  111
10.1.2 单元测试 = 开发者测试  111
10.1.3 其他测试 = 质量保证测试  112
10.2 质量保证  112
10.2.1 测试驱动开发不能取代质量保证  113
10.2.2 单元测试不是万能的  113
10.3 编写优质测试  114
10.3.1 这不是测试  115
10.3.2 以行为作为单元  115
10.4 TDD可以提供迅速的反馈  116
10.5 TDD可以为重构提供支持  116
10.6 编写可测试的代码  117
10.7 TDD也会失败  118
10.8 如何将TDD引入团队  119
10.9 成为测试感染者  119
10.10 让我们付诸实践  120
10.10.1 进行优质验收测试的7个策略  120
10.10.2 进行优秀单元测试的7个策略  121
10.11 总结  122
第11章 实践7:用测试描述行为  123
11.1 红条、绿条、重构  124
11.2 一个用测试先行来描述行为的实例  125
11.2.1 编写测试  125
11.2.2 存根代码  126
11.2.3 实现行为  127
11.3 引入限制条件  128
11.3.1 编写测试和代码存根  129
11.3.2 实现行为  129
11.4 我们创建了什么  130
11.5 测试就是标准  132
11.6 测试需要完整  133
11.7 让测试独一无二  134
11.8 用测试来覆盖代码  134
11.9 bug是缺失的测试  135
11.10 用模拟对象来测试工作流  135
11.11 建立防护网  136
11.12 让我们付诸实践  136
11.12.1 使用测试作为标准的7个策略  136
11.12.2 修复bug的7个策略  137
11.13 总结  139
第12章 实践8:最后实现设计  140
12.1 可变性的阻碍  140
12.2 可持续性开发  142
12.3 编码与清理  143
12.4 软件被阅读的次数比编写次数多  143
12.5 意图导向编程  144
12.6 降低圈复杂度  145
12.7 将创建和使用分离  146
12.8 演化式设计  147
12.9 让我们付诸实践  147
12.9.1 进行演化式设计的7个策略  148
12.9.2 清理代码的7个策略  149
12.10 总结  150
第13章 实践9:重构遗留代码  151
13.1 投资还是借贷  152
13.2 变成“铁公鸡”  153
13.3 当代码需要修改时  153
13.3.1 对已有代码添加测试  154
13.3.2 通过重构糟糕代码来培养良好习惯  154
13.3.3 推迟那些不可避免的  155
13.4 重构技巧  155
13.4.1 图钉测试  155
13.4.2 依赖注入  156
13.4.3 系统扼杀  156
13.4.4 抽象分支  156
13.5 以支持修改为目的重构  157
13.6 以开闭原则为目的重构  157
13.7 以提高可修改性为目的重构  158
13.8 第二次做好  158
13.9 让我们付诸实践  159
13.9.1 助你正确重构代码的7个策略  159
13.9.2 决定何时进行重构的7个策略  161
13.10 总结  162
第14章 从遗留代码中学习  163
14.1 更好,更快,更廉价  164
14.2 不在不需要的事情上花钱  166
14.3 循规蹈矩  167
14.4 提升整个软件行业  168
14.5 超越敏捷  169
14.6 将理解具象化  170
14.7 成长的勇气  171
参考文献  174
· · · · · · (收起)

读后感

评分

评分

评分

评分

评分

用户评价

评分

说实话,我对“修改软件的艺术”这本书的期待,更像是寻找一本能让我“顿悟”的宝典。软件开发,尤其是大型项目,往往是一个不断演进的过程,修改是绕不开的环节。但我发现,很多时候,我们只是在“修补”,而不是在“优化”或“进化”。这本书的“艺术”二字,让我觉得它可能触及到了修改软件的更高境界。我希望它能深入探讨那些关于代码的“本质”的东西,比如设计模式在修改中的应用,如何通过清晰的架构设计来降低修改的复杂度,以及如何构建健壮的测试体系来支持频繁的修改。我更想看到的是,如何将修改变成一种创造性的过程,而不是一种负担。这本书会不会揭示一些隐藏在“修改”背后的哲学,让我能从更宏观的视角去理解软件的生命周期,以及我们在其中扮演的角色?我很期待,它能给我带来不同于以往的启发。

评分

我买这本书,主要是被它的“艺术”两个字吸引了。很多技术书籍往往专注于“术”,也就是具体的技巧和工具,但“艺术”则意味着更高层次的理解和创造力。我一直相信,好的软件修改,就像好的艺术品一样,需要有清晰的整体观,同时又能兼顾细节的精妙。我希望能在这本书里找到一些关于如何培养这种“艺术感”的启发。或许它会探讨软件设计的原则如何影响修改的便利性,又或者如何通过重构来提升代码的可读性和可维护性,从而让后续的修改变得更加容易。我脑海里常常浮现出那种感觉,当你修改一段代码,不仅解决了问题,还让整个系统的结构变得更清晰,更优雅,这就是一种艺术的体现。这本书能否帮助我达到这样的境界?我对此充满了好奇,也希望它能提供一些理论框架,让我能够更好地理解“为什么”要这样做,而不仅仅是“怎么”做。

评分

当我看到“修改软件的艺术”这个书名时,我的脑海里立刻闪过无数次在深夜面对一堆难以理解的代码,试图进行修改的场景。那种感觉,既有挑战,又带着一丝绝望。我希望能在这本书里找到一些能够点亮我内心黑暗的“火种”。我渴望它能提供一套行之有效的方法论,指导我如何去理解那些“前人”留下的代码,即使这些代码看起来杂乱无章,难以入手。也许书中会介绍一些分析工具,或者一些思维模式,能够帮助我快速抓住代码的核心逻辑。更重要的是,我希望能学到如何在修改过程中,尽可能地减少对现有功能的影响,甚至能够通过修改来提升软件的整体质量。我期待这本书能够给我带来一种“化腐朽为神奇”的力量,让我不再畏惧那些复杂的代码库。

评分

坦白说,我一开始对这本书的期待并不是特别高。市面上的软件开发书籍很多,但真正能触及本质、让人眼前一亮的并不多。但“修改软件的艺术”这个名字,总有一种莫名的吸引力,让我想去一探究竟。我总觉得,软件开发最容易被忽视,也最考验功力的,就是对已有代码的修改。很多时候,我们匆忙地加上新的功能,或者修复一个bug,却可能埋下更多隐患。这本书会不会提供一种系统性的方法,让我们在修改的时候,能够更有章法,而不是凭感觉“缝缝补补”?我希望能看到书中对“坏味道”代码的识别,以及如何逐步改善这些“坏味道”的策略。同时,我也对书中关于如何权衡修改成本和收益的讨论很感兴趣。毕竟,在实际工作中,我们总要面对时间和资源的限制,如何在“完美”和“可用”之间找到一个平衡点,是一门重要的学问。

评分

这本书的书名很有意思,“修改软件的艺术”。拿到手的时候,我第一反应就是,这肯定不是一本教你如何从零开始写代码的书。更像是对那些已经写好的软件,如何去“雕琢”、“打磨”的指南。我一直觉得,软件开发中最有挑战性的部分,往往不是创造,而是维护和改进。当需求改变,或者出现了意想不到的bug,甚至是为了优化性能,都需要我们深入到已有的代码中去,小心翼翼地进行修改。这本书的名字就准确地捕捉到了这种精髓——修改,并非简单的增删改查,而是一门需要技巧、经验和洞察力的艺术。我期待它能给我一些关于如何安全、高效地进行软件修改的深刻见解,尤其是在处理遗留系统或者复杂项目中,如何避免“牵一发而动全身”的风险。希望它能提供一些实用的方法论,比如如何更好地理解现有代码的逻辑,如何设计出易于维护的修改方案,以及如何在修改后进行有效的测试,确保软件的稳定性和可靠性。

评分

the way to Scrum. 技术人的书就是这样, 讲理论也是条条道道文理清晰. 当然, 内容多, 重复也多, 建议画个脑图, 核心内容其实不多. https://www.jianshu.com/p/fb6ecc0eecaa

评分

作者30年的从业经验,在TDD这章用了一个极其简单的Person类来阐述,是没有说服力的。勇气真的是非常非常重要,重要到我认为只要能拥有勇气就能成功的程度。

评分

絮絮叨叨的。

评分

本书偏向于介绍敏捷开发、项目管理。本书也比较薄,不到两百页。

评分

挺不错的书,介绍了9种构建易维护代码的方法,有不少真知灼见,但深度不够,代码示例也显得比较少,很多地方不带有自己实践是很难体会的。//去年冬天就想读的书,过了大半年,终于花了几天时间看完,因为拖延,我甚至要付给图书馆约8元的超期罚金。2018-07-06@水澜轩,借于浙江图书馆

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2026 qciss.net All Rights Reserved. 小哈图书下载中心 版权所有