《代码简洁之道》读书笔记

[TOC]

前言：

​ 这本书算是一本编程必读书，对于如何优化自己的代码很有帮助。这本书看了有将近一周的时间，更多时间花在了实践代码上面，按照书中给出的建议去思考和优化自己的代码，发现其中的过程其实是非常快乐的，这次的读书笔记介绍一下从这本书中学到了那些内容。

文章目的：

1. 努力写出简洁的代码是程序员的基本素质，时刻关注各个细节

2. 把简单的事情做到极致，才有能力做更有挑战的事情

3. 收集《代码简洁之道》的书籍基本知识和内容点，回顾书籍个人认为比较重要的内容。

4. 利用思维导图总结整个书籍的大致内容（导图内容较为庞大）

简述：

​ 作者通过最简单的为什么要编写代码到编写简洁代码的一些建议，从最简单的命名规范逐渐扩展到方法，类，系统，到最终利用一个实际的案例讲述作者亲身经历的一次代码重构体验，在难易度和节奏的把控比较到位，不需要担心一上来就是复杂的理论，非常具备条理。

​ 这本书的内容比较重要的是在于实战，提供大量代码和说明进行迭进式改造（虽然看的想睡觉），如果当做理论书去看把这本书简单扫一遍其实毫无意义。同时这本书全书围绕着“简洁”两个字，用了大量的案例和实际经验举证各种程序员写代码容易犯的错误，稍微看看就可以看到很多建议“很像”自己平时写代码的做法。

​

推荐程度：

强烈推荐，程序员必读书之一，作者提供了很多的建议如何写出整洁的代码，同时给出代码实战怎么处理代码。

如果想要看实战代码改进部分，可以查看附录B对于SerialDate这个类是如何进行迭进和改造的，对于学习改良代码十分有帮助。

最大的问题可能还是本书没有配套的源代码。书中许多对于代码的优化思路在阅读的时候不易理解作者思路

思维导图：

由于这本书的笔记单靠一篇文章很难梳理完，为了节省阅读文章的时间个人将书本的内容提炼笔记和重点精简为思维导图，读者可以按需参考思维导图阅读：

https://share.mubu.com/doc/2oVODZ8tw25

幕布思维导图

书籍内容分析：

重点阅读：

下面列出几个比较重要的点，这里去掉了后面几章对于代码的迭进相关章节，注意这些内容比较重要，但是苦于找不到现成代码所以没有列入考虑范围（用纸看代码虽然可以但是十分痛苦并且难以理解，个人认为效率太低），所以只列出前面建议的部分以及最终的总结部分。

PS：下面的内容摘录自思维导图

• 第三章：函数

  • 重点

  • 时刻保持参数的数量控制

  • 函数要返回期望的内容，运行期望的行为

  • 避免副作用的方法

  • 取个好名是好方法的关键步骤

  • 简介

  • 介绍如何写出更加简单并且令人夸赞的好方法

  • 函数式封装的第一个步骤，时刻练习如何写出好的函数

• 第四章：注释

  • 重点

  • 写出好代码才是关键，先写出好简洁代码，再考虑写好注释

  • 最好的状态是代码本身就能诠释注释

  • 努力写出简单易懂的好注释

  • 好注释不仅可以让阅读者理解，还可以让阅读者学到新知识

  • 简介

  • 写一个注释容易，但是写好一个注释不容用。

  • 程序员因为各种“借口”懒得写注释

  • 如果你的代码足够具备表达力，就不需要注释，否则请加上你的注释

• 第七章：异常处理

  • 重点

  • 异常处理的一些技巧

    • 用单独的方法进行try/catch

    • 从大的异常到细化异常

  • 不要返回Null值

  • 异常需要作为单一职责看待，而不是和方法捆绑

  • 简介

  • 异常处理是一种权责，不要和业务混淆

  • 异常处理的基本手段和一些原则介绍

• 第九章：单元测试

  • 重点

  • 测试单元：一个测试一个断言，测试单元尽可能简短

  • FIRST原则

    • F：快速

    • 测试可以快速进行

    • I：独立

    • 测试之间相互独立

    • R：可重复

    • 测试在任何环境都可以通过

    • S：自足验证

    • 存在布尔值输出，可以验证自己的结果

    • T：及时

    • 测试要及时进行编写

  • 简介

  • 学习使用TDD测试驱动开发的形式

  • 单元测试是非常重要并且必要的

    • 测试的好处

    • 整洁的测试

  • TDD的三大定律

    • 编写不能通过的测试代码之前，不编写生产代码

    • 只编写刚好无法通过的单元测试

    • 只编写刚好足以通过测试的生产代码

