对你影响最深的计算机书籍是哪一本?

如果非要拿出来一本的话,我推荐《重构:改善既有代码的设计》(第2版 平装版),一本普通程序员进阶到编程高手的修炼秘笈,软件开发大师Martin Fowler的不朽经典,影响了几代程序员。

对你影响最深的计算机书籍是哪一本?_第1张图片

本书是一本为专业程序员编写的重构指南。我的目的是告诉你如何以一种可控且高效的方式进行重构。你将学会如何有条不紊地改进程序结构,而且不会引入错误,这就是正确的重构方式。

一起来和小编了解这本书每章的内容介绍吧,每一章节中还有小编的摘录。

第1章 重构,第一个示例

本章的重构有3个较为重要的节点,分别是:将原函数分解成一组嵌套的函数、应用拆分阶段(154)分离计算逻辑与输出格式化逻辑,以及为计算器引入多态性来处理计算逻辑。每一步都给代码添加了更多的结构,以便我能更好地表达代码的意图。

我谈论的是如何改善代码,但什么样的代码才算好代码,程序员们有很多争论。我偏爱小的、命名良好的函数,也知道有些人反对这个观点。如果我们说这只关乎美学,只是各花入各眼,没有好坏高低之分,那除了诉诸个人品味,就没有任何客观事实依据了。但我坚信,这不仅关乎个人品味,而且是有客观标准的。我认为,好代码的检验标准就是人们是否能轻而易举地修改它。好代码应该直截了当:有人需要修改代码时,他们应能轻易找到修改点,应该能快速做出更改,而不易引入其他错误。一个健康的代码库能够最大限度地提升我们的生产力,支持我们更快、更低成本地为用户添加新特性。为了保持代码库的健康,就需要时刻留意现状与理想之间的差距,然后通过重构不断接近这个理想。

好代码的检验标准就是人们是否能轻而易举地修改它。

这个示例告诉我们最重要的一点就是重构的节奏感。无论何时,当我向人们展示我如何重构时,无人不讶异于我的步子之小,并且每一步都保证代码处于编译通过和测试通过的可工作状态。

第2章 重构的原则

前一章所举的例子应该已经让你对重构有了一个良好的感觉。现在,我们应该回头看看重构的一些大原则。

在第2章就开始谈延展阅读,这似乎有点儿奇怪。不过,有大量关于重构的材料已经超出了本书的范围,早些让读者知道这些材料的存在也是件好事。

第3章 代码的坏味道

难题来了!解释“如何删除一个实例变量”或“如何产生一个继承体系”很容易,因为这些都是很简单的事情,但要解释“该在什么时候做这些动作”就没那么顺理成章了。除了露几手含混的编程美学(说实话,这就是咱们这些顾问常做的事),我还希望让某些东西更具说服力一些。

如果你无法确定该采用哪一种重构手法,请阅读本章内容和书后附的“重构列表”来寻找灵感。你可以阅读本章或快速浏览书后附的“坏味道与重构手法速查表”来判断自己闻到的是什么味道,然后再看看我们所建议的重构手法能否帮到你。也许这里所列的“坏味道条款”和你所检测的不尽相符,但愿它们能够为你指引正确方向。

如果你不知道该做什么,这才是注释的良好运用时机。除了用来记述将来的打算之外,注释还可以用来标记你并无十足把握的区域。你可以在注释里写下自己“为什么做某某事”。这类信息可以帮助将来的修改者,尤其是那些健忘的家伙。

第4章 构筑测试体系

重构是很有价值的工具,但只有重构还不行。要正确地进行重构,前提是得有一套稳固的测试集合,以帮我发现难以避免的疏漏。即便有工具可以帮我自动完成一些重构,很多重构手法依然需要通过测试集合来保障。

我并不把这视为缺点。我发现,编写优良的测试程序,可以极大提高我的编程速度,即使不进行重构也一样如此。这让我很吃惊,也违反许多程序员的直觉,所以我有必要解释一下这个现象。

一个测试集是否足够好,最好的衡量标准其实是主观的,请你试问自己:如果有人在代码里引入了一个缺陷,你有多大的自信它能被测试集揪出来?这种信心难以被定量分析,盲目自信不应该被计算在内,但自测试代码的全部目标,就是要帮你获得此种信心。如果我重构完代码,看见全部变绿的测试就可以十分自信没有引入额外的bug,这样,我就可以高兴地说,我已经有了一套足够好的测试。

第5章 介绍重构名录

