tyst08的专栏

凡事俱在人为，程序员也是人，人的性格会对程序员的工作产生不同的影响。 很多人认为聪明是程序员的一大优势，其实不然，往往是聪明反被聪明误。因为现代软件的复杂性，再聪明的程序员也无法在脑子里同时理清所有的问题，所以真正牛X的程序员是那些认识到了自己的脑子容量有限，而采取了对应措施的人，比如降低软件复杂性。这也就是说好的程序员要谦虚，认识到自己的不足，这样才能进步，这道理在哪里都是一样有效。

说到注释，总是有争论要不要注释，有人喜欢尽可能多的注释，有人根本不写注释。作者的意见是适当的注释是需要的，但不要重复代码，不好的注释还不如不注释。总结性的，描述意图的注释是好的注释，它会告诉读者代码所没有提供的信息，是我们的目标。而另一大目标就是写出自注释的代码，无比清晰，根本不需要注释。这样可以大大节省读注释的时间，分析注释与代码是否一致的时间，从而提高效率。 具体的方法有很多，篇

说到布局和风格，首先要阐明的一点就是代码是写给人看的。自然，代码写出来是要给计算机去运行，但在编译器如此发达的现在，这个不是问题。问题是代码还要给人看，被人维护和修改的。一份代码被读的时间要远远超过它被写出来的时间。所以，可读性可维护性是写代码时必须要注意的，布局和风格就是讲怎样布局，采用什么样的风格使得代码更易读，更易理解。 用好的布局和风格写出来的代码视觉效果很好，可以很好的展示程序

编程工具多种多样，有很多是可以很好的提高效率的。一一介绍觉得没有必要，这里只是附上一个checklist，可以提个醒，看看有哪些是可以用而忘了用的。另外就是没有合适的工具时，别忘了考虑自己写个工具来用。Checklist: Programming ToolsDo you have an effective IDE?Does your IDE support outline view

集成是把各个分散的软件部分合并成一个统一的系统的过程。好的集成方法能带来很多好处，比如便于诊断错误，提高代码质量，更可靠的预测，更好的用户关系，更高的士气等等；而坏的集成方法可能导致最后系统无法完成。 集成的方法可分为两大类，一类是先把所有的部分都准备好，然后一起集成；另一类是增量集成，也就是先搭个架子，然后一部分一部分往上加。第一类的问题在于一下子引入了太多的耦合，关系太复杂，出了问题

构建的管理基本可以分为代码的管理、配置的管理、进度的管理、质量的管理和人的管理。 代码的管理核心就是鼓励写出好的代码，不管用什么样的方式。可以制定代码标准，用版本控制的工具，可以用各种技巧比如结对编程，审阅，张贴好的代码示例等等。 配置的管理就是对变化的管理。各种各样的变化，需求的，设计的，代码的等等，怎么让它们的影响最小，保证项目可持续完工。方法很多，详细的可参考下面的che

这一章内容很少，要说的核心就是一点：项目大小对软件开发的影响不是成比例的，写一个20K行的程序所花的时间远不止写一个2K的程序所花时间的10倍。项目越大，沟通成本越高，缺陷率越高，生产率越低，构建所占的时间比例越小，架构设计、系统测试等占的时间越多，文档化工作越多。

前面讲了重构，重构的目标是改善代码的可读性可维护性。这里讲的代码调整针对的主要目标是软件的性能。很多情况下，性能和可读性可维护性是相互矛盾的指标，所以在做代码调整之前，一定要想好它真的是需要的吗？提高软件的性能有很多种方法，列在下面的checklist中，代码调整是其他的方法都不行了才不得不用的方法。总之，慎用！Checklist: Code-Tuning StrategiesOvera

重构是改变软件的内在结构从而让其更好理解更容易修改。在软件开发过程中随处可见它的身影。很多地方都可以用重构来改善，比如重复的代码，太长的函数，嵌套很深的循环等，下面是一个比较完整的list，需要重构的原因：Checklist: Reasons to RefactorCode is duplicatedA routine is too longA loop is too lon

