江湖人称菠萝包

代码清单B-15　SpreadsheetDateFactory.java（最终版本）代码清单B-16　SpreadsheetDate.java（最终版本）代码清单B-14　DayDateFactory.java（最终版本）代码清单B-10　DateInterval.java（最终版本）代码清单B-12　WeekdayRange.java（最终版本）代码清单B-11　WeekInMonth.java（最终版本）代码清单B-13　DateUtil.java（最终版本）

本附录扩充了第13章的内容，由一组相互独立的主题组成，你可以按随意顺序阅读。为了实现这样的阅读方式，节与节之间存在一些重复内容。

Martin Fowler在其大作《重构：改善既有代码的设计》（Refactoring: Improving the Design of Existing Code）中指出了许多不同的“代码的坏味道”。下面的清单包括很多Martin指出的“坏味道”，还添加了更多我自己提出的“坏味道”，也包括我借以历练本业的其他珍宝与启发。我借由遍览和重构几个不同的程序总结出这个清单。每次修改，我都问自己为什么要这样改，把修改的原因写下来，结果就得到相当长的清单，该清单列出了在读代码时让我闻起来不舒服的味道。

如果你找到JCommon类库，深入该类库，其中有个名为的程序包。在该程序包中，有个名为SerialDate的类，我们即将剖析这个类。SerialDate的作者是David Gilbert。David显然是一位经验丰富、能力很强的程序员。如我们将看到的，他在代码中展示了极高的专业性和原则性。无论怎么说，SerialDate都是“好代码”，而我将把它撕成碎片。这并非恶意的行为，我也不认为自己比David强许多，有权对他的代码说三道四。其实，如果你看过我的代码，我敢说你也会发现好些该埋怨的东西。

JUnit是最有名的Java框架之一。就像别的框架一样，它概念简单，定义精确，实现优雅。但它的代码是怎样的呢？本章将研判来自JUnit框架的一个代码例子。

本章研究一个逐步改进的案例。你将看到一个开始还不错，但规模扩大后即出问题的模块。你还将看到这个模块是如何被重构得整洁起来的。我们中的大多数人都会遇到解析命令行参数的情况。如果没有就手的工具，就得遍历传入main函数的字符串数组。有一些不同来源的好工具，但没有一个是最符合要求的。所以，我当然要自己写一个，我把它叫作Args。Args非常易于使用。你只要简单地用输入参数和格式化字符串构造Args类，再向Args实体询问参数值即可。看看代码清单14-1中给出的简单例子。代码清单14-1　Args的简单用法。

对象是过程的抽象。线程是调度的抽象。编写整洁的并发程序很难——非常难，而编写在单线程中执行的代码却简单得多。编写表面上看似不错、深入进去却支离破碎的多线程代码也简单，但是系统一旦遭受压力，这种代码就扛不住了。本章将讨论并发编程的需求及其困难之处，并给出一些应对这些难点、编写整洁的并发代码的建议。最后，我们将讨论与测试并发代码有关的问题。整洁的并发编程是个复杂话题，值得用一整本书来讨论。本书只做概览，并在附录A中提供更详细的指引。如果你只是对并发好奇，阅读本章就足够了。

假使有4条简单的规则，跟着做就能帮助你创建优良的设计，会如何？假使遵循这些规则，你就能洞见代码的结构和设计，更能轻易地应用SRP和DIP之类的原则，便会如何？假使这4条规则有利于良好的设计“浮现”出来，又会如何？我们中的许多人认为，Kent Beck关于简单设计的4条规则，对于创建具有良好设计的软件有着莫大的帮助。据Kent所述，只要遵循以下规则，设计就能变得“简单”：运行所有测试；不可重复；表达了程序员的意图；尽可能减少类和方法的数量。以上规则按其重要程度排列。

复杂要人命。它消磨开发者的生命，让产品难以规划、构建和测试。

