本次分享的内容是《代码整洁之道》，书中是以现实案例，以讲故事形式来总结归纳问题，并给出解决方案，很容易与我们产生共鸣。文中会有大量书中内容摘抄，都是个人认为很值得分享的内容。当然，也会有个人感悟，作为学习记录及简单分享。
翻开书，前言章节，映入眼帘的就是下面这一张图
代码质量的唯一有效度量是：WTFs（what the fuck）/minute
真的太精辟了，不管哪个项目，代码都避免不了存在 bad code的情况了，我们应该怎么面对这种情况呢？
每个项目组的规范还不一样，本文是读书笔记，不会说明太多的代码规范，只是阐明我们应该怎样做或者抱着什么样的心态来写代码吧
如果你看到这里，我要引用书中的一句话：
第一，你是个程序员；第二；你想成为更好的程序员。我们需要更好的程序员
代码整洁有什么用？
思路清晰，降低bug几率
更容易维护，利于团队协作
看起来舒服，提高效率
......
引用作者一句话
软件质量与代码整洁度成正比 --Robert.C.Martin(作者)
软件设计3R层次结构： readable, reusable, and refactorable 可读性、可重用性、可重构性
这些原则是作者提出的一些最佳实践，但不是强制约束
我们应该如何保持代码的整洁？
破窗理论：环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉
为了我们代码的整洁，我们需要为他花费一定的时间来进行优化。
整洁的代码就是作者着力照料的代码。有人曾花时间让它保持简单有序。他们适当的关注到了细节，他们在意过。
一般来说，除了linter等用于规范代码格式的工具之外，还有一些需要自己进行关注的方面：
代码逻辑直接了当
减少依赖便于维护
根据分层战略完善错误处理
单元测试覆盖全面
有意义的命名（做到名副其实）
提供一种而非多种做某件事的途径（没有重复代码）
专业的态度
做项目/产品，通常都是指明deadline的，但是截止到deadline之前，需求量的多少是不固定的，说白了是“以deadline不变应需求万变”，美其名曰「敏捷」
我们经常要面对短期内开发出大量需求的请求，很可能为了快速完成这些需求，胡乱的堆叠代码，上线之后一声长叹庆幸这个功能开发的结束。过了好久，有关这个功能的需求有所变化，重新查看代码时，直接就 WTF 了......，再一看是自己写的，你说尴尬不？
如果是因为任务多胡乱叠加代码，我们就应该在接受需求的时候提出我们的看法：
过多的需求在短期内上线的代码质量不能得到保证
编程是工艺
这就是《代码整洁之道》的中心思想。贯穿全书的要点是：软件是一门艺术，做软件就像“画画”。作者认为编程的本质是一门工艺。
但如何让编程从单纯地写代码变成“工艺”呢？
马丁认为，程序员掌握的主要工具是持续重构和测试驱动开发（TDD）。两者像硬币的两面般协同工作。来看一些概念：
重构是在不更改输出的情况下调整现有计算机代码结构的过程。
测试驱动开发是将需求转换为特定测试用例，再添加代码以使测试通过的过程。
因此，制作软件的过程可能如下所示：
1. 编写测试代码以验证所需但未实现的功能。
2. 编写有效代码（可能不整洁），并通过测试。
3. 逐步重构代码（保证每次通过测试），使代码在每次开发迭代中都更加清晰。
“不要想着一次性编程后系统就能正确、漂亮地运行。今日的任务仅仅是让程序运行起来，而重构和扩展系统是明天的任务。这是迭代和增量敏捷的本质。”——罗伯特·C·马丁
因此，本书的中心思想是，整洁代码是在开发和实践中实现的，而非简单地一口气创建出来。
整洁的边界
所谓的“边界”是指外来代码（三方程序包、开放源代码、其他团队打造的组件和子系统）和自己写的代码之间进行整合的连接区域
1.使用第三方代码
1.第三方程序包和框架提供者追求普适性，这样就能在多个环境中工作，吸引广泛的用户。
2.我们建议不要将Map（或在边界上的其他接口）在系统中传递，把它保留在类或近亲类中，避免从API中返回边界接口，或将接口作为参数传递给公共API。
比如应用程序可能构造一个map对象并传递它。我们的初衷可能是map对象的所有接收者都不要删除映射图中的任何东西。但map正好有一个clear方法。
2.使用尚不存在的代码
还有一种边界，那种将已知和未知分隔开的边界。在代码中总有许多地方是我们的知识未及之处。有时我们并不往边界那边看过去
编写我们想得到的接口，好处之一是它在我们控制之下。这有助于保持客户代码更可读，集中于它该完成的工作。
这里我觉得书里的例子就非常的好，如图：
结语
《代码整洁之道》中，并非每个想法都是Bob叔叔提出的，他在书中的各部分都承认了这一点。而这反而是使本书如此成功的一个原因——它是编程界智慧的汇聚，并附有实例，值得大家一看。