调试，号称是软件开发过程中最耗时的工作，无数的开发人员在上面花费了无数的时间。毫无疑问，想办法提高调试的效率是非常有用的。那么关键在哪里呢？就是要用科学的方法。 相信所有的开发人员都有这样的经历：要改正一个缺陷，试试改掉这一句行不行，再试试改掉那一句行不行，试来试去，越改越多，最后自己都迷糊了，不知道改了些什么。也许一下子可以了，也许还是不行，还是不知道为什么行或者不行。这个过程会花费很

开发人员测试不同于测试人员测试，前者是白盒测试，后者是黑盒测试。开发人员测试主要包括单元测试，组件测试，集成测试等。不管哪一种，测试的目的都是为了发现缺陷。所以，既然测试，首先就要认为一定会发现缺陷，若是总想着找不到缺陷，就会真的找不到缺陷。测试这件事，要从一开始就考虑，像测试用例，早晚都是要写的，不如先写，想用就能用，还能更早发现需求是否有问题。 作者在书中通过一个例子详细的列出了各种

这一章介绍了合作开发的一些常用方法。所有的合作开发都基于这样一个前提，即任何开发人员都有自己的盲点，大家的盲点不一样，所以合作起来就可以减少盲点，也就减少了开发缺陷出现的几率。合作开发的方法有很多，结对编程，正式审查(Formal Inspections)，非正式审阅，读代码，读文档，几个人讨论等等，形式多样，不必拘泥。作者在书中重点讲了前面两种。 结对编程相信大家就算没用过也至少有所耳

软件质量可以分为两类，外部的和内部的。外部的软件质量是对用户来说的，包括正确，易用，高效，可靠，完整，适应各种环境，准确，健壮。内部的软件质量是用户不关心，只有程序员才关心的，包括可维护性，灵活性，可移植性，可重用性，可读性，可测试性，可理解性。当然，程序员不仅关心内部的质量，同时也关心外部的质量，而这内外的区分有时候也不是那么明显，因为内部质量可能会影响到外部质量。要注意的是列出来的这些指标有些

这一章类似于这一部分的一个总结。阐述了控制流程中常见的问题。比如布尔表达式，深层的嵌套等。 布尔变量和布尔表达式是我们程序控制中不可或缺的组成部分。处理好它们，程序的控制流程会清晰明了，可读性，易用性都大大增加。具体说来，有下面这些值得注意： 用true和false，不要用1和0.用if(a>b)，不要用if((a>b)=true)。 简化复杂的布尔表达式。可以增加

表驱动方法是编程中很常用的一种方法。它的主要用途是简化复杂的逻辑判断，使程序简洁易懂，可读性，可维护性都大大提高。 用表的时候最主要考虑的是如何去访问表，一般来说，可以专门写一个函数来访问表，这样即使以后要改，也很方便。访问表的方法包括直接访问，索引访问，阶梯式访问等等。 直接访问是最简单最常用的方法。把需要处理的情况都列在一个表中，哪种情况来了，直接调用就好了。复杂一点的情况

所谓不常见的控制结构，其实也不是那么不常见，只是相对顺序结构，条件结构，循环结构而言。主要有三种：多重返回，递归，goto。一个一个说。 多重返回其实还是蛮常见的，就是一个函数里有多个return语句。其目的主要是增强可读性。比如有时候一些错误处理检查条件嵌套太深，不如不满足条件就马上返回。还有一个好处是可以提高效率，比如有些函数得到结果了就可以马上返回，后面那些其他的情况都不用再处理。

循环是相对来说复杂一些的控制结构。大体来说分为两类：For循环和While循环。像foreach之类的可以归到for类里，do-while之类的可以归到while循环类里。如何选择呢？一般来说，知道循环的次数，用for，否则用while。For循环相对来说比较简单些，所以尽量用它。 选好了之后，说说如何用。第一原则，简单！能写多简单就写多简单。简单才不容易出错，才易读，易维护。有了第一原

