复杂度的衡量:
- 标量一个程序复杂性的方法
1) 若要理解程序你得一次连续在脑中记住多少目标程序语句
2) 程序的复杂性很大程度上决定了要理解一个程序要花多大努力
复杂度的控制方法:
1)早在二十年前,Edager Dijkstra就意识到复杂性的危险
2)一个聪明的程序员总是清楚地知道自己的脑力容量有限,因此他得十分小心谨慎地完成编程任务
3)这并不意味着为了处理很复杂的问题你得增大你的脑力而是说你得想办法尽可能降低复杂性
4)有了复杂性度量数目该怎样判断程序的复杂性
> 把部分程序写成子程序并不能减少整个程序的复杂性
它仅仅是把决定点转移到别的地方,但它却降低了一次涉及到的复杂性
> 既然你的目的是降低一次要在你脑中考虑的问题数目
因此编成子程序降低复杂性的方法是有帮助的
> 首先,你可以做一些动脑筋练习来提高在脑中打底稿的能力
但大多数程序都很大,而人同时考虑的问题一般都不能超过5~9 个
因此靠提高脑子的容量来帮助降低复杂性能力有限
> 要降低程序的复杂性就要求你彻底理解你所要解决的问题
5) 控制流的复杂性很重要,因为它和低的可读性和频繁的出错紧密联系在一起
6)抽象所带来的主要好处是可以忽略掉无关紧要的细枝末节问题,而专注于重要的特性
如果总是在相当于分子的层次上工作,那是不可能建成软件系统的
7)你尽力创造出与解决真实问题某一部分抽象程度相同的编程抽象
# 这种抽象能力使你可以在更高层次上对问题进行考虑而且,不必把神经绷得太紧,就可以一次考虑很多问题
# 一个程序模型越是真实地反映了实际问题.那么,由此产生出的程序质量越好,在多数情况下,关于项目的数据定义要比功能稳定得多,因此应象面向对象设计一样,根据数据来进行设计,这可以使设计更稳定
8)好的注释不是重复代码或解释它,而是使代码更清楚
# 注释在高于代码的抽象水平上解释代码要做什么事
# 图示法是另一种有力的启发工具,一幅图抵得上一千个单词
复杂度模型:
> 相关图例
然而对任何一个特定人来说,其大脑的能力总是相对固定,用图中的水平线来表示。一旦那条复杂度曲线与这条水平线相交并且超出水平线之后,系统的复杂度也就增加到了个人的头脑不能继续实施“完美无缺式”控制的地步