最近在看这本书，记录一些思考和笔记

设计好一个软件的架构能够减少很多问题，很多时候规范是杜绝你的代码成为屎山的关键，这也就是为什么要有 codereview 的原因。在写代码前先思考，需要考虑其架构、可维护性、拓展性等。

1.命名其实很重要，曾经我在一次面试中被问到“你们写代码的时候有没有写注释”，我立马回答说：写！，接着面试官又问“你觉得一份好的代码需不需要写注释？”，我觉得当然是需要这样无论是排查问题还是交由后面的人维护都是有好处的，谁知后面面试官的回答让我恍然领悟。面试官说：“我觉得一份好的代码是可以没有注释的，从方法、变量的命名就可以知道其功能是什么，代码即文档”。

变量名、方法名、包名、类名、模块名的命名都要能提醒出其各自的作用，提高其简洁度。

在 Java 中，我们通常使用如下命名约定。

• 类名采用“大驼峰”形式，即首字母大写的驼峰，例如 Object、 StringBuffer、FileInputStream。

• 方法名采用“小驼峰”形式，即首字母小写的驼峰，方法名一般为动 词，与参数组成动宾结构，例如 Thread 的 sleep(long millis)、 StringBuffer 的 append(String str)。

• 常量命名的字母全部大写，单词之间用下划线连接，例如 TOTAL_COUNT、PAGE_SIZE 等。

• 枚举类以 Enum 或 Type 结尾，枚举类成员名称需要全大写，单词间 用下划线连接，例如 SexEnum.MALE、SexEnum.FEMALE。

• 抽象类名使用 Abstract 开头；

• 异常类使用 Exception 结尾；实现类以 impl 结尾；

• 测试类以它要测试的类名开始，以 Test 结尾。

• 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单 词，包名统一使用单数形式。通常以 com 或 org 开头，加上公司名， 再加上组件或者功能模块名，例如 org.springframework.beans。

  更多参考阿里代码规范手册

  2.注释需要有效注释，注释是为了代码表达能力失败而存在的。

1.混乱是有代价的，我们必须通过一些规范来进行约束。包括缩进、水平对齐、注释格式等

2.日志规范。往往生产中出现的问题排查都需要通过日志来快速定位，遵循日志规范能减少我们排查问题的时间

3.异常规范。制定不同模块的异常码

4.架构规范。分层、业务划分、模块化思想、包的划分等

5.防止破窗效应，不要做“打破第一扇窗”的人；其次，发现有“破窗”，要及时地修复，不要让事情进一步恶化。

可以通过一些代码 review 插件进行扫描，如果存在问题及时反馈

1.指责单一，遵循 SRP 不仅可以提升代码的可读性，还能提升代码的可复用性。 因为职责越单一，功能越内聚，就越有可能被复用，这和代码的行数没 有直接的关联性，但是有间接的关联性。

2.使用 Optional 类取代又臭又长的 null 判断

3.抽象层次一致性（Single Level of Abstration Principle，SLAP），是 和组合函数密切相关的一个原则。组合函数要求将一个大函数拆成多个 子函数的组合，而 SLAP 要求函数体中的内容必须在同一个抽象层次 上。如果高层次抽象和底层细节杂糅在一起，就会显得凌乱，难以理 解。

4.函数式编程和面向对象编程并没有本质上的区别。在函数式编程 中，函数不仅可以调用函数，也可以作为参数被其他函数调用。从这个 角度看，对象在作为值被传递时，也是对业务逻辑的封装，只不过它不 仅包含函数，还包含属性。

减少冗余代码，让代码更简洁、可读性更好。
函数是“无副作用”的，即没有对共享的可变数据操作，可以利用多 核并行处理，而不用担心线程安全问题。

4.设计原则

在软件设计领域中，有很多这样的原则，遵从这些设计原则可以有 效地指导我们设计出更灵活、易于扩展和维护的软件系统。需要注意的 是，和其他道理一样，原则并非是形而上学的静态客观真理，不是说每 一个设计都要教条地遵守每一个原则，而是要根据具体情况进行权衡和 取舍。

SOLID 是 5 个设计原则开头字母的缩写，其本身就有“稳定的”的意 思，寓意是“遵从 SOLID 原则可以建立稳定、灵活、健壮的系统”。5 个 原则分别如下。

• Single Responsibility Principle（SRP）：单一职责原则。
• Open Close Principle（OCP）：开闭原则。
• Liskov Substitution Principle（LSP）：里氏替换原则。
• Interface Segregation Principle（ISP）：接口隔离原则。
• Dependency Inversion Principle（DIP）：依赖倒置原则。

Single Responsibility Principle（SRP）单一职责原则

任何一个软件模块中，应该有且只有一个被修改的原因。

SRP 要求每个软件模块职责要单一，衡量标准是模块是否只有一个被修改的原因。职责越单一，被修改的原因就越少，模块的内聚性（Cohesion）就越高，被复用的可能性就越大，也更容易被理解。

案例
可以看到 Rectangle 类有两个方法，draw 负责绘制到屏幕，area 负责求出面积。其类具有至少两个职责，不管是改变绘制逻辑，还是面积计算逻辑，都要改动 Rectangle 类。
为了遵从 SRP 原则，我们需要把两个职责分离出来，放在两个不同的类中，这样就可以互相不影响了。最简单的解决方案是将数据与函数分离。设计两个用来做逻辑处理的类，每个类只包含与之相关的函数代码，互相不可见，这样就不存在互相依赖的情况了。
上面的方式有点“贫血”模式的味道。我们也可以采用面向对象的做法，把重要的业务逻辑与数据放在一起，然后用 Rectangle 类来调用其他没那么重要的函数。

Open Close Principle（OCP）开闭原则。

Liskov Substitution Principle（LSP）里氏替换原则。

Interface Segregation Principle（ISP）接口隔离原则。

Dependency Inversion Principle（DIP）依赖倒置原则。

代码精进之路-从码农到工匠.pdf