这一章依然比较简单。条件语句主要有两类，if-else，和switch-case。 总体的原则都是要提高可读性，降低犯错率，提高效率等。 对于if-else语句来说，要注意的有这么几条：一、先写正常情况下会发生的条件，这样读的人一看就知道正常情况下会怎么样，可以很容易的知道这段代码的功能，同时执行效率也会提高，因为正常的情况会是最可能发生的情况。二、把正常的情况放在if后面而不

从这一章开始学习语句(statement)级别的一些方法，注意事项。 这一章的内容相对来说很简单，以至于很少有书会专门提到这些。然而归纳总结一下还是能有所提高。 组织顺序排列的代码，核心问题就是一个，如何处理好各行语句之间的依赖关系。 如果依赖关系存在，必须要按某个顺序来组织语句，就要想办法让这种依赖关系表现得很明显，比如调整顺序，用合适的函数名，用合适的参数名等等。

所谓不常见的数据类型，就是在现代的面向对象的编程中不提倡从而不常见的类型。主要有三种：结构体(structure), 指针(pointer), 和全局变量。 结构体相对来说还是比较简单，它可以看做是只有公有成员变量的类。其主要用途就是把相关联的数据组织到一起，可以把大堆的数据分组；可以简化对一大块数据的操作，比如复制，交换；可以简化参数列表；从而简化了维护的工作。当然，也可以考虑用类来实

这一章没什么好说的，需要注意的checklist里都列出来了，用的时候一条一条对着看就行了。Checklist: Fundamental Data TypesNumbers in General Does the code avoid magic numbers? Does the code anticipate divide-by-zero errors? Are

这一章对变量名的讲述是相当的具体，作为一本手册真是名符其实。我不想在这里再重复那些具体详细的方法，可以去翻书，或者按照后面附上的checklist一条一条去检查。这里主要讲讲为什么要有那么多方法。 原因就是增强程序的可读性，从而降低程序的复杂性。所有的总总方法都围绕这一目的展开。像变量名要能准确完整的描述这个变量表示的内容，要描述它是什么(what)，而不是怎么做(how)，越具体越好，

从这一章开始，将讲述变量有关的内容。这里所说的变量是广义的，包括系统自带的类型像整数，数组等，也包括各种自定义的对象。 这一章讲的是一些基本的用法，定义，初始化，生存范围，绑定时间等。 定义要注意的是一定要显式定义，有些语言支持隐式定义，像VB，最好不用，可能出错。 初始化是最容易出错的地方，有一些规则可以尽量减少出错的概率。一、定义的时候初始化。二、第一次使用之前初

伪码编程的概念相信大家都知道，就是用伪代码，也就是描述性的语句来表示一个程序的实现过程。遗憾的是，包括我自己在内，用的人不多，就算是用，用得也不好。看完这一章之后觉得，以后还是要好好用这个工具。 伪码编程有很多好处，首先，它是用类似于自然语言的陈述，有利于我们理清思路，到底这个类，这个函数要干什么，怎样做。伪码不要用程序语言的语法，尽量要用自然语言，这样可以把它翻译成任何程序语言。伪码的

防御式编程，顾名思义，就是保护自己不受其他人错误的影响，防御那些意料之外的错误。比如对一个函数来说，即使它被传递了一个错误的数据，它还是可以继续正常工作，哪怕这个错误数据是其它函数的错，好的程序永远不会输出垃圾信息。防御式编程帮助我们更容易发现错误，改正错误，当然，最好是一开始就不要引入错误，也就是可以利用一些方法，规则尽可能减少错误的产生。好了，下面说方法。 首先，要抵御外来的侵略，也

讲完了高质量的类，第七章就接着讲了高质量的函数。 要创建函数的原因像创建类的原因一样有很多：降低复杂性；引入便于理解的抽象；避免重复的代码；支持子类；隐藏顺序执行的过程；隐藏指针操作；增加可移植性；简化复杂的布尔逻辑；提高性能等等，最核心的也还是降低复杂性。有时候我们不要因为一个函数只有一行代码就不去创建它，有可能这一行代码会在很多地方重复使用，而万一哪一天你要改它，一个杯具就此产生。

