《代码整洁之道》读书笔记

  不管是现实世界还是软件项目中，命名都是一件让人头疼的事情，给小孩起过名字的就知道，你希望把你对孩子的期望包含在这个名字中，你又希望这个名字读起来要好听，至少不至于将来成为别人的笑柄（比如庞光大、魏升京这样的名字），可能你还要考虑族谱班辈的排列等等。软件项目中的命名情况会更加复杂，简单的说命名的原则是"见名知意"，当然你还需要用各种方式防范命名冲突的问题，不同的编程语言也有自己不成文的像契约一样的命名规则和方式（例如匈牙利命名法），这些可能都是需要考虑的事情。我个人并不喜欢匈牙利命名法，加上一个类型前缀的感觉就是永远和这个东西绑定到一起了，就如同用C语言的malloc函数分配内存创建一个能放100000个元素的数组，你愿意用下面哪种写法呢？记住：好的名字相当于为代码写了一段有用的注释。

int* myArray = NULL;
    /* 写法1 */
    myArray = malloc(100000 * sizeof(int));
    /* 写法2 */
    myArray = malloc(100000 * sizeof *myArray);

  第三章讲的是函数，说了这么一句话："Function should do one thing. They should do it well. They should do it only. "（函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情），听起来很简单的一句话但是要践行这条原则却并不容易，所以我们的代码中才会有很多的坏味道（请参考《重构：改善既有代码的设计》一书的第三章）。事实上，上升一个层次，我们在设计类的时候也应该如此，这是面向对象设计原则中说的单一职责原则（SRP），当我们的代码中出现了冗长的方法或者巨大的类的时候，我们就应该依据职责来对其进行拆分，这样程序的结构才会趋于合理，最终达到"高内聚"的目标。当然，这一章里面还提到很多理念，包括：Command Query Separation（一个方法要么执行某种命令，要么返回查询数据）、DRY（不要重复自己）、Prefer Exceptions to Returning Error Codes（异常优于返回错误码）等。

  第四章讲的是注释，有一句话我很喜欢，说的是："Comments Do Not Make Up for Bad Code."（注释不是对劣质代码的补救）。事实上好的代码即便没有注释也拥有良好的可读性，但恰当的注释会让代码变得更可读、可维护性更高。

  第九章的内容是单元测试。Bob大叔是TDD（测试驱动开发）的倡导者，这一章讲的是如何编写整洁的测试，Bob大叔的答案是FIRST规则（Fast、Independent、Repeatable、Self-Validating、Timely）。

  第十章介绍类的设计，最重要的还是SRP（单一职责原则）。

  第十一章是关于系统设计的内容，开篇引用了微软首席技术官Ray Ozzie的一句话："Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test."（复杂要人命，它消磨开发者的生命，让产品难于规划、构建和测试）。这章对于希望了解面向切面编程的开发者是极好的，包括了对依赖注入、代理模式以及AOP的探讨。

  第十二章探讨了系统的迭代式演进。

  第十三章对并发编程的讨论非常经常，很多开发者都畏惧并发编程，也有的开发者迷信多线程可以解决所有的并发问题，如果你是这两类人之一，本章会教给你真正的并发编程。这一章的内容我重新整理了一篇文章，已经发布在的博客上，名为。

  第十四章是一个精彩的案例用来讲解对代码的持续改进，你可以自己好好阅读一次。第十五章到第十七章说的都是重构，相当精彩。如果你还没有来得及读《重构：改善既有代码的设计》一书，你可以先读读这几张中探讨的代码的坏味道及其改进方案。

  总之，这本书从引言到附录都无比精彩，书中的代码是用Java语言书写的，赶紧去阅读吧。