《代码整洁之道》
文章平均质量分 59
代码风格基础
帅气呢杰哥
每周写一篇博客。
展开
-
18并发编程 II
文章目录客户端 / 服务器的例子服务器添加线程代码观察服务器端执行的可能路径路径数量深入挖掘了解类库Executor 框架非锁定的解决方案非线程安全类方法之间的依赖可能破坏并发代码容忍错误基于客户代码的锁定基于服务端的锁定提升吞吐量单线程条件下的吞吐量多线程条件下的吞吐量死锁互斥上锁及等待无抢先机制循环等待不互斥不上锁及等待满足抢先机制不做循环等待测试多线程代码测试线程代码的工具支持完整代码范例不使用线程的 客户端 / 服务器 代码使用线程的 客户端 / 服务器 代码todo客户端 / 服务器的例子服原创 2021-04-05 22:09:02 · 71 阅读 · 1 评论 -
17 味道与启发
文章目录注释环境函数一般性问题Java名称测试注释环境函数一般性问题Java名称测试原创 2021-04-05 22:03:42 · 153 阅读 · 0 评论 -
14-15-16 JUnit内幕 重构SerialDate
文章目录15 Junit 内幕16 重构 SerialDate15 Junit 内幕16 重构 SerialDate原创 2021-04-05 22:02:31 · 240 阅读 · 0 评论 -
13 并发编程
todo 平时并发用的少 等系统学完并发使用 再回头补充这节为什么要并发挑战并发防御原则单一权责原则限制数据作用域使用数据复本线程应尽可能地独立了解 Java 库了解执行模型生产者—消费者模型读者—作者模型宴席哲学家警惕同步方法之间的依赖保持同步区域微小很难编写正确的关闭代码测试线程代码将伪失败看作可能的线程问题先使非线程代码可工作编写可插拔的线程代码编写可调整的线程代码运行多于处理器数量的线程在不同平台上运行装置试错代码硬编码自动化...原创 2021-04-05 21:56:19 · 55 阅读 · 0 评论 -
12 迭进
文章目录通过迭进设计达到整洁目的简单设计规则 1:运行所有测试简单设计规则 2~4:重构不可重复表达力能够编写整洁代码的人 一定精通并擅长使用设计模式!换句话说如果你连设计模式都不能熟谙 就休要声称自己有代码洁癖 能写出真正整洁代码通过迭进设计达到整洁目的简单设计的四条规则运行所有测试不可重复表达了程序员的意图尽可能减少类和方法的数量以上规则按其重要程度排列简单设计规则 1:运行所有测试编写测试引致更好的设计遵循 SRP 保持类短小且目的单一 高内聚遵循 DIP 使用依赖注入原创 2021-04-05 21:49:54 · 255 阅读 · 0 评论 -
11 系统
文章目录如何建造一个城市将系统的构造与使用分开扩容三种切面机制Java代理纯 Java AOP 框架AspectJ 的方面测试驱动系统架构优化决策如何建造一个城市分工清晰明确 全局&细节—— 角色:老师 医生 程序员 …恰当的抽象层级模块 ——管理: 老板 领导 下属 …关注面切分 —— 全局性适用功能:每个人都要有身份证 社保卡将系统的构造与使用分开构造与使用分开的方法分解main 将全部构造过程搬迁到 main依赖注入 控制反转 DI容器 工厂解耦了构造细节扩容横贯式原创 2021-04-05 20:40:41 · 308 阅读 · 1 评论 -
10 类
文章目录类应该短小单一权责原则低耦合 高内聚保持内聚性就会得到许多短小的类为了修改而组织感觉到这一级就开始更加涉及到设计模式相关的思想了类应该短小如果无法为某个类命以精确的名称 这个类大概就太长了单一权责原则单一权责原则:类或模块应有且只有一个修改的原因低耦合 高内聚内聚性高 意味着类中的方法和变量互相依赖 互相结合成一个逻辑整体保持内聚性就会得到许多短小的类采用更有描述性的变量名 将函数 类 变量的声明当作是给代码添加注释的一种手段为了修改而组织具体类包含实现细节 抽象类呈现概念 依原创 2021-04-05 19:26:59 · 91 阅读 · 0 评论 -
9 单元测试
文章目录TDD 三定律保持测试整洁整洁的测试每个测试一个断言F.I.R.S.TTDD 三定律定律一 在编写不能通过的单元测试前 不可编写生产代码定律二 只可编写刚好无法通过的单元测试 —— 测试临界定律三 只可编写刚好足以通过当前测试的生产代码测试与生产代码一起编写 测试只比生产代码早写几秒钟保持测试整洁命名短小具有描述性设计良好仔细划分脏测试 = 没测试 测试不能保持整洁 你就会失去它们因为测试必须随着生产代码的演进而修改 脏测试导致测试成为不断翻番的债务 不断恶性循环原创 2021-04-05 10:57:01 · 187 阅读 · 0 评论 -
8 边界
文章目录使用第三方代码浏览和学习边界学习 log4j学习性测试的好处不只是免费使用尚不存在的代码整洁的边界使用第三方代码浏览和学习边界学习 log4j学习性测试的好处不只是免费使用尚不存在的代码整洁的边界...原创 2021-04-05 00:21:14 · 88 阅读 · 0 评论 -
7 错误处理
文章目录使用异常而非返回码先写 try-catch-finally 语句使用不可控异常给出异常发生的环境说明依调用者需要定义异常类定义常规流程别返回 null 值别传递 null 值编写既整洁又强大的代码——雅致地处理错误代码的一些技巧和思路使用异常而非返回码使用返回码的问题搞乱了调用者的代码调用者必须在调用之后即刻检查错误 并且这个步骤很容易被遗忘解决方式:抛异常 调用代码很整洁 其逻辑不会被错误处理搞乱先写 try-catch-finally 语句没看懂 不好意思使用不可控异常可原创 2021-04-05 00:18:35 · 107 阅读 · 0 评论 -
6 对象和数据结构
文章目录数据抽象数据结构与对象的反对称性得墨忒耳律 Demeter's law隐藏结构数据抽象// 具象点:暴露实现public class Point { public double x; public double y;}// 抽象点:隐藏实现public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double ge原创 2021-04-04 23:08:22 · 121 阅读 · 0 评论 -
5 格式
文章目录格式目的垂直格式向报纸学习垂直区隔垂直靠近垂直距离垂直顺序水平格式水平区隔与靠近缩进团队规则格式目的关乎沟通 沟通是专业开发者的头等大事可读性代码风格和律条的深远影响影响到可维护性 扩展性垂直格式向报纸学习顶部有头条 —— 源文件名应该一目了然 足够告诉我们是否在正确的模块中第一段是大纲 给出粗线条概述 但隐藏了细节 —— 源文件最顶部应该给出高层次的概念和算法接着读下去 细节渐次增加 —— 源文件后面是越来越底层的函数和细节多数短小精悍 —— 要拆分函数 每个函数只做一原创 2021-04-04 17:10:37 · 222 阅读 · 0 评论 -
4 注释
文章目录注释不能美化糟糕的代码让代码来阐述好注释法律信息提供信息注释意图声明注释阐释警示todo注释放大公共 API 中的 JavaDoc复杂算法坏注释多余注释误导注释循规式注释日志式注释废话注释能用函数或变量就别用注释位置标记括号后面的注释归属与署名注释掉的代码非公共代码中的 JavaDoc别给糟糕的代码加注释——重新写吧若编程语言足够有表达力 或者长于用这些语言来表达意图 就不那么需要注释注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败程序员并不能坚持维护注解 代码在变化 在演化 注释并不总原创 2021-04-04 16:41:11 · 409 阅读 · 2 评论 -
3 函数
文章目录短小只专心做一件事每个函数一个抽象层级swith使用描述性名称函数参数一元函数标识函数二元函数三元函数参数对象参数列表动词与关键字无副作用分隔查询与操作使用异常代替返回错误码抽离 try-catch 代码块错误处理就是一件事Error.java 依赖磁铁别重复自己结构化编程如何写出这样的函数短小函数第一规则 要短小函数第一规则 还要更短小通常要小于 10 行if | else | while 语句,其中的代码块应该只有一行 这行大抵应该是个函数调用语句不但能保持短小函数名较具有说明性原创 2021-04-04 00:28:42 · 135 阅读 · 0 评论 -
2 命名
文章目录名副其实避免误导做有意义区分使用可读名称使用可搜索名称避免使用编码避免思维映射类名方法名每个抽象概念对应一个词别用双关使用解决方案领域名称使用问题领域名称添加有意义语境不要添加没用语境名副其实如果名称需要注释来补充 那就不算是名副其实避免误导避免留下掩藏代码本意的错误线索hp hypotenuse(斜边) & linux 专有名称【还有 aix sco】accountList 如果不是列表类型 => accountGroup | bunchOfAccounts | acc原创 2021-04-03 23:09:02 · 314 阅读 · 0 评论 -
1 整洁代码
文章目录要有代码糟糕的代码混乱的代价华丽新设计态度谜题整洁代码的艺术什么是整洁代码?思想流派我们是作者童子军军规前传与原则为什么要阅读本书?你是个程序员你想成为更好的程序员要有代码**代码永存!**我们永远抛不掉代码 因为代码呈现了需求的细节。某些层面上 这些细节无法被忽略或抽象 必须明确之将需求明确到机器可以执行的细节程度 就是编程要做的事糟糕的代码糟糕的代码足以毁了公司稍后等于永不混乱的代价混乱增加 — 团队生产力下降 — 增加人手 — 新人不熟悉系统设计,什么修改符合设计意图原创 2021-04-03 22:18:01 · 85 阅读 · 2 评论 -
0 前言
文章目录内容提要序代码猴子与童子军军规内容提要软件质量的决定因素架构项目管理代码质量整洁度序软件开发 80% 以上的工作量集中在修补上写出可读的代码重要程度不亚于写出可执行代码用为自己孩子命名般谨慎给变量命名签入代码前是否已做重构代码猴子与童子军军规离开时要比发现时更整洁...原创 2021-04-03 21:20:12 · 64 阅读 · 0 评论