《代码大全》阅读笔记

阅读这本书可以先看每章后面的关键点，如果有自己感兴趣的，再去读前面的细节



******不一定要赞同文中所举的隐喻，但它揭示了一种思考的方式，隐喻可能并不严谨，但却能给我们灵感
做好早期的准备似乎跟采用瀑布式还是跌代式开发没有必然的因果关系
瀑布式：有时，返工带来的好处相比它所造成的代价，也许是微不足道的，更何况世界上没有完美的东西，我们只有在有限的范围内，改善它。就像你改正了系统设置的一处不足，但并没必要对整个系统重做一次ghost，不值。
跌代式：在客观条件、个人能力有限而确实不能保证早期准备的可行性时，必要时我们的确得推倒重来，所以跌代式在这个时候是合适的。


******精心计划，并非意味着事无巨细的计划或过度的计划
一项规划得体的项目能够提升你在后期改变细节的能力

******
感觉前期准备中的架构设计、确定跌代式还是瀑布式开发、需求（按兴趣度排序）比较适合阅读

******
适度的前期准备：如果前期准备做的太少，可能导致后期“大规模”的返工 ，如果做的太多，可能前期的一些需求和计划后来证明是无效的，同样阻止了构建活动的顺利进展。
大多数情况下，我们都相信都相信前期准备的重要性，但我们不知道现在是否已经做的够好和如何做的更好，我们只能立即开始编码，并期望前期准备出的错比较少

普通的商业系统更适合用跌代式开发，非正式的流程能节省更多的时间和成本，可靠性要求很高的更适合用瀑布型开发，因为需求稳定是“超高级的可靠性”的必备条件之一

如果没有做好前期的准备，代式式与瀑布式开发都会增加很多的成本，虽然前者强一点，但也是半斤八两，就像把1个蛋糕分成二十份，虽然每份看起来很小，但实际上还是一份蛋糕

关于权衡采用跌代式还是瀑布式开发的几个因素参见“在序列式开发和跌代式开发间做出选择”一节

 ------认识设计
设计是一个了无章法的过程：你很难判断何时设计做到何时才足够好
设计受到诸多限制（有限的资源、时间、空间），所以需要人确定取舍、调整顺序
设计是一个启发式的过程


软件的首要技术任务：5.2管理复杂度（参见原文）

5.3 启发式方法
------信息隐藏
信息隐藏是结构化程序设计和面向对象设计的基础之一，它强调的是隐藏复杂度，自然就增强了程序的可读性和易维护性
强烈推荐阅读5.3信息隐藏的一个例子
如果你的类包含了太多的子程序，在信息隐藏方面，类中的数据与全局数据的区别就变得模糊起来。
***可以察觉的性能损耗     似乎没有解释出信息隐藏时是可以较容易的防止性能损耗的
***信息隐藏的价值    很好的说明了对象并非就适合用来隐藏信息，更进一步说明了：遵守一个原则，常常比遵守满足这一原则的技术更重要
------找出（并应对）容易变化的区域
指出了一些易变却可能被忽视的部分
预料变化应把精力放在那些很有可能发生的变化上
------保持松散耦合
指出了一些衡量耦合程度的标准
一个模块越容易被其它模块使用，那么他们之间的耦合关系就会越松散
***列出了一些较紧密的耦合
传递控制标志
使用全局变量
对被调用模块的了解超出了它的接口
从理论上证明了松散耦合的必要性：提供了一个简单易用的接口/抽象，降低了整个系统的复杂度。
******其它一些设计启发式方法：
高内聚性（敏捷软件开发中也认为：一个类只应该有一个职责）
构造分层结构
为测试而设计
避免失误
最有效的设计原则之一就是不要卡在单一的方法上。
你无须马上解决整个设计难题。既然现在实在没有思路，那就等有思路的时候再来解决吧

5.4 设计实践
------跌代
随着认识的逐渐加深，做第二遍甚至第三遍设计常常能得出比第一遍更好的方案
------自上而下还是自下而上
即分解还是合并，有些时候需要两者的相互协作
------试验性原型
用最少的、可以扔掉的代码，来验证设计能否满足某个特定的实现细节
5.5 对流行的设计方法的评论
你在应用某种设计方案时越教条化，你所能解决的现实问题就越少。
一些好书
《设计模式》
《设计模式解析》
《面向对象软件构造》
《UNIX编程艺术》
《UML和模式应用》

6 类------强调对数据、及其操作的抽象
用来隐藏实现的细节，甚至数据的细节
简单来说，一个类应该只提供一个或一组明显相关的功能，即强调功能的高内聚性。并且，类的接口在数据抽象的意义上应该一致的。
尽量通过语法来说明接口，这样编译器可以强制的要求这些说明被满足，而不是通过注释等一些编程约定，那样很容易被误用