在咖啡里溺水的鱼

阅读本文之前请确保你已与我达成共识。即，代码是一门讲规矩的艺术。前一段时间因为要参加一个有关重构的培训，匆匆读完了《CleanCode》一书，参加完培训后看到之前的读书笔记，发现又有了一番新的认识，因此在此加以总结。希望能够与愿意把代码当成一件艺术品去精心打磨的同学们一起来学习和研究如何把代码写的“优雅”。 简洁优秀的代码的好处不需更多的解说，但如何写出“优雅”的代码，还需要在个人的实践中仔细的体

并发并发的意义分离 做什么 与 何时做并发防御原则单一权责限制数据作用域使用数据副本线程应尽可能独立了解类库的线程安全性了解执行模型生产者-消费者读者-作者宴席哲学家警惕同步方法之间的依赖保持同步区域微小尽早考虑关闭问题编写线程测试代码将伪失败看做可能的线程问题先使非线程代码可工作编写可插拔的线程代码编写可调整的线程代码运行多于处理器数量的线程在不同平台上运行装置试错

系统将系统的构造与使用分开分解main使用工厂模式实现延迟加载依赖注入合理使用代理借助于AOP实现面向切面编程书中翻译为 面向方面，我认为还是 面向切面 更形象一些AspectJ是实现面向切面编程的有力工具测试驱动系统架构不认同迭进简单设计的几条规则运行所有测试重构不合适的设计不可重复提高代码表达力尽可能少的类和方法

类应该短小单一职责 SRP 类或模块应该有且只有一条加以修改的理由 即类应当只做一类事情内聚 类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。保持内聚就会得到许多短小的类使用接口与抽象类来隔离修改

边界作者的核心思想就是，使用 学习型测试代码，测试第三方类库的正确性的同时学习该类库的使用方法更多的操作技巧，则是使用适配器、代理等模式。单元测试作者推崇的TDD（测试驱动开发）我个人认为在WEB开发中使用较少，因此有关TDD的内容仅作记录，并不支持。TDD三定律在编写不能通过的单元测试前，不可编写生产代码只可编写刚好无法通过的单元测试，不能编译也算不通过只可编写刚好足以通过当前失败测试的生产

使用异常而非返回某种标识码先写try-catch-finally语句使用不可控异常 可控异常的代价是违反开放/闭合原则。如果在方法中抛出可控异常，而catch语句在多个层级之上，就得在catch语句和抛出异常处之前的每个方法签名中声明该异常。这意味着对软件中较底层的修改，都将波及较高层的签名给出异常发生的环境说明 记录日志自定义合适的异常定义常规流程 将业务逻辑与异常处理代码做出良好

对象和数据结构数据抽象使用合适的模型去抽象数据eg// badpublic class Point { public double x; public double y;}// goodpublic interface Point { private double x; private double y; private Point() {

团队规则大于一切无论你认为自己的规则有多么的优秀，团队的规则有多么的不符合你的口味。无论你是喜欢Google的编程规范还是阿里的编程规范，只要你的团队有着自己的规则，且大部分人都在按照团队的规则去执行，那么你也同样应该遵守。规则的作用在于统一，只要达到了这一目的规则的细节其实并没有那么的重要。所以记住，团队的规则大于一切。因此以下的规则，仅供参考垂直格式类最佳的垂直尺寸是200行以内。最大不应超过

来自CleanCode原书中的一句话，告诉了我们注释的核心原则。 别给糟糕的代码加注释——重新写吧注释不能美化糟糕的代码，能用代码说明的问题，就不要用注释来说明。 《CleanCode》这本书作为Java的必读书目之一，关于注释的这个观点却还是有许多人都不明白。甚至某些公司对于注释有着某些变态的格式要求，我真的是只能抱之以呵呵。如果看函数名就能明白函数的功能的话，那你再把函数名解释成中文写出

函数命名使用描述性的名称。 函数又称为方法，其目的是要完成一项功能。命名应该能够描述出这件事。大小要短小。肉眼可见的量化标准是： - 不长于一屏 - 缩进层级不高于2层功能要符合单一职责原则。面向对象SOLID原则之一。一个函数只做一件事情，没有副作用。分隔指令与询问。要么询问一件事，要么命令一件事。也是单一职责的一种体现每个函数中的内容保持在同一抽象层级错误的抽象层级：public

注释不恰当的注释废弃的注释冗余的注释糟糕的注释注释掉的代码环境需要多步才能实现的构建需要多步才能做到的测试函数过多的参数输出参数标识参数死函数一般性问题一个源文件中存在多种语言明显的行为未被实现(违反 最小惊异原则 The Principle of Least Surprise)不正确的边界行为忽视安全重复在错误的抽象层级上的代码基类依赖于派生类信息过多