《代码整洁之道》第二部分：需要反复练习的案例研究
2023-02-04 22:00:57 9 举报AI智能生成
《代码整洁之道》第二部分内容的整理
作者其他创作
大纲/内容
第10章 类
尽管讨论了这么多关于代码语句及由代码语言形成的函数的表达力，
但是，除非我们将注意力放到代码组织的更高层面，否则始终不能得到整洁的代码
但是，除非我们将注意力放到代码组织的更高层面，否则始终不能得到整洁的代码
类的组织
代码应该符合自上向下的原则，让程序读起来像一篇报纸文章
封装：尽可能的保持函数或变量的隐私；放松封装是下策
类应该短小
关于类的第一条规则时类应该短小，第二条规则是还要更短小
类只应有一个权责
类的名称应当描述其权责，类名越含糊，该类越有坑拥有过多的权责
系统应该由许多短小的类而不是少量巨大的类组成
类应该只有少数实体变量
隔离依赖
需求会改变，所以代码也会改变
依赖具体细节的类，当细节改变时就会有风险，可以借助接口和抽象类来改立这些细节带来的影响
依赖倒置原则
类应当依赖抽象而不是依赖具体细节
第11章 系统
复杂要人命，它消磨开发者的生命，让产品难以规划、构建和测试
将系统的构造和使用分开
抽象工厂模式
依赖注入
扩容
我们不能一开始就在小镇里修建一条六车道的公路
合理的利用资源，而不是浪费
优化决策
延迟决策至最后一刻也是好手段，这不是懒惰或不负责，而是让我们能够基于最有可能的信息做出选择
系统也应该是整洁的，侵害性架构会湮灭领域逻辑，冲击敏捷能力
最好的方案：大概可开展工作的最简单方案
第12章 迭代
Kent Beck 简单设计的4条规则
运行所有测试
不可测试的系统，同样是不可验证的；不可验证的系统，绝不应部署
测试编写得越多，就越能持续走向编写较易测试的代码
测试消除了对清理代码就会破坏代码的恐惧
不可重复
重复
极其雷同的代码
实现上的重复
作用上的重复
想要实现大规模复用，必须理解如何实现小规模复用
表达了程序员的意图
软件项目的成本主要在于长期维护
代码写的越清晰，其他人花在理解代码上的时间越少
做到有表达力的总重要的方式是 尝试
用心是最珍贵的资源
尽可能减少类和方法的数量
第13章 并发编程
并发是一种解耦策略
常见迷思和误解
并发总能改进性能
编写并发程序无序修改设计
采用Web时，理解并发问题并不重要
并发防御原则
单一职责
限制数据作用域
使用数据副本
线程应尽可能地独立
熟悉现有语言中的高并发的类库
了解执行模型
基本定义
限定资源
互斥
线程饥饿
死锁
活锁
生产者-消费者模型
读者-作者模型
宴席哲学家
警惕同步方法之间的依赖
保持同步区域微小
尽早考虑关闭问题
测试线程代码
第14章 逐步改进
要编写整洁代码，必须先写肮脏代码，然后再清理它
混乱是逐渐产生的
毁掉程序的最好方法之一就是以改进为名大动其结构
重构有点儿像解魔方，需要经过许多小步骤，才能达到较大目标，每一步都是下一步的基础
优秀的软件设计，大都关乎分割————创建合适的空间放置不同种类的代码。对关注面的分割让代码更易于理解和维护
保持代码整洁的方法是相对容易：早晨在模块中制造出一堆混乱，下午就能轻易清理掉
更好的情况是：5分钟之前制造出混乱，马上就能很容易地清理掉
第15章 JUnit内幕
遵循童子军军规，每个人都有责任把模块改进得比发现它时更整洁
第16章 重构 SerialDate
首先，让它能工作
让它做对
第17章 味道与启发
注释
不恰当的信息
废弃的注释
冗余注释
糟糕的注释
注释掉的代码
环境
需要多步才能实现的构建
需要多步才能做到的测试
函数
过多的参数
输出参数
标识参数
死函数
一般性问题
一个源文件中存在多种语言
明显的行为未被实现
不正确的边界行为
忽略安全
重复
在错误的抽象层级上的代码
基类依赖派生类
信息过多
死代码
垂直分隔
前后不一致
混淆视听
人为耦合
特性依恋
选择算子参数
晦涩的意图
位置错误的权责
不恰当的静态方法
函数方法应该表达其行为
理解算法
把逻辑依赖改为物理依赖
使用多态代替 if/Else 或 Switch/Case
遵循行业标准
使用命名常量替代魔术数
准确
结构基于约定
封装条件
避免否定性条件
函数只做一件事
掩蔽时序耦合
别随意
封装边界条件
函数应该只在一个抽象层级上
在较高层级放置可配置数据
避免传递浏览
Java
通过使用通配符避免过长的导入清单
不要继承常量
名称
采用描述性名称
名称应于抽象层级相符合
尽可能使用标准命名法
无歧义的名称
为较大作用范围选用较长名称
避免编码
名称应该说明副作用
测试
测试不足
使用覆盖率工具
别略过小测试
被忽略的测试就是对不确定事物的疑问
测试边界条件
全面测试相近的缺陷
测试失败的模式有启发性
测试覆盖率的模式有启发性
测试应该快速
0 条评论
下一页