本书剩余的篇幅是一份重构的名录。最初这个名录只是我的个人笔记,我用它来提示自己如何以安全且高效的方式进行重构。然后我不断精炼这份名录,对一些重构的深入探索又引出了更多的重构手法。对于不太常用的重构手法,我还是会不断参阅这份名录。

第6章 第一组重构

在重构名录的开头,我首先介绍一组我认为最有用的重构。

第7章 封装

分解模块时最重要的标准,也许就是识别出那些模块应该对外界隐藏的小秘密了[Parnas]。数据结构无疑是最常见的一种秘密.......

第8章 搬移特性

到目前为止,我介绍的重构手法都是关于如何新建、移除或重命名程序的元素。此外,还有另一种类型的重构也很重要,那就是在不同的上下文之间搬移元素。

一旦代码不再被使用,我们就该立马删除它。有可能以后又会需要这段代码,但我从不担心这种情况;就算真的发生,我也可以从版本控制系统里再次将它翻找出来。如果我真的觉得日后它极有可能再度启用,那还是要删掉它,只不过可以在代码里留一段注释,提一下这段代码的存在,以及它被移除的那个提交版本号——但老实讲,我已经记不得我上次撰写这样的注释是什么时候了,当然也未曾因为不写而感到过遗憾。

在以前,业界对于死代码的处理态度多是注释掉它。在版本控制系统还未普及、用起来又不太方便的年代,这样做有其道理;但现在版本控制系统已经相当普及。如今哪怕是一个极小的代码库我都会把它放进版本控制,这些无用代码理应可以放心清理了。

第9章 重新组织数据

数据结构在程序中扮演着重要的角色,所以毫不意外,我有一组重构手法专门用于数据结构的组织。将一个值用于多个不同的用途,这就是催生混乱和bug的温床。

如果顾客数据永远不修改,那么两种处理方式都合理。把同一份数据复制多次可能会造成一点困扰,但这种情况也很常见,不会造成太大问题。过多的数据复制有可能会造成内存占用的问题,但就跟所有性能问题一样,这种情况并不常见。

如果共享的数据需要更新,将其复制多份的做法就会遇到巨大的困难。此时我必须找到所有的副本,更新所有对象。只要漏掉一个副本没有更新,就会遭遇麻烦的数据不一致。这种情况下,可以考虑将多份数据副本变成单一的引用,这样对顾客数据的修改就会立即反映在该顾客的所有订单中。

第10章 简化条件逻辑

程序的大部分威力来自条件逻辑,但很不幸,程序的复杂度也大多来自条件逻辑。我经常借助重构把条件逻辑变得更容易理解。

我只用断言预防程序员的错误。如果要从某个外部数据源读取数据,那么所有对输入值的检查都应该是程序的一等公民,而不能用断言实现——除非我对这个外部数据源有绝对的信心。断言是帮助我们跟踪bug的最后一招,所以,或许听来讽刺,只有当我认为断言绝对不会失败的时候,我才会使用断言。

第11章 重构API

模块和函数是软件的骨肉,而API则是将骨肉连接起来的关节。易于理解和使用的API非常重要,但同时也很难获得。随着对软件理解的加深,我会学到如何改进API,这时我便需要对API进行重构。

好的API会把更新数据的函数与只是读取数据的函数清晰分开。

第12章 处理继承关系

在最后一章里,我将介绍面向对象编程技术里最为人熟知的一个特性:继承。与任何强有力的特性一样,继承机制十分实用,却也经常被误用,而且常得等你用上一段时间,遇见了痛点,才能察觉误用所在。

小编还想再推荐一本《代码整洁之道》

对你影响最深的计算机书籍是哪一本?_第2张图片

“阅读这本书有两种原因:第一,你是个程序员;第二,你想成为更好的程序员。很好,IT行业需要更好的程序员!”——罗伯特·C. 马丁(Robert C. Martin)

鲍勃大叔作品,程序员,汇聚编程数十年编程生涯的心得体会,阐释如何解决软件开发人员、项目经理及软件项目领导们所面临的棘手的问题。

学写整洁代码很难。它可不止于要求你掌握原则和模式。你得在这上面花工夫。你须自行实践,且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步,再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策,又是如何为错误决策付出代价。

本书提出一种观念:代码质量与其整洁度成正比。干净的代码,既在质量上较为可靠,也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者,本书作者给出了一系列行之有效的整洁代码操作实践。这些实践在本书中体现为一条条规则(或称“启示”),并辅以来自现实项目的正、反两面的范例。只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量。

你可能感兴趣的:(重构,架构师,程序员)