《代码整洁之道》全书归纳

如果要把这本书最关键、最核心、被反复提及和强调的重点提炼出来，那就是：

• 可读性高于一切： 你的代码是给人读的，让它像一篇清晰的文章一样易于理解。表达意图是关键。
• 短小、单一： 函数要短小，类要短小，它们都只做一件事情。这是控制复杂度的主要手段。
• 命名是基础： 花时间起好名字，这是让代码自文档化的第一步。
• 测试是生命线： 没有好的单元测试，你无法安全地重构和改进代码。测试是整洁代码不可或缺的一部分。
• 持续改进： 整洁不是一次性的任务，而是一个持续的过程。每次触碰代码，都 (尽量) 使它比你来之前更整洁（童子军规则）。
• 专业精神： 视编程为一项需要持续学习和精进的技艺，对自己的代码质量负责。

《代码整洁之道》核心要点

• 可读性与简洁性：代码应该像讲故事一样易于理解，遵循 KISS 原则（Keep It Simple）。保持代码高内聚、低耦合，并遵循“童子军法则”——每次修改后都让代码更整洁。清晰可读的代码便于维护和扩展。
• 有意义的命名：变量、函数、类等名称要准确描述其用途和含义，使用可读的单词而非晦涩缩写或魔法数字。命名应让代码自解释，减少对注释的依赖，保持一致的命名风格以提高可读性。
• 函数简洁且单一职责：函数应短小（通常不超过几行），每个函数只做一件事并保持在同一抽象层级。函数名要清晰表意，参数尽量少（避免超过2-3个），不应依赖全局变量或产生副作用。遵循单一职责原则（Single Responsibility Principle，SRP），可以将复杂逻辑拆分为多个小函数。
• 避免重复（DRY原则）：不要复制粘贴代码。当发现重复时，应通过提取公共函数或重构来消除重复。重复的代码会增加错误风险和维护成本，因此 DRY（Don't Repeat Yourself）原则是整洁代码的重要实践。
• 合理使用注释：注释应简明有用，仅在必要时提供代码以外的信息或解释意图。避免无意义、过时或冗余的注释。好的代码本身应该能够自解释，当代码难以直接说明意图时再添加注释，并保证注释与代码同步更新。
• 一致的格式和风格：遵循统一的代码格式规范（如缩进、换行、空格、命名约定），保持代码风格一致。良好的格式有助于阅读流畅、快速定位结构，并促进团队协作。使用格式化工具和代码评审可确保风格统一。
• 类和模块的单一职责：每个类或模块都应只有一个职责，使其高内聚、易理解。不要在一个类中混合无关功能。通过关注点分离提高设计质量，并可遵循开放-封闭、里氏替换、接口隔离等设计原则，增强代码的灵活性和可扩展性。
• 对象与数据结构：区分对象和数据结构的概念——对象封装行为和状态，数据结构主要承载数据。避免将二者混合使用。为每个概念创建合适的类或常量，将魔法数字/字符串封装起来，提升代码的可维护性。
• 错误处理：错误处理逻辑要清晰，不应混乱或干扰主要逻辑。优先使用异常机制代替返回错误码，在需要的层面捕获和处理异常。不要吞掉异常，应记录或传播错误信息以便定位问题，从而保证系统的鲁棒性。
• 自动化测试：编写充分的单元测试，每个测试只验证一个断言，保持测试简洁可读且相互独立。测试驱动开发（TDD）鼓励先写测试再实现代码，从而促使设计更清晰。良好的测试用例可作为代码行为的文档，帮助重构和防止回归。

代码异味识别

识别“代码异味”（Code Smells）： 重构通常始于发现代码中的问题迹象，即“代码异味”。这些异味是代码中可能存在更深层次设计问题的表面特征。学会识别这些异味是重构的第一步。常见的异味包括：

• Duplicated Code (重复代码): 同一段代码在多个地方出现。
• Long Method (过长函数): 一个函数做了太多事情，包含太多行代码。
• Large Class (过大类): 一个类承担了太多职责，包含太多字段和方法。
• Primitive Obsession (基本类型偏执): 过度使用基本类型代替小对象，例如用两个 double 表示一个范围，而不是一个 Range 类。
• Switch Statements (Switch语句): 过长的或重复的 switch/if-else if 结构，通常意味着可以使用多态来替代。
• Parallel Inheritance Hierarchies (平行继承体系): 当你继承一个类时，必须同时继承另一个类。
• Lazy Class (孺子类): 一个类做的事情太少，没有充分的理由独立存在。
• Feature Envy (依恋情结): 一个方法过度使用另一个对象的字段和方法，而不是使用自身类的字段和方法。
• Data Clumps (数据泥团): 一组数据（字段或方法参数）总是结伴出现，应该考虑将它们封装成一个对象。
• Comments (注释): 过多的解释性注释，或者注释只是在解释代码“做了什么”，而不是“为什么这么做”，这通常意味着代码本身不够清晰
• 前后一致：比如 HttpServletResponse 命名为 response，后面一致用 response
• 枚举优先变量