总结的口诀

• 大虫虫是魔鬼
  -大类，大函数，大参数列表；重复代码，重复造轮子；魔鬼数字硬编码，常量应该统一定义，集中管理，便于理解和统一替换。
• 小虫抽风
• 一个小钦差
• 大重重是魔鬼
• 长虫发现数据链
  -长类，长函数，长参数列表; 发散式变化，散弹式修改；switch惊悚现身，基本类型偏执；数据泥团，幼稚的数据类；过度耦合的消息链，依恋情节。
• 好莱坞的迪米特喜欢组合而不是继承

小技巧

• 将业务代码和非业务代码（操作日志，错误处理）分离

• 异常代替错误码

• 代码的组织逻辑，相关相似的代码放在一起，变量定义靠近第一次使用的地方

• 常量应该统一定义，集中管理; 避免魔鬼数字和硬编码。

• 拒绝重复代码， 使用优秀开源方法，不要重复造轮子

• 函数要短小优美，大函数提取函数，大类

• 尽可能使用枚举

• 针对接口编程，而不是实现编程。成员变量，参数，返回值，局部变量，尽量定义为接口。

• 定义类和方法时，优先使用泛型，通配符

• 容器类设置容量

• 优先返回空集合，空对象，而不是null。

• 懒加载，需要时再创建，对象的创建要紧挨着变量的使用，避免创建无用的对象

• 不要使用参数做临时变量

• 变量的参数不要太多，嵌套不要太深

• 数据库往返次数，使用批量操作代替循环操作

• 卫语句

设计原则

• SOLID
• 依赖倒置
  客户拥有抽象接口，它的服务者从这些抽象接口中派生，底层模块实现了在高层模块声明并被高层模块调用的接口
• 好莱坞原则

1. 你不要找我，我会找你 。 高层组件对待底层组件的方式：别调用我们，我们会调用你
2. 应用场景：观察者模式,以通知替代轮询

• 工厂模式
  Ioc依赖注入,DI控制反转设计的基础，所有组件都是被动的，初始化和调用都由容器负责

代码的坏味道

1. Duplicated Code(重复的代码)
   将重复的代码提取成为函数，分别调用

2. Long Method(过长方法)
   细化步骤，分解成小函数

3. Large Class(过大类)
   细化类的职责，分解成职责单一的类

4. Long Parameter List(过长参数列)
   将不属于一个对象但有细微联系的数据提成一个对象，然后将这些属于一个对象的数据以对象当参数

5. Divergent Change(发散式变化)
   细化类的职责，分解成职责单一的类

6. Shotgun Surgery(霰弹式修改)
   将发生变的函数和字段提取到一个类或者新类当中

7. Feature Envy(依恋情结)
   拆分函数，将过多引用其它类的变量的函数移过去

8. Data Clumps(数据泥团)
   将这些常一起出现的数据提取到一个类当中

9. Primitive Obsession(基本类型偏执)
   将应该被放在一起的基本类型字段用对象代替

10. Switch Statements(switch惊悚现身)
    利用面向对象的多态性和状态、策略等设计模式来处理

好的习惯

1. bean职责要单一

2. 类名显示出类型，helper business bean

3. 不可将主流程与辅助流程混合在一起

抽象与接口

1. 从抽象类和接口语义来看：
   抽象类表示的是一种A是B的关系
   接口表示的是一种A有B的行为的关系

2. 从实践的角度来看，使用抽象类或者接口，我们可以考虑几个问题：
   优先使用接口，因为接口是一种完全的抽象且接口允许多实现
   你抽象出来的核心模块中，有没有实例字段？
   你抽象出来的核心模块中，需不需要普通方法？
   你抽象出来的核心模块中，需不需要构造函数进行必要的传参？

设计模式

1. 模板模式简单说就是代码设计人员定义好整个代码处理流程，将变化的地方抽象出来，交给子类去实现。有两个难点：
   （1）主流程必须定义得足够宽松，保证子类有足够的空间去扩展
   （2）主流程必须定义得足够严谨，保证抽离出来的部分都是关键的部分

2. 代理模式
   功能上讲：
   被代理对象功能没有变化，还是那个功能；装饰器模式，被装饰对象的功能是增强了的
   从语义的角度来说：
   装饰器模式强调的是给对象增加功能
   代理模式强调的是控制对象的访问

抽象、封装变化

• 找出易变化的部分，合理抽象。
• 用抽象构建框架、用实现扩展细节
• 面向接口编程的思想：

