"任何一个傻瓜都可以写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员" -- Martin Flower
Clean Code
- 什么样的代码才是整洁代码？
- 整洁代码有怎样的特性？
什么样的代码才是整洁代码？
从六个方面解决代码整洁的问题：
- 命名：有意义
- 方法：有层次
- 类：合理封装
- 注释：够简洁
- 格式：统一
- 重构：持续改进
命名
- 名副其实就不需要注释
- 避免命名之间的混淆
- 请抵制缩写诱惑
- 名称长度与作用范围成正比
小游戏--统计字符串中各个字母出现的次数
包含坏味道的最初实现代码：
根据 Clean Code 命名原则进行重构后：
命名借鉴：取个好名字是一门艺术
重构
- 允许先写肮脏的代码，但必须重构它
- 尽量借助工具重构，避免人为错误
- 持续改进，避免破窗效应
工具：代码编辑器，IDEA、VSCod等
IDEA默认快捷键：
IDEA 提供了重构的功能，支持：重命名、提常量与变量、抽方法等，只需要选中需要重构的代码段然后右键，找到 refactor 并选择需要使用的功能即可，当然也可以通过快捷键进行对应的操作
方法
一个方法只做一件事情，即Clean Code提倡的方法应该是原子方法
那么如何判断"一个方法只做一件事情"呢？
- 能用"为了实现...的功能，需要..."来描述这个方法
- 将函数名、函数体带入，即：为了实现(函数名)的功能，需要(函数体)
- 保持同一抽象层级
- 参数越少越好：0>1>2>3
- 参数的顺序最好反应被使用的顺序
- 标识参数表明函数不止做一件事
- 尽量将异常处理从主流程中分离出来
小游戏--上传文件的功能
上图为上传文件功能的最初实现，仅为了实现功能而写代码，完全不考虑代码整洁问题
重构--上传文件的功能
首先在对代码进行重构之前，先梳理一下实现此功能的逻辑：
为了实现上传文件的功能，需要：
- 判断上传的文件是否为空；若为空，抛出错误异常
- 获取文件夹路径
- 判断放文件的文件夹是否存在；若不存在，创建文件夹
- 获取文件路径
- 判断上传的文件是否存在；若不存在，创建文件
- 将上传的文件内容保存到文件夹下的文件里
下图是该功能的流程图，与文字描述对应着来能对功能的实现流程更加清晰
根据上面梳理的功能逻辑并结合 Clean Code 对方法实现的要求进行重构后：
下面是根据功能抽出的方法：
类
- 包含的内容太多，就拆分它
- 对外暴露内容太多，就封装它
注释
- 注释尽量做到简洁
- 最好不写注释
- 写注释说明表达意图的失败
- 糟糕代码是注释存在的动机之一
- 必须写的注释
- 警告他人
- 版权协议
- 公共API
- TODO 注释
- 写注释的注意事项
- 无法自注释的情况(副作用)
- 注释与代码同步
- 注释只说明Why
格式
"对代码采用一致的格式，这不是浪费时间的愚蠢修饰，而是一种重要的交流工具" -- Andy Hunt
学习报纸排版，报纸排版让读者能快速的根据需求定位到对应的板块，获取相应的信息
- 选一款赏心悦目的字体
- 代码排版的注意事项
- 紧密相关的代码放在一起
- 保持代码短小(width：80)
- 保持格式统一一致
- 合理的运用换行和空格
整洁代码有怎样的特性？
整洁代码具有三个特性：
- 可读性
- 可维护性
- 可扩展性
Clean Coder
- 始终保持专业水准，具备良好的沟通能力、项目管理能力和问题解决能力
- 专业的软件开发人员需要遵守道德准则，包括保护用户隐私、保持透明度和保持数据安全
- 了解开发流程，如测试驱动开发、敏捷开发和持续集成
- 应该具备的技能，如测试、代码重构和代码审查等
- 客户和其他团队成员进行积极有效的沟通
- 职业生涯规划和发展的建议，如：构建自己的个人品牌、处理职业生涯中的挑战和与其他开发人员建立联系
小结
Clean Code 和The Clean Coder这两本书是姊妹篇，作者都是 Bob 大叔
- Clean Code 给开发者提供了如何使项目代码更整洁的一些建议，或者说协议（当大家都遵守时）
- The Clean Coder 则更注重于职业素养的培养，也是提供了一些建议，成为专业开发者的建议
Clean Code 和 The Clean Coder 两书相辅相成，当身为开发者的你掌握了 Clean Code 中的规约后，需要同时具备 The Clean Coder 中提到的专业开发者的素养，才能正真的写出整洁代码
推荐书籍：《Clean Code》、《The Clean Coder》