您当前位置：首页 > php开源 > php教程 > 《代码整洁之道》读书笔记

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

来源：程序员人生发布时间：2015-04-18 11:45:24 阅读次数：4289次

??最初我喜欢这本书多是由于非技术方面的缘由，这本书中有很多我喜欢的插图。这本书的第1章的第1句话是这样说的：读这本书通常有两个缘由：1. 你是1名程序员。2. 你想成为更好的程序员。我们需要更好的程序员。
??这本书的每章都可以总结出1句话，其实每章开始的插图就是这句话的浓缩。
这里写图片描述
??本书的第1章是关于甚么是整洁代码的讨论，援用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的开创人之1）等人固然也Bob大叔（本书的作者Robert Martin）自己对整洁代码的理解。顺便说1下，上面那张图上的代码应当是保龄球计分程序（不知道大家看清楚了没有，哈哈）。

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

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

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

这里写图片描述
??第4章讲的是注释，有1句话我很喜欢，说的是："Comments Do Not Make Up for Bad Code."（注释不是对劣质代码的补救）。事实上好的代码即使没有注释也具有良好的可读性，但恰当的注释会让代码变得更可读、可保护性更高。

这里写图片描述
??第5章讲的是代码风格。现代IDE（集成开发环境）几近都有代码格式化代码的功能，你只需要设置好你使用的代码风格就能够了，其实不只是IDE，很多高级的文本编辑工具也能够依照指定的风格格式化你的代码。用甚么样的代码风格不是关键，关键是全部项目组的成员应当使用相同的代码风格，让多个人编写的代码看起来像1个人书写的。我个在代码中使用的括号风格是1TBS（One True Bracing Style，也叫做K&R风格，这类风格是Kernighan和Ritchie两位老师在"The C Programming Language"1书中使用的代码风格），固然Allman风格（FreeBSD系统的作者之1使用的代码风格）也是很好的选择。

这里写图片描述
??第6章讨论的是对象和数据结构，读完以后的感觉是虽然我们每天都嚷着吼着要面向对象编程，但是很多时候我们都使用了类的退化结构，包括我们开发时常常使用的失血模型和贫血模型（事务脚本模式）都和面向对象的设计理念相背背。我得承认在读这1章的时候我可能没有捉住作者的观点。

这里写图片描述
??第7章对毛病处理（异常）的讲授非常精彩的，整洁的代码中对毛病的处理应当是被分离的关注点（不要跟正常的业务逻辑混杂在1起），而面向对象中的异常机制就是1种在不打乱原有业务逻辑的条件下处理掉程序在运行时产生的不正常状态的手段。这章有两个观点我特别欣赏，1是"Use Unchecked Exceptions"（非受检异常允许你在适当的地方处理异常，而适当的地方就是异常影响代码履行逻辑的地方，不管做哪一种类型的利用，都应当尽量向用户隐藏异常的产生，除非产生了不可挽救的状态，这才是符合最小惊讶原则的设计）；2是"Don’t Return Null"（如果1个方法在出状态的时候返回null，那末调用者都要通过频繁的检查返回值来判定是不是出错，1旦忘了这件事情就有可能出错，既然null是1种异常状态，那末用抛出异常的方式来代替返回null明显是更好的做法）。

这里写图片描述
??第8章的内容对实际开发有重要的指点意义，由于我们的项目中不可避免的要使用第3方工具，因此我们需要将这些东西整洁的纳入到我们的系统中，这时候就需要斟酌系统边界的问题。有的时候我们会千辛万苦的发现系统中的1些bug是来源于第3方工具的，固然我们基本上没有时间去重头学习和研究第3方工具或自己写代码来实现第3方工具的功能，但是我们最少应当先对第3方工具进行测试。我在之前的项目中，即便用Apache提供的那些著名的第3方工具，我的做法也是先写测试代码对这些工具的可用性和有效性进行证实，固然有的时候多是过于谨慎了，但这类习惯和做法本身是很好的。在这类场景下，适配器模式是非常好的设计，它不但能将不兼容的接口改写成兼容的接口，还能够对通过对第3方工具重新封装来避免边界的变化对系统的影响。

这里写图片描述
??第9章的内容是单元测试。Bob大叔是TDD（测试驱动开发）的提倡者，这1章讲的是如何编写整洁的测试，Bob大叔的答案是FIRST规则（Fast、Independent、Repeatable、Self-Validating、Timely）。

这里写图片描述
??第10章介绍类的设计，最重要的还是SRP（单1职责原则）。

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