1. 在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
2. 好处：可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
3. 实际编程中，最好做到如下3点：
   低层模块尽量都要有抽象类或接口，或者两者都有。
   变量的声明类型尽量是抽象类或接口。
   使用继承时遵循里氏替换原则
   如果依赖的是一个稳定的具体类，那么可以直接依赖它

• 编程的关键根本就不是编程语言，而在于背后的思想，能不能分层，抽象，分而治之，能不能把变化的部分和不变的部分给隔离开，能不能让各个功能独立地变化和扩展， 需认真学习，积极思考，多加实践

代码的可读性

1. 代码的可读性，可维护性。可读的代码可维护性高。代码的模块化有助于提高代码的可维护性，高内聚低耦合的代码可维护性高

2. 函数的作用:实现代码的复用;实现代码的模块化，提高可读性，可维护性;实现对代码的封装和抽象，隐藏实现细节，暴露业务接口

3. 整个流程中的抽象是在同一个层次上的，比较清晰易于理解

4. 架构的本质是管理复杂性，抽象、分层、分治和演化思维是工程师 / 架构师应对和管理复杂性的四种最基本武器。

重构代码

• 一个小钦差

• 一：单一职责，只做一件事儿，做好这件事儿；同一抽象层次；要么做什么，要么回答什么；只有一个导致变化的原因。

• 拆，将不同语义的功能拆分到不同的类中，单一职责。将变量，方法置于哪个类中，将变量方法拆分到哪个类中。语法，语义，意图，功能

常用设计模式

• 工厂模式，静态工厂，简单工厂，抽象工厂。

• 构建器模式

• 单例模式

• 策略模式

• 模板方法

• 观察者模式

• 特殊对象模式

• 中介者模式

• 生产者～消费者模式

反模式

• 上帝类，一个类集齐所有功能。

• 黄金大锤，只有一把锤子，看到什么都是钉子。

通用原则

• 不要重复自己，消除重复

• 封装，信息隐藏，过度封装会导致客户端调用的灵活性降低，需要平衡封装的程度。token是外部传入还是内部生成，sql语句是内部生成还是外部传入

• 使用函数，最好是小函数

• 相关的代码放在一起

• 日志最好集中打印

• 小虫抽风

面向接口编程

面向接口编程，『接口』在面向对象的设计中，是属于抽象层面的东西，那什么时候需要抽象呢？一定是两种及以上事物拥有共同的一些特征时，才能形成抽象（自底向上），或者从高层定义一些抽象特征，由两种或以上事物来体现这个特州，这种抽象才有意义（自顶向下）。

最佳实践

异常代替错误码

变量的定义靠近第一次使用的地方，流程要流畅

代码可读性，依靠的是代码语义、意图；不知道POJO的意义，以及语义化的涵义；只是感觉Map，String好灵活好喜欢。

尽管方法都短小简洁，但是代码的可读性依然不强，分析后发现是由于代码分层不清晰导致的。编码时，喜欢将需要的方法都写到一个类中，导致类混杂了很多功能，掺杂了不同的语义。应该通过抽象与分层将不同语义的功能，抽离到不同的类中。

消除重复

写好注释

语法与语义要保持一致，代码与功能要保持一致

类和方法的设计优先考虑泛型

契约式设计，防御式编程有利于编写安全可靠的代码，入参的合法性检验，与处理前的净化

站在客户的角度，审视自己的接口设计。自己设计的类对他人的影响，他人是否按照你的预想使用你的类。每个类既是服务的提供者，也是服务的享受者。

将相关的数据项绑定到一个类中，便于统一管理，如复制，创建，传参数，比较。rest，ftp，email

代码的位置，代码应该在哪个类中；代码的顺序，变量应该定义在靠近使用的地方，语句的顺序调整

将多个方法的变量设置为成员变量，避免方法间传来传去。

变量和类名的命名，命名要准确，多加限定词

精确的动词

• 简单的返回数据/内存中获取，getFullName

• 从远程获取/其他微服务，query

Clean Code（整洁代码）相关推荐

1. 《Clean Code》代码的整洁之道（一）

   <代码整洁之道>:细节之中自有天地,整洁成就卓越代码 概述 软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发流派还是传统开发流派,都不得不承认.<代 ...

2. Clean Code 《代码整洁之道》前四章读书笔记

   第一章: 整洁的代码只做好一件事 减少重复代码 提高表达力 提早构建简单抽象 让营地比你来时更干净 第二章:有意义的命名 名副其实:如果名称需要注释来补充,就不算是名副其实. 一定要注意命名,一旦发现 ...