接口设计好了，实现也不能含糊。下面就来讲实现相关的问题，包含，继承，成员变量和成员函数，构造函数等。 先说包含与继承。包含是“有”(has a)的关系，继承是“是”(is a)的关系。这还是很好区分的。包含也可以通过私有继承来实现，但这种方式应该是实在不得已才为之的，因为这样做会破坏封装，增加复杂性，不提倡。无论是包含还是继承，都要注意一个著名的数字7±2。这个数字号称是一个人能同时记住

第六章是讲如何创建高质量的类。首先作者介绍了一下抽象数据类型ADT(Abstract Data Type)。一个ADT就是一些数据和对这些数据的操作的一个集合。在面向对象的程序语言中，可以用一个类来实现。当然，类比ADT多一些东西，像继承，多态等。面向对象的语言也会自动支持多个实例，用起来很方便。若是非面向对象的语言，那么实现ADT就要多考虑一下了。若是有多个实例，可能要在ADT的操作中增加一个I

前面一节的启发主要专注于设计的属性，也就是最终的设计是什么样的，这一节的启发则专注于设计的实践，即通过怎样的步骤可以得到好的结果。同样是启发式，所以也有各种各样的方法。 1、迭代。一般来说第二次的设计都会比第一次的好，而且我们会从每一次设计中学到东西，从而提高整体的设计水平。 2、分而治之，各个击破(Divide and Conquer)。人脑的容量，处理能力都有限，对于大的问

各种启发式设计的方法：1、寻找真实世界中的对象 主要包括下面几个步骤： 确定对象以及它们的属性，包括方法和数据； 确定每个对象是干什么的； 确定每个对象可以对其他的对象做什么； 确定每个对象的哪些部分是公开的； 确定每个对象的接口。 这几个步骤不一定按这个顺序，可能是反复确认。2、形成一致的抽象(Form consist

第五章是讲构建中的设计 (Design in construction)。 第一节介绍了设计中面临的一些挑战。设计是一个"wicked"的问题，就是需要通过解决或者部分解决才能定义清楚的问题。作者特别举了Tacoma Narrows大桥的例子来说明，不等到这个桥被建好，并被风吹倒，设计者根本不会知道设计的时候还要考虑风的影响。设计也是一个"Sloopy"的过程，过程中会犯错，一个好的方案

第四章主要讲了在创建过程中关键的几个决定。 第一，选择编程语言。高级语言会带来更高的生产率和质量。不同的语言在表达概念方面有不同的特点，而Sapir-Whorf假说认为，人必须知道要表达的思想的词汇才能想到要表达的思想；如果不知道那些词汇，人就不能表达那个思想，甚至根本不会产生那个思想。所以多学几门编程语言没啥坏处，可以提供更广阔的视野，激发更多的好想法。 第二，编程约定。这一

花了几天时间看完了第三章。从这一章用木匠的这条谚语——Measure Twice, Cut Once——作为标题，可以看出这一章的核心内容就是讲要做好充分的准备。而准备的终极目标就是降低风险。 首先当然是解释为什么。我相信有过软件开发经验的人都已经不再对此怀有疑问。作者在书中还是很认真地从逻辑，类比，以及用数据作出了解释。对此结论没有疑问的，可以略过。 有用的在后面，当我们忘了

看完了前两章。第一章主要在讲什么是软件创建(Construction)。第二章着重在讲如何通过一些比喻更好地理解软件开发。下面详细说。 软件开发主要包括的方面：1. 问题定义（Problem definition）2. 需求分析（Requirements development）3. 创建计划（Contruction planning）4. 总体设计（Softwa

所有的人都说这本书是一部经典，本着读书先读经典的原则，我优先选择了这本书作为构建知识体系的第一步。 按作者所说，这本书会缩小理论与实践的距离，很多问题理论上都已解决，只需要我们把它应用到实践中。 这本书是一个手册或者指南，能帮助我们创造高质量的软件，更快更好的完成工作，它提供了在软件开发过程中可能会遇到的各种问题的解决方法，以及若想深入研究的更多参考资料。 这本书甚至