Clean Code 中文版.docVIP

什么是整洁代码 如果代码很容易被团队的每个人读懂的话就称作整洁代码。伴随着可理解化 发展了代码的可读性与可理解性，可变性，可扩展性和可维护性。在没有积 累大量的技术债务情况下需要所有的东西来保持项目长时间的工作 最佳响应 特点 刚性 该软件是很难改变的。一个小小的改变，会导致后续变化级联反应。 – – – – – – 常规 按照标准公约 编码，建筑，设计指南（检查工具） 字段非定义状态+ + + + – – 脆弱性 由于一个单一的变化，会使得软件很多地方遭到破坏。 保持简单，愚蠢 简单的总是更好。尽可能地降低复杂性。 F字段保存数据并不属于实例状态，但用于保存临时数据。使用局部变量或提 取一类抽象执行的动作。 可配置性– 高 高 固定性 您不能重复使用代码在其他项目中，因为关系到风险和高精力。 童子军规则 离开营地比你发现它要清洁。 防止可配置性，因为没有人能决定它应该如何。否则，这将导致过于复杂不 稳定的系统。 响应变化 根本原因分析 在一个源文件的多国语言版 C#, Java, JavaScript, XML, HTML, XAML, English, German … 微层 不要在上面添加功能，但整体需要简化。 – 实际 CoC 变动成本(CoC) 响应 粘度的设计 抄近路和引进技术债务更能够事半功倍。 总是寻找一个问题的根本原因。否则，它将让你一遍又一遍。 依存性 实体逻辑相依存 单身/服务定位 使用依赖注入。单身隐藏的依赖关系。 + – – – – 粘度环境 高度增加复杂性 该设计中包含的元素，目前没有用到。增加的复杂性，使代码更难理解。因 此，扩大和改变代码结果需要投入较高的精力。 构建，测试和其他任务需要很长的时间。因此，每个人都没能将这些活动正 确执行技术债务引入。. 环境 项目建设只需要一步。 退出只需然后建立一个单一的命令。 I如果一个模块依赖于另一个，那应该是实体依赖，而不只是逻辑。不需要作 出假设。 + + + + – 技术债务 低 最佳 CoC 时间 低 执行测试只需要一步 运行所有的单元测试，只需要一个单一的命令 基类取决于它们的派生类 基类可以与任何派生类工作。不必要的重复 – 源控制系统 通常使用源代码控制系统 信息过多 减少接口耦合以致降到最低 一个项目开始编写干净的代码是一个软件产品的整个生命周期中使变化成本 保持尽可能恒定的一项投资。因此，当写干净的代码（灰线）时最初的变化 成本比快速和肮脏的编程（黑线）稍高，但支付却相当快。尤其要记住的在 软件维护过程中大部分费用需要支付。随着时间的推移，如果不重构干净的 代码，不洁代码会导致技术债务增加。还有其他原因导致技术债务，如坏流 程和缺少文件，但不洁的代码是一个主要驱动因素。造成结果的是，响应变 化的能力在下降（红线）。 代码中包含大量重复的代码：精确的代码重复或设计重复（以不同的方式做 同样的事情）。重复一段代码更改更昂贵，更容易出错，因为变化在几个地 方，需要面临一个地方没有相应改变的风险。 持续集成 保证完整性与持续集成 特征排斥 重写的安全装置 依赖关系注入 从运行系统中解耦构建 在运行时完全解耦构建阶段，有助于简化运行时的行为。 不要重写警告，错误，异常处理-他们会抓住你。. 透明度 – 代码是很难理解的。由于不理解的副作用，因此，任何变化都需要花费额外 的时间来重新设计代码，并更可能导致缺陷，。 + 类的方法应该是用在属于该类的类变量和函数中产生作用的，而不是作用于 其他类别的变量和函数。当一个方法使用一些其他的对象来操作该对象内的 数据的访问器和存取器时，那么它排斥其他对象类。它希望它里面的其他类 以便可以直接访问变量操纵。 人工耦合 隐性时态耦合 – – 在整洁代码中，错误不能隐藏 类的设计 单一职责原则 一个类应该有一个，且只有一个理由去改变。 不依赖于对方不应该被人为地加上。 例如，一些方法调用的顺序是非常重要的，然后确保他们不能被称为在次序 错误 + + + + + + 当改变现有的代码时，许多软件缺陷被引入。原因是开发商不能完全掌握改 变代码时产生的影响。通过编写尽可能容易明白的代码，干净代码使引入缺 陷的风险降至最低。 设计 较高水平的配置数据 + 开闭原则 在不修改它的情况下，你能够有扩展一个类的行为。 原则 松散的耦合 类，组件，模块中的至少有一个使用了其它的，则两个类，组件或模块将会 耦合。这些项目了解对方之后，会实现宽松耦合。一个组件仅能够松散地耦 合到它的环境，这样使得比强耦合的组件更为容易地改变或替换 Liskov 替换原则 + 必须替代其基类的派生类 I如果你有一个如拖欠或配置恒定的值，具有已知和抽象化预计的高水平，不 要把它埋没在一个低级别的功能上。作为一个参数揭露它，从