3. clean code（代码整洁之道）

   一.有意义的命名 示例1 示例2 示例3 示例4 图一 图二 图三 示例5 示例6 示例7 示例8 二.函数 1.尽可能短小 2.只做一件事 如果对你写的某个方法的代码进行审查时 发现他做了多件事 这 ...

4. 《代码整洁之道》（Clean Code）- 读书笔记

   一.关于Bob大叔的Clean Code <代码整洁之道>主要讲述了一系列行之有效的整洁代码操作实践.软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发流派 ...

5. 代码整洁之道（Clean Code）- 读书笔记

   Sorry, 许久未更新文章了,主要因为刚刚换了一家新公司,忙于组建团队(建设.招聘.流程.框架等)与熟悉公司业务,还有领导给的其他工作等等,实在是没有时间更新了.最近在和团队分享Bob大叔的< ...

6. 代码整洁之道(clean code)序

   代码整洁之道(clean code)序 为什么要写出一手整洁的代码 我可以说是对自己coding水平要求比较高的那种类型,不是说代码能跑起来就ok了,总是希望自己的代码就像诗一样的优美,让人读起来赏心 ...

7. 代码整洁之道 Clean Code 读书笔记

   目录 代码整洁之道 Clean Code 第一章 整洁代码 第二 三章 命名与函数 第四 五章注释与格式 第六章 对象和数据结构 第七章 错误处理 第八章 边界 第九章 单元测试 第十章 类 第十一章 ...

8. 《代码整洁之道 clean code》 读书笔记（上篇）

   <代码整洁之道 clean code> 读书笔记(上篇) 这本书我准备用较快的时间来读一下,简单记录一下自己的一些读完的感悟,因为更多地编码技巧还是需要在实际编程和读源码的过程中进行锤炼. ...

9. Clean Code 代码整洁之道笔记（1-8 章）

   Clean Code Chapter 1-8 第一章 整洁代码 1. 为什么需要代码? 2. 混乱的代码 3. 什么是整洁代码 第二章 有意义的命名 1. 名副其实 2. 避免误导 3. 做有意义的区 ...

10. 2015年第11本：代码整洁之道Clean Code

    前一段时间一直在看英文小说,在读到<Before I fall>这本书时,读了40%多实在看不下去了,受不了美国人啰啰嗦嗦的写作风格,还是读IT专业书吧. 从5月9日开始看<代码整洁 ...

最新文章

1. 浅谈pytorch 模型 .pt, .pth, .pkl的区别及模型保存方式 pth中的路径加载使用
2. mysql查看和启用二进制日志
3. python自动化第三周---文件读写
4. 使用OpenJDK 11运行JAXB xjc编译器
5. windows等宽字体
6. 计算机仿真在电力领域的应用,仿真技术在电力系统中的应用实例
7. 软考系统架构师笔记-综合知识重点（二）
8. (转)Android属性动画完全解析(中)，ValueAnimator和ObjectAnimator的高级用法
9. TensorFlow教程之API DOC 6.1.4 Class tensorflow::Session
10. JS判断手机端是否安装某应用
11. 捷联惯导更新算法及误差分析汇总
12. 从《征途》看互联网盈利模式的设计
13. [白话解析] Flink的Watermark机制
14. 学计算机用书包吗,起底大学生活 | 书包物品大揭秘
15. google android 市场份额,谷歌公布安卓系统市场占有率份额 碎片化依然严重
16. JavaWeb商城项目笔记--- Day1 （热门商品，热销商品）
17. pyhon使用CDS API抓取哥白尼气候数据（详细步骤）
18. 全国OSTA计算机高新技术SQLSever数据库四级证书--考证复习知识点集合（附下载地址）
19. go语言ORM框架ent使用教程
20. Flink实战之实时风控规则引擎

热门文章

1. 2022-2027年中国海洋功能性食品行业发展监测及投资战略研究报告
2. Linux上vim编辑器使用教程
3. Java Overview
4. 奇点临近：人工智能让人类变成软件，并迅速统治宇宙
5. web项目高并发量网站解决方案
6. 上海市大数据技术与应用创新中心成立
7. 毕业设计-基于微信小程序的校园二手闲置物品交易系统
8. 普源DG1022U信号发生器技术参数
9. 角色控制器wasd移动
10. 云栖大会倒计时，17个精彩的故事与你一起等待！