OO第二次总结

设计策略的变化

作业上

一开始接触多线程的时候完全没有概念，第五次作业按着之前的电梯的思路写了一通运行起来完全不是想象的那样，最后是选择了推倒重写，才终于抓住了一些多线程的灵光。

策略上

由于最初的时候我是以某一个具体着手，导致了整体的崩塌，我发现要想从微观到宏观至少在我这里是绝对走不通的，于是决定从全局，构思好线程有哪些，他们分别主要有什么工作，构思好整体框架，再往每一个线程里面加细节。

设计上

一定不要贪图一些方便的写法而牺牲扩展性，因为几乎不可能一次成功，所以之后debug过程中有很大概率要扩展程序，如果牺牲的扩展性，那么有可能发现bug却不知道怎么把它改掉，然后放弃掉这一部分，这种无力感是非常难受的。

 

---

 

程序分析

度量分析

第五次作业

设计类图

由queue作为中间传导，将输入和执行进行调节。

Metrics

圈复杂度和嵌套块深度

圈复杂度那里，是判断指令是否正确的老问题，这次推倒重写心态崩了，写了很多无意义的东西还没有判断好。

嵌套块深度是构建主命令和电梯进行运动，完成了部分，因为重写时间不够，这里写的很暴力，所以嵌套很深。

Sequence UML

第六次作业

设计类图

Metrics

圈复杂度

Main,这里我直接在main里判断了输入指令是否有效、需要执行操作的类别等，写的时候条理还算清楚，但是是比较暴力的，所以直接拉高了复杂度。

Sequence UML

第七次作业

设计类图

中间那一堆是课程提供的GUI，肝不动的

Metrics

GUI的draw方法，这个我也没办法

Sequence UML

BUG分析

第五次作业

这一次作业由于推倒重来了一遍，导致很多本来可以避免的bug涌现出来，很多都是关于输入的控制。

前几次作业已经完善的输入控制在这里没有重新构架好，而且推倒重来这种事真的很心态爆炸，而我自测的时候也是拿着正确是输入去测试功能，看到好不容易新生的程序出了结果之后有些过于放松，导致根本没有去管错误输入会怎么样，因此有一些错误输入会把程序崩掉，实在是可惜。

 

第六次作业

这一次的作业给我的感觉是比上一次还要难的，本来好好的多线程任务强行加了一堆文件操作不说，指导书还朝令夕改，搞得作业面目全非。而这一次的作业我错在把最初追踪文件的地方写错了，导致了根本性的错误，只完成了极少数的功能测试，也使我追寻指导书的死抠细节变得毫无意义，这进一步强调了整体框架的重要性。

 

第七次作业

这一次我是从整体考虑的，我将指导书要求的输出抛开不谈，只是将这个系统完整的分析并且从整体上着手构架，最终自我测试的结果还是不错的，虽然在追踪路径上出了一点问题导致无法输出，但从整体上看这只是整个程序中的一点小毛病而已。但是真正的恐怖总在意想不到的地方出现

我最初使用课程提供从gui等文件时，就使用源代码一模一样的东西也不知道为何出现了无法找到地图文件的提示，而源文件是使用的相对路径，我也懒得想原因直接改成绝对路径，问题解决，成功运行（是不是看上去一点问题也没有）。

然后我写好代码提交了，但是最终无效，原因是个人信息，因为直接从gitlab上import生成的文件夹是带学号的。

我从第二次作业在票圈里看到某两位同学大骂个人信息泄露被报无效且其中一位还决定专门下载pdf阅读器以确认自己真的删除了个人信息，再到之后某同学因为在README里写了一个看他描述应该是讲解内容的链接(但是是指向自己的)而被认出个人信息然后无效。我认为我有他们的前车之鉴我不会犯这种问题，结果在这种地方栽了。是能说吃一堑长一智了。

 

---

 

其他总结

关于测试

其实先读readme很重要，如果他readme写的很完备，那么可以先把能想到的测试一口气输进去，要是结果正确，基本上就是一个一个写通过了。如果readme就有含糊不清的或者刻意忽略的部分，甚至直说有什么做不到的，就从简单到困难测ta的程序，很有可能发现很多bug。

 

心得体会

从整体到局部，这是这几次作业最重要的收获。这一点非常关键，有了整体的把控，写起局部就感觉水到渠成，有种“这里就该这么写”感觉。整体分析，就是分析指导书中关于功能的描述，一个程序该怎么运转，它主要的功能有哪几块，每一块再细分，就像是一级一级的索引。