到目前为止，本书一直在讨论如何编写良好的代码行和代码块。我们深入研究了函数的恰当构成，以及函数之间如何互相关联。尽管讨论了这么多关于代码语句及由代码语句形成的函数的表达力，但是，除非我们将注意力放到代码组织的更高层面，否则始终不能得到整洁的代码。

过去十年以来，编程专业领域进步很大。1997年时，没人听说过测试驱动开发。对于我们之中的大多数人来说，单元测试是那种用来确保程序“可运行”的用过即扔的短代码。我们辛勤地编写类和方法，再弄出一些特殊代码来测试它们。通常这些代码会是一种简单的驱动式程序，让我们能够手工与自己编写的程序交互。我记得在20世纪90年代曾为一套嵌入式实时系统编写过C++程序。想法很简单；到达指定毫秒数时，在一个新线程中执行Command的execute方法。问题在于如何测试它。我随便写了个简单的驱动式程序，聆听来自键盘的动作。

我们很少能控制系统中的全部软件。有时我们购买第三方程序包或使用开放源代码，有时我们依靠公司中其他团队打造组件或子系统。不管是哪种情况，我们都得将外来代码干净利落地整合进自己的代码中。本章将介绍一些保持软件边界整洁的实践手段和技巧。

对异常分类有很多方式。可以依其来源分类：是来自组件还是其他地方？也可以依其类型分类：是设备错误、网络错误还是编程错误？不过，当我们在应用程序中定义异常类时，最重要的考虑应该是它们如何被捕获。我们来看一个不太好的异常分类的例子。下面的语句是对某个第三方代码库的调用。try {语句包含了一大堆重复代码，这并不出奇。在大多数异常处理中，不管真实原因如何，我们总是做相对标准的处理。我们得记录错误，确保能继续工作。

我们将变量设置为私有（private）有一个理由：不想让其他人依赖这些变量。我们还想在心血来潮时能自由修改其类型或实现。那么，为什么还是有那么多程序员不假思索就给对象添加赋值器（setter）和取值器（getter），将私有变量公之于众，如同它们是公共变量一般呢？

当有人查看底层代码实现时，我们希望他们为代码的整洁、一致及所感知到的对细节的关注而震惊。我们希望他们高高扬起眉毛，一路看下去。我们希望他们感受到专业人士们的劳作。但若他们看到的只是一堆像是由酒醉的水手写出的鬼画符，那他们多半会得出结论，认为项目其他任何部分也同样对细节漠不关心。你应该保持良好的代码格式。你应该选用一套管理代码格式的简单规则，然后贯彻这些规则。如果你在团队中工作，则团队应该一致同意采用一套简单的格式规则，所有成员都要遵从这套规则。使用能帮你应用这套格式规则的自动化工具会很有帮助。

什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。注释并不像辛德勒的名单。它们并不“纯然地好”。实际上，注释最多也就是一种必需的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释——也许根本不需要。注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注意，我用了“ 失败”一词，我是说真的，注释总是一种失败。我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆贺。

在编程的早期岁月，系统由程序和子程序组成。后来，到Fortran和PL/1的年代，系统由程序、子程序和函数组成。如今，只有函数存活下来。函数是所有程序中的第一组代码。本章将讨论如何写好函数。请看代码清单3-1。在FitNesse中，很难找到长函数，不过我还是搜寻到一个。它不光长，而且很复杂，有大量字符串、怪异且不显见的数据类型和API。花3分钟时间，你能读懂多少？代码清单3-1　HtmlUtil.java（FitNesse 20070619）读懂这个函数了吗？大概没有。

起好名字最难的地方在于需要良好的描述技巧和共有文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。其结果是，这个领域内的许多人都没能学会做得很好。我们有时会担心其他开发者反对重命名。讨论一下就会知道，如果名称改得更好，那大家真的会感激你。多数时候我们并不记忆类名和方法名，而使用现代工具应对这些细节，好让自己集中精力把代码写得像词句篇章，至少像是表和数据结构（词句并非总是呈现数据的最佳手段）。改名可能会让某些人吃惊，就像你做到其他代码改善工作一样。别让这种事阻碍你前进的步伐。

略。