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