• 第十章：类

  • 重点

  • 少量的大类并不一定比大量小类好管理

  • 用尽可能少的类和方法完成目的

  • 类不应该有太多的权责和干扰

  • 简介

  • 关键内容在于类的权责拆分

    • 当失去内聚的时候就想办法拆分

    • 生活抽象：你是要一个装任何东西的百宝箱还是一个布满各种放个的工具箱

• 第十七章：味道和启发 #重点

  • 重点

  • 总结全书的一些要点

  • 回顾全书的重点内容

  • 简介

  • 非常重要的一个章节，用一个章节概括了全书的一些重要内容

  • 可以从最后一章确定全书要阅读的部分

作者的核心思想：

从头到尾认真仔细阅读下来，做了很多的笔记，下面就个人理解说一下作者的几个核心思想：

• 单一职责：不管编写简单还是复杂的代码，都需要关注权责的拆分。
• 简洁：要想尽一切办法努力优化自己的代码，养成一个良好的编程习惯。
• 迭进：作者通过大量的案例和代码表达对于代码是如何一步步进行迭代改进的，要不断的思考和改良
• 注释：好注释真的非常非常重要，虽然注释这一章其实更像是作者的吐槽和埋怨
• 批判精神：不在乎水平的高低，敢于去重构代码，并且反省和思考
• 重构：看似每一个无关紧要的细节的改动对于系统构建产生的魔力变化

序章

序章可以明白作者写这本书的用意，作者鼓励读者对于代码提出挑战，并提出了如下的观点：

• 神在细节之中
• 5S哲学
  • 整理：命名规范
  • 整顿：每段代码在期待的地方
  • 清楚：注释和处理应用diamante
  • 清洁：组织结构清晰
  • 身美：乐于改进

首章要有代码

作者在第一章不是上来就介绍如何编写好代码或者一些技巧，而是探讨提倡的AI编程（其实很早就有这个概念了）以及编写代码的重要性，下面记录书中提出的对于编写代码的一些态度，个人理解是作者对代码存在极致的追求，所以开头便鼓励读者要写出 整洁的代码：

• 代码永存，必须要要有代码
• 勒布朗法则：稍后等于永远不做
• 不要把烂代码归咎为外因
• 好代码的前提
  • 果断敢绝，就事论事，没有犹豫和无用细节
  • 外表或者举止令人愉悦，优美与雅致

味道和启发

个人建议时间比较紧迫或者想要简单了解全书大致内容的，直接去阅读最后一个章节“味道与启发”，本部分内容直接介绍了全书的一些核心理念，相当如作者给你做了一次总结，非常良心。建议重点阅读本章节的内容，里面用了非常多的小点介绍了一些平时编写简洁代码的建议。

附录部分内容：附录的内容比较容易被忽略，虽然是对于并发模块和测试检测异常做了一个入门的介绍。这部分作者讲了个人亲身经历调优并发代码的故事比较有意思。

附录部分摘录

这里记录附录部分关于如何计算线程的路径数量笔记

如何计算路径数量：

假设有N个指令和T个线程，将会产生T*N个步骤

假设有步骤AB和线程12，将会有如下的情况：

1122、1212、1221、2112、2211、2121

他们的特征是：每个T会出现N次，因为不管顺序如何执行，执行肯定会被执行完成

这样就引出一个公式：

(N*T)! / N!^T （!为阶乘操作）

举例：对于有2个步骤和2个线程的代码， 带入公式可得：(2*2)!  / (2!)^2 = 24 / 4 = 6

将会出现6种情况

那么这时候就会有疑问了，我们synchronized到底改变了什么？

我们按照上面的假设，有2个线程得出来的结果是 N! 就是 指令的阶乘变为常数2

个人感悟：

​ 对于个人来说这本书物超所值，干货满满的一本书，不是单纯的讲空话，而是针对代{过}{滤}理的代码案例进行吐槽，特别是注释这一个章节，以前喜欢写很多的注释生怕同事看不懂过来询问（当然牵扯业务问题很乐意与同事讨论），但是看完书感觉以前做的事情有些多余。个人在工作之后，逐渐养成了编写文档的习惯，不管需求大小，总是喜欢写一写文字记录一下需求以及自己的思路轮廓，实践下来发现还是挺有用的，虽然事后会觉得文档写的很啰嗦或者有时候会忘记写过文档=-=，而且有些可能还不算十分准确，但是对于自己回顾业务和需求确实有一定的帮助。总之，非常庆幸自己坚持下来读完整本书。

