20220516数据结构绿皮书读书笔记

20220516数据结构绿皮书读书笔记

大型项目的实验和需求分析最终应当是需求的正规陈述,这种陈述成为用户和软件工程师的主要表达和交流方法,来让软件工程师尝试理解并建立标准。
1.功能性需求
2.系统的假设和限制
3.维护需求
4.文档需求
需求规范陈述软件应该做什么,怎么做。且需求应当让用户和软件工程师同时理解,他们将形成后面阶段设计、编码、测试和维护的基础

编码
在合适的的时间启动编码

编程原则
在需求准确和完成之前不要开始写代码
Act in haste and repent at leisure. Program in haste and debug foreve。不翻译,翻译不出这个意境
从0开始通常比在旧程序打补丁要容易

正如我们自上而下地设计,我们应该自上而下地编码。一旦顶层的规范是完整而精确的,我们应该开始对高抽象层次的Class和方法进行编码,并通过包含适当的Stub来测试它们。如果发现我们的设计有缺陷,我们可以轻易的修改它而不至于让低级别的方法白写

如果一个程序的10%都要做修改,那是时候重写它了。相比在一个大程序上重复的打补丁,很多的bug都是由同一个地方导致。

项目练习1.6

1.幻方判断和生成
1.1.写一个程序读取一个矩阵,判断是否是幻方
1.2.写一个程序,用下面的方法生成幻方
方法仅对奇数大小的幻方有效,开始把1放在第1行中间然后依次填写2,3,4。。。顺序如下:
向上、向右,按对角线方向,当你遇到了第一行则跳回到最后一行,当你遇到最后一列则跳回第一列。当被占用的时候向下移动一格再继续填写

结果如下
17 24 1 8 15
23 5 7 14 16
4 6 13 20 22
10 12 19 21 3
11 18 25 2 9

2.一维的Life模拟游戏
把游戏改成仅在横着的单元格中进行,规则和二维类似,在细胞的两侧2格内都是邻居
当死亡的细胞存在2或3个存活的邻居时复活,当存活的细胞存在0,1,3个邻居存活时死亡(因此死亡细胞存在0,1,4个邻居的时候依然是死亡,存活细胞存在2,4个邻居时依然存活)
设计,编写,测试一个程序,模拟一维的Life游戏

3.打印日历
不赘述,麻烦的一B,到现在做日历项目的我还有没搞定的高效算法

总结
1.为了改进你的程序,先review逻辑,不要在一个垃圾的算法上做代码的优化
2.在你的程序正确和工作之前,不要开始优化
3.除非绝对必要,否则不要优化代码
4.保持你的方法足够的短,任意一个方法都应该在一屏内(屏幕大的好处)
5.在开始写代码之前,确认你的算法是正确的(我要是能提前知道对不对,我早去搞算法了,实际需求里大概率我没法100%证明正确性)
6. 验证你算法最复杂的部分
7. 保持你的逻辑简单
8. 在你决定解决问题之前,确认你理解了你的问题
9. 在写代码之前,确认你理解了算法(我要是理解,我还用动手写?)
10.当遇到困难的时候,拆分问题来独立思考。(不幸的是很多时候拆分问题本身就是个困难)
11. 描述一个问题时出现的名词暗含了关联的Class名称,动词往往对应着方法名
(需求分析常用套路,前提是需求文档无歧义表达,否则需要人工去重。这也是个消除歧义的好时机,可能会让产品发现自己表达的错误和歧义)
12. 给你的每个方法细心的添加注释和文档(想啥呢,不存在的hhh)
13. 给每个方法细心的填写前提条件和执行效果
14. 在方法开始的时候进行错误检查,保证前提条件是满足的
15. 每使用一个方法的时候,问你自己为什么你知道它的前提条件是满足的
(实际情况是管它满不满足呢,写了再说,大概率不会出问题的。为啥呢?我就是这么自信,我相信我对数据结构的设计有足够的容错性,做的前提检查足够的严谨,对代码执行路径的静态分析足够正确,才有胆量这么干)
16. 使用stub桩、driver测试用例、黑盒、白盒测试来简化调试
17. 使用大量的脚手架代码来帮助定位错误
18. 在用数组的时候,注意index需要减1,永远使用边界值检查使用了数组的程序
19. 保持你的程序有良好的格式,因为书写和debug的时候会更加容易
20. 永远保持你的文档和代码的一致性,当阅读一个程序的时候以代码为准,而不要轻易相信注释
(典型的自己懒得写,要求别人写。所以最好的办法就是不写,然后让代码自解释)
21. 小黄鸭调试法,尝试向别人解释你的代码,这会让你更好的理解代码逻辑
(当别人问问题时,也可以诱导对方使用这种方法,描述自己程序的逻辑和他自己的想法,然后大概率就没问题了)

明天开始看堆栈,难度开始逐渐提高
mark 目前是49页,pdf是67页

0 Comments
Leave a Reply