本文是《代码大全》学习笔记系列的最后一篇。书中最后几章是一些杂项主题，本文将简要记录这几个主题的内容，包括个人性格对编程的影响，软件开发艺术的有关问题，以及关于软件工程的推荐书单。

本文关注的是计算机编程的美学话题——程序源代码的布局和自说明性。尽管这些技巧并不影响执行速度、内存使用量等方面的程序性能，但它却会让你日后理解、检查以及修改代码变得更容易，也使其他人在你缺位的时候更容易阅读、理解和修改你的代码。

需要注意的是，形成良好的代码布局，并让代码具备自说明性，需要始终贯穿项目的生命期，晚了就很难做好了。要想完全实现这些细节规定，在最初建构时就要着手去做。如果你干的是合作项目，更是要在开始编码之前统一大家的风格。

集成是指将一些独立的软件组件组合为一个完整系统。对大项目，集成也许要花数周或数月时间，把一组程序编织为一个整体。本文将首先介绍不太常用的阶段式集成，然后再介绍更为常用的增量集成，其中集成的策略是讨论的重点。最后每日构建与冒烟测试的使用原则。

软件开发的规模扩大并不是像“拿一个小项目来，然后增大它的每一部分”那样简单。如果要开发大型软件，就必须了解软件规模对构建的影响。此外，本文将记录与构建直接相关的一些特定管理问题。如果你是一名开发人员，本文将帮助你了解管理者需要考虑的一些问题；如果你是一名管理者，本文将帮助你了解开发人员是如何看待管理者的，以及如何才能有效地管理构建。

本文首先概述了程序运行性能应该考虑的一些问题，然后从策略上和技术上两个方面来探讨代码性能的调整问题。技术上的代码调整并没有什么万金油的方法，也不是灵丹妙药，唯一可以信赖的法则就是每次都应当在具体的环境下评估代码调整所带来的效果，而本文所列的调整方法则仅供参考。此外，追求性能的背后往往伴随着牺牲程序的可读性和可维护性，而在很多情况下，代码的可读性和可维护性都要比运行速度或资源占用更为重要。因此在调整代码时一定要考虑这样的性能提升是否真的必要。

测试可以由开发人员或专门的测试人员进行。按层级分，测试可以分为单元测试、组件测试、继承测试、回归测试、系统测试；按是否了解对象内部工作机制分，测试可以分为黑盒测试和白盒测试。本文关注的是开发人员所进行的白盒测试。重构是“在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改”的过程。本文将讲述软件演化以及重构的一些理念。

测试和重构都是非常大的话题，大到足以各用一本经典著作来阐述，如《软件测试》和《重构：改善既有代码的设计》。因此本文也仅是记录一些要点，如果要深入了解，还是要阅读相关的书籍为好。

所有的协同构建技术都试图通过这样或那样的途径，将展示你工作的过程正式化，以便把错误暴露出来。软件构建不可避免地都会伴随着调试，在一些项目中，调试可能占到整个开发周期的50%。对很多程序员来说，调试是程序设计中最为困难的部分。本文的前半部分将介绍协同构建的一些实践方法，后半部分将介绍一些科学的调试手段以节省更多精力。

表驱动法是一种编程模式——从表里面查找信息而不使用逻辑语句（if和case）。事实上，凡是能通过逻辑语句来选择的事物，都可以通过查表来选择。本文将介绍直接访问表、索引访问表和阶梯访问表三种常见的表驱动法。最后，本文将记录一些控制问题（如布尔表达式的使用、空语句、深层嵌套问题等等）上的使用原则，这一部分内容比较简单而且与前面的章节有一些重叠，因此将快速带过。

防御式编程这一概念来自防御式驾驶。在防御式驾驶中要建立这样一种思维，那就是你永远也不能确定另一位司机将要做什么。这样才能确保在其他人做出危险动作时你也不会受到伤害。你要承担起保护自己的责任，哪怕是其他司机犯的错误。本文将讲述如何面对严酷的非法数据的世界、在遇到“绝不会发生”的事件以及其他程序员犯下的错误时保护你自己。

本文开始从以数据为中心的编程观点转到以语句为中心的观点上。常用的编程语句有顺序、控制和循环三种基本结构，本文将依次介绍这三种基本结构的使用原则。最后，还总结了一些不太常见的控制结构，如子程序多处返回、递归、关于goto语句的讨论。