下面是个人的一些感悟，同时如果不想看书，可以参考下面列出个人比较建议的点：

• 边看边思考，边看边实践。实践最重要

• 代码不是一步到位的，代码永远都没有最优解，根据自己的能力要不断摸索更优解。刻意练习

• 不想看书的一些建议点

  • 单一职责

  • 代码是否真的只做了一件事，是否在自己骗自己

  • 验证是否只做一件事的万金油法则：加需求

  • 方法是否是“全包干”

  • 不要重复自己

  • "CV"编程会让水平停留在"CV"

  • 现代的编辑器可以减少很多思考

  • 什么是简洁

  • 没有注释，读代码就像在读业务逻辑

  • 没有过时的注释，也没用错误的注释，更没有没用的注释

  • 用最少的代码做最大的事情，代码复用度高

  • 没有重复，单一职责

  • 迭进

  • 学会拆分职责和剥离职责

• 思考何为面向对象

  • 不断的改进，写出更简洁的代码

• 批判：不断接受批评，才能不断进步

下面是个人想到的一些日常生活中碰到的参考案例以及一些小思考，读者可以写下自己碰到或者遇到的编程习惯进行批判：

• 在做需求之前，写一份需求文档的草稿。不要求十分的精确，但是要简略的说明改动的理由

  • 介绍需求
  • 思路
  • 解决步骤1、2、3

• 喜欢一行代码一行注释，在保证完成任务的前提下补齐个人的注释代码

  • 写代码不是写文章，不需要面面俱到
  • 大量的注释容易埋没代码本身的价值

• 容易编写许多参数的方法，并且通常容易忽视

  • 该需求喜欢喜+1，这周情况不妙

• 不自觉的写出很多无用注释，和书中的喃喃自语相同

• 改正喜欢写很多注释的习惯

• 改正喜欢CV代码的习惯

• 多想想自己写的代码是否符合设计规则，是否是在重复劳动

• 让方法和参数的命名更加的符合规范

• 复查代码，注意代码的格式和行数

• 思考设计模式思想能否在代码层面应用。

• 减少参数名，多注意方法的取名

• 偷懒是烂代码的本质原因

•  

书本总结：

​ 这本书更多的还是建议将书中的观点带入到实际的代码当中，会有比较好的效果，因为作者提出的很多问题确实从自己的代码当中显而易见（冗余的注释，累赘的方法等等）

​ 先说说这本书的优点，虽然年代可能比较久远，而且某些思想可能不是非常符合现代的开发思想，但是依然可以看到很多值得借鉴的地方，比如要时刻注意细节，并且要敢于打破自己的代码思考新的方向，个人从书中查漏补缺，反省了一下自己需要改正的一些编程思路，对于提升个人的编程水平确实是有实际作用的。

​ 再说说缺点，首先是代码部分，个人认为部分案例代码来的比较突兀，同时由于很多代码不存在上下文的关联，虽然作者进行了解释但是依然让读者摸不着头脑（当然也可能是个人理解能力问题），总之不是部分代码案例确实云里雾里。其次是书中包含的代码量较多，需要较长的时间消化和吸收，比较影响沉浸式的阅读体验。当然这本书更多的也是支持读者去自己实践。

​ 这本书个人比较遗憾的是代码部分，因为书中作者从12章之后介绍如何迭进代码，加入使用实际的案例如何改写“烂”代码的，粗略看了下虽然可以理解作者想要尽力的告知读者一些优化思想，但是个人在网络上寻找很久依然没有找到相关的源码，比较遗憾。同时篇幅多大几页的代码以及没有上下文的代码在书本当中有些让人望而却步。

​ 作者在书中说建议查看《字面编程》这本书135页对于权责拆分的良好案例，后续会花时间去研究一下

精句阅读：

只有通过批评，我们才能学到东西。医生就是这样做的，飞行员就是这样做的，律师就是这样做的，我们程序员也需要学习如何这样做。（书本的252页）

这里偷懒直接截图了=-=

总结：

​ 更多的内容欢迎查看思维导图，为了避免文章的内容过长，将更多的细节放置到思维导图帮助自己的思考和回顾。后续将会阅读《重构》这本书，虽然也是一本老书，但是看到很多人进行了推荐所以也买了一本翻翻看。这本书也花了很多的心思编写读书笔记，希望读者给予建议。