Category: ReadingNotes

代码整洁之道(Clean Code) 笔记(三)

2017-04-24 | 阅读(501)

第八章：边界

本章关于如何学习使用第三方组件

  1. 第三组件或框架追求普适性，而使用者则想要集中满足特定的需求
  2. 学习第三方组件首当其冲当然还是文档，其次重要的是它的单元测试，我甚至是把单元测试当作文档的一部分来看待。其实更重要的方法是学习性测试(learning tests), 通过测试来学习才是切实的体验，是一种精确的试验，我们甚至可以用自己的测试来验证第三方组件的新版本
  3. 边界上会发生有趣的事，这就要求我们对它清晰的分割和定义，以避免我们的代码过多地了解第三方组件中的特定信息，依靠你能控制的东西好过依靠你控制不了的东西，免得日后受它控制。简而言之就是尽可能隔离边界，在边界改动时只需要修改一下适配器，对的适配

第九章：单元测试

这一章我自认为是很重要的，特别是正在采用测试驱动开发/设计(TDD) 的程序员来讲。充分，良好的单元测试是保证我对生产代码大刀阔斧的关键，这也就是 TDD 的最后一个 D 又能理解了 Design 的原由

阅读全文 >>

代码整洁之道(Clean Code) 笔记(二)

2017-04-02 | 阅读(480)

第四章：注释

  1. 别给糟糕的代码加注释 -- 重新写吧
  2. 什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧，提供错误信息的注释更有破坏性
  3. 若编程语方足够有表达力，或者我们长于用这些语方来表达意图，就不那么需要注释 -- 也许根本不需要
  4. 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
  5. 不准确的注释要比没注释坏得多。它们满口胡言。代码，只有代码能忠实的告诉你它做的事
  6. 好注释不多，如法律信息，警示等。我都不觉得 TODO 是多好的东西
  7. 大多数注释都是坏注释，甚至一些 IDE 自动生成的代码也加一堆的废话注释，分散阅读注意力。我也写过那种日志式注释，这本是版本控制系统干的事。
  8. 很奇怪 IntelliJ IDEA 还在自动为新建的类加下创建者，代码是团队共有，时间长了根本就与作者无半毛关系。我经常碰到这种写有作者的代码哭笑不得，直接把原作者改了或删了也不太好，还不如把文件删了，新建一个没有作者注释的类
  9. 直接把代码注释掉是种讨厌的做法，自己可能不会再启用，其他人以为很重要更不敢删。不用了最好果断删掉，版本控制系统会帮你记住历史。
  10. 个人认为，注释会胡说八道，产品代码和测试代码不会撒谎。有功夫写注释还不如写好测试用例，测试需要维护，它本身就是最真实的文档。

阅读全文 >>

代码整洁之道(Clean Code) 笔记(一)

2017-03-07 | 阅读(716)

第一章：整洁代码

  1. 代码即设计
  2. 童子军军规：把露营地清理得比来时还干净，签入代码前是否已做重构
  3. 你湎自行实践，且体验自己失败。你须观察他人的实践与失败
  4. 勒布朗(LeBlanc) 法则：稍后等于永不 (Later equals never)
  5. 赶上期限的唯一方法--做得快的唯一方法--就是始终尽可能保持代码整洁
  6. 缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化
  7. 不好的代码引诱别人做没规矩的优化，搞出一堆混乱来
  8. 整洁的代码只做好一件事，糟糕的代码想做太多事，它意图混乱，目的含混
  9. 整洁的代码从不隐藏设计者的意图
  10. 整洁的代码只提供一种而非多种做一件事的途径
  11. 整洁的代码总是看起来像是某位特别在意它的人写的
  12. 回放我们编码过程显示，多多数时间都是在滚动屏幕，浏览其他模块
  13. 读与写花费时间的比例超过 10:1, 写新代码时，我们一直在读旧代码
  14. 编写代码的难度，取决于读周边代码的难度 阅读全文 >>