代码整洁之道
2021-09-27 10:24:53 0 举报AI智能生成
《代码整洁之道》 读书知识归纳
作者其他创作
大纲/内容
整洁的代码只做好一件事
集中
见名知意
表达力
小规模抽象
可读性
易修改
消除重复
整洁代码
命名可以不需要注释来补充说明
类和对象用名词
方法用动词
别害怕长名称
别害怕花时间取名字
命名方式保持一致
函数使用描述性的名称
名副其实
避免系统关键词
避免相似
废话都是冗余
避免无意义词汇
避免添加不必要的语境
避免混淆
易于搜索
成员前缀
借口和实现
避免使用编码
命名
函数不该长于一屏
函数的缩进层次不该多于一层或两层
短小
判断函数是否只做了一件事的方法就是是否能再拆出一个函数
例如checkPassword() 中做了Session初始化，应修改为checkPasswordAndlnitializeSession()
如果是有副作用的函数，应在函数名中说明
只做一件事
向下规则
每个函数一个抽象层级
方便理解
方便测试
最理想的参数是零，其次是二，避免三或以上
参数
没有返回的参数
需要有入参和出参，形成链路
事件函数
避免传入boolean类型的参数
标志参数
if(set(\"username\
错误范例
if(attributeExists(\"username\")) { setAttribute(\"username\
正确范例
分隔指令和询问
当返回错误码时就是要求调用者立马处理错误
使用异常处理代替返回错误码
便于理解和修改
抽离try/catch代码块
如果某个函数中存在try关键字，它就应该是第一个单词，而且catch/finally代码块后面也不应该有其他的内容
错误处理就是一件事
异常使用
识别困难
代码臃肿，修改困难
重复会导致问题
抽出基类
面向切面编程
面向组件编程
消除重复的例子
别重复自己
函数
如果编程语言足够有表达力，我们就不需要注释，注释是在我们用代码表达意图失败时的弥补措施
注释存在的时间越久，就离其所描述的代码越远
程序员应当将注释保持在可维护、有关联和精确的高度
我们应该多花心思减少注释量
含义
注释不能美化糟糕的代码
用代码来代替注释进行阐述
法律信息
提供信息的注释
对意图的解释
警示
定期检测TODO，处理没有暂时没有进行处理的工作
删除不必要的TODO
TODO注释
公共API中的javadoc
好注释
如果只是因为你觉得应该或者因为过程需要就添加注释
喃喃自语
多余的注释
误导性注释
作者批判每个函数和每个变量都需要注释的规定
循规式注释
日志式注释
坏注释
嘿嘿
产生废话不可怕，可怕的是连废话都是错误的
废话注释
只有在特别有价值的时候采用。当标记栏不多，就会显而易见
位置标记
现在有版本控制，所以更加没必要写这种注释
归属与署名
如果代码不用直接删除掉
注释掉的代码
该方法并没有对8082端口进行控制，却写在该方法的注释中
非本地信息
信息过多
注释的作用就是解释代码，如果注释还需要注释来进行解释，就不是好注释
不明显关系
注释
应该选用一套管理代码格式的简单规则，然后贯彻这条规则
短文件通常比长文件更容易让人接受
使用空白行将不同的概念分割开
将关系紧密的代码放置在同一源文件中，防止读者在源文件中跳来跳去
变量的声明应尽可能靠近其使用的地方
调用者应该尽可能放在被调用者上面
相关函数
概念相关的一组函数应该放置在一起
垂直格式
大约80-120字符一行
加强分割效果
赋值符号左右添加空格
较高的优先级
乘法之间不用加空格
优先级较低
加减法之间添加空格
这样会显得强调不重要的东西
不建议对齐一组声明的变量名
一行代码也要进行缩进
就是是空范围｛｝也需要进行缩进
缩进
代码格式
每个人都有自己喜欢的格式规则，但是在团队中就以团队为准
横向格式
格式
这是一组表示坐标的数据，将x和y的赋值作为一组原子性的操作
不要乱加get和set
不暴露细节，以抽象形式表述数据
数据抽象
过程式代码便于添加新的函数
面向对象代码便于添加新类
链式编程是否违反了该定律？
直接ctxt.getAbsoulutePath()如何？
模块不应该了解它所操作对象的内部情形
德墨忒耳律
只有公共变量，没有函数
DTO(Data Transfer Objects)
数据传送对象
对象和数据结构
规范
异常处理是程序必须做的事情之一，但是如果因为它搞乱了代码逻辑让读者无法看明白代码所做的事情，就是错误的做法
该代码是单条件，不满足条件无程序执行，才适用于书中所说的修改方案
整理后的
使用异常而非错误码
当需要捕获多个第三方API的异常并进行不同的逻辑操作时，可以将处理异常的过程新建一个打包类，不仅代码更简洁，而且减少了对它的依赖
打包异常
创建一个类或配置一个对象，用来代替处理个别异常的行为。业务代码就不用进行异常处理了
特例模式
水哥的selectList()查询采用了该方式
用空的集合返回，减少多做空值检查判断
别返回null
别传递null值
错误处理（异常处理）
关于使用第三放库的建议，暂时不太理解
边界
测试驱动开发
在编写不同通过的单元测试前，不可编写生产代码
只可编写刚好无法通过的单元测试，不能编译也算不通过
只可编写刚好足以通过当前失败测试的生产代码
TDD三定律（待定）
好的全套自动化单元测试可以确保修改生产代码后的程序正确性
单元测试让你的代码可拓展、可维护、可复用
减少对修改代码的担忧，测试覆盖率越高，就越不担心修改
测试代码和生产代码一样重要
明确、简洁、有足够的表达力
每个测试一个概念、一个断言
快速Fast
独立Independent
可重复Repeatable
自足验证Self-Validating
及时Timely
规则FIRST
整洁的测试
例如字符串的拼接在测试中可以直接用+，而不用StringBuilder或StringBuffer，因为不用担心内存资源问题
测试与生产的双重标准
单元测试
类应该从一组变量列表开始，如果有公共静态常量，应该先出现，然后是私有静态变量，以及私有实体变量
类应该短小
类名越含糊，则说明该类的职责过多
类的名称应当描述其职责
单一权责原则SRP
类应当对拓展开放，对修改关闭
开放闭合原则OCP
类应当依赖于抽象而不是依赖于具体细节
依赖倒置原则DIP
内聚性高，意味着类中的方法和变量相互依赖、互相结合成一个逻辑整体
内聚
类
抽象工厂模式让应用自行控制何时创建对象，将构造的细节与应用程序代码隔离
将系统的构造与使用分开
依赖注入DI
控制反转IoC
由模块化的关注面领域组成
使用单一语言对象实现
侵害性架构会湮灭领域逻辑，冲击敏捷能力导致缺陷隐藏，生产力下降
不同领域之间不具侵害性
测试驱动系统架构
系统
系统的修改必须可测试、可验证
运行所有测试
额外的工作
额外的风险
额外的复杂度
不可重复
多花时间去尝试、去调整
表达了程序员的意图
应当避免教条式的去遵循规定，比它更重要的是测试、消除重复和表达力
尽可能减少类和方法的数量
迭进
并发是一种解耦策略，将目的和时机分解开，能明显的改进应用程序的吞吐量和结构
并发会在性能和编写额外代码上增加一些开销
正确的并发是复杂的，即便对于简单的问题也是如此
并发缺陷并非总能重现，所以常被看做偶然事件而忽略，未被当作真的缺陷看待
并发常常需要对设计策略的根本性修改
对于并发的一些说法
分离并发相关代码与其他代码
单一责权原则SRP
无法预期的行为采用synchronized保护使用共享对象的临界区
限制数据作用域
从多个线程收集所有复本的结果，并在单个线程中合并这些结果
使用数据复本
线程应尽可能独立
并发防御原则
java.util.concurrent包
并发环境中有着固定尺寸或数量的资源。例如数据库连接和固定尺寸读写等
限定资源
每一时刻仅有一个线程能访问共享数据或共享资源
互斥
一个或一组线程在很长时间内或永久被禁止。例如：总是让执行得快的线程先运行，假如执行得快的线程没完没了，则执行时间长的线程就会“饥饿”
线程饥饿
两个或多个线程互相等待执行结束。每个线程都拥有其他线程需要的资源，得不到其他线程拥有的资源，就无法终止
死锁
执行次序一直的线程，每个都想要起步，但发现其他线程已经在路上。由于竞步的原因，线程会持续尝试起步，但在长时间内却无法如愿，甚至永远无法启动
活锁
基础定义
一个或多个生产者线程创建某些工作，并置于缓存或队列中
一个或多个消费者线程从队列中获取并完成这些工作
生产者和消费者之间的队列是一种限定资源
生产者-消费者模型
一个共享资源，主要为读者线程提供信息源，偶尔被作者线程更新
读者-作者模型
宴席哲学家
执行模型
客户端在调用第一个方法前锁定服务器
基于客户端锁定
服务端内创建锁定服务端的方法，并调用所有方法
基于服务端锁定
创建执行锁定的中间层
适配服务端
避免使用一个共享对象的多个方法，如果必须则
保持同步区域微小
尽早考虑线程关闭问题
测试并不能确保正确性，但是能尽量降低风险
将偶发事件看作可能的线程问题
确保非线程代码可正常工作
编写可插拔的线程代码
编写可调整的线程代码
运行多于处理器数量的线程
在不同平台上运行
增加wait、sleep、yield等方法调用，改变代码执行顺序
硬编码
Aspect-Oriented Framework
CGLIB
ASM
自动化
装置试错代码
测试线程代码
应对并发
并发编程
本书从14章之前是对于整洁代码的思路与策略，以不重复原则为核心，衍生大量的规范编程。从14章开始作者用大量的代码进行示例逐步改造的过程，包含测试用例以及一些类库的重构。满满的干货，可以遵循着作者的代码将前面提出的概念很好的过一遍第17章为作者整理出清单式的建议，满满的干货，看这本书，完全可以先把第17章的内容精读一遍，立马可以运用到工作之中
小结
代码整洁之道
0 条评论
回复 删除
下一页
