代码大全2（读书笔记9）

101、多次尝试的好处

当你首次尝试得出了一个看上去足够好的设计方案后，请不要停下来！第二个尝试几乎肯定会好于第一个，而你也会从每次尝试中都有所收获，这有助于改善整体设计。在大多数情况下，用一种就去来解决问题会为你带来一些新的洞察力，从而帮助你使用另一种更好的方法来解决问题。

 

102、“自上而下”与“自下而上”的合作

自上而下和自下而上设计并不是互相排斥的―――－你会益于二者的相互协作。设计是一启发式（试探）的过程，这意味着没有任何解决方案能够保证万无一失。设计过程中充满了反复的试验，请多尝试些设计方法，直到找到最佳的一种。

 

103、设计方法教条化

综观软件设计的历史，你可以看到大量的、相互矛盾的设计方法被各自的支持者们所鼓吹。当我在20世纪90年代早期发表《代码大全》第1版时，设计方案的信徒们正在鼓吹说在着手编码之前，应该完善设计的每一处细节。这种推荐事实上根本没有任何意义。

当我在21世纪前十年的中期撰写现在这个版本时，一些软件学者正争辩说根本不需要做任何的设计。“预先做大量的设计（Big Design Up Front）是BDUF”。他们说，“BDUF很不好。你在着手写代码之前最好不要做丝毫的设计！”

十年之内，设计的钟摆就从“设计一切”摆动到了“不做设计”。不过，BDUF的替换方案却不是不做预先设计，而预先做一点设计，或者预先做足够的设计。

那么你怎样才能判断出需要多少设计才够呢？这是一个主观判断，没有人能完美地回答它。不过，在你没有足够的信心去判断最佳设计量的时候，请记住有两种情况一定是不对的：设计所有的细节和不做任何设计。这两个由位于立场两端的极端主义者所倡导的做法，恰恰被证明是仅有的两个永远是错误的做法。

正如P.J.Plauger所言，“你在应用某种设计方法时越教条化，你所能解决的现实问题就会越少”。请把设计看成是一个险恶的、杂乱的和启发式的过程。不要停留于你所想到的第一套解决方案，而是去寻找合作，探求简洁性，在需要的时候做出原型，迭代，并进一步迭代。你将对自己的设计成果感到满意。

 

104、设计类前的思考

在考虑类的时候有一种很好的方法，就是把类看做一种用来实现抽象数据类型的机制。每一个类应该实现一个ＡＤＴ，并且仅实现这个ＡＤＴ。如果你发现某个类实现了不止一个ＡＤＴ，或者你不能确定究竟它实现了何种ＡＤＴ，你就应该把这个类重新组织为一个或多个定义更加明确的ＡＤＴ。

 

 

105、在编写代码的时候，你要经常想着，那个最终维护你代码的人可能将是一个有暴力倾向的疯子，并且他还知道你住在哪里。

 

106、测试的心态

找到错误，是自己提升的一个很好的机会。因为自己的错误，往往具有有普遍性与针对性。

测试发现缺陷的记录有助于你归纳出程序中最常见错误的类型。你可以用这一信息去选择适当的培训课程、指引今后的技术复查活动，设计未来的测试用例。

 

107、改动程序前的思考

当改到程序时，要思考这些改动的影响范围，以便于改动后有针对性的测试，而不是把整个程序再全部测一遍。

 

108、子程序可访问级别

　　当你在犹豫某个子程序的可访问性应该设为公用（public)、私用（private)抑或受保护（protected)时，经验之举是应该采用最严格且可行的访问级别。

 

109、碰到不懂使用的类的方法

　　如果仅仅根据类的接口文档还是无法得知如何使用一个类的话，正确的做法不是拉出这个类的源代码，从中查看其内部实现。这是个好的初衷，但却是个错误的决断。正确的做法应该是去联系类的作者，告诉他“我不知道该怎么用这个类。”而对于类的作者来说，正确的作法不是面对面地告诉你答案，而是从代码库中ｃｈｅｃｋ　ｏｕｔ类的接口文件，修改类的接口文档，再把文件ｃｈｅｃｋ　ｉｎ回去，然后告诉你“看看现在你知不知道该怎么用它了”。你希望让这一次对出现丰接口代码里，这样就能留下来让以后的程序员也能到。你不希望让这一次对话只存在于自己的脑海里，这样会给使用该类的调用方代码烙下语义上的微妙依赖性。你也不想让这一次对话只在个人之间进行，这样只能让你的代码获益，而对其他人没有好处。

 

110、代码重用

　　ＮＡＳＡ在其项目结束时挑出了可供重用的备选代码。然后，他们进行了必要的工作来让这些代码可以重用，这些工作或被当做是主项目后期的一个特殊项目或被当做是新项目的第一个步骤。