南昌航空大学-软件学院-24201911-杨亿淼第一次blog作业

• 前言
  本次blog主要是针对前三次pta上电梯的题目进行总结和反思
  1. 关于题目的知识点
     三次题目都是紧紧围绕着java面向对象思想进行考察的，每一次迭代都比上一次提出了更高的要求。第一次是初识电梯题目，了解底层的逻辑算法，并没有特别针对面向对象思想的考察。
     第二次就开始进行分结构，进行结构上和类的设计上的进一步完善。第三次则是对题目要求的进一步考察，比第二次更加精细，对细节的把控能力上升到了另一个阶段。
  2. 关于题目的难度
     在我所接触的题目中，这种难度的题目还是第一次见，除了之前做过的管理系统，这种需要迭代更新的题目对我来说无疑是一个巨大的挑战。但是题目并没有难到写不出来的程度，只要肯花时间研究题目调试，还是能够写出题目的。
• 设计与心得

1. 第一次电梯题目

上图为第一次设计的类图
分为了两个类：1、电梯类用于处理电梯的移动和数据处理。2、外部请求类用于记录外部请求的数据传入
此外还使用了枚举，用于存储电梯的运行状态。
由于第一次写没有经验，导致了程序的结构混乱，并没有遵循单一设计原则，而是把所有东西都加在了电梯类里进行处理。main函数里主要是使用正则表达式进行对数据的入队，处理数据的输入。

复杂度分析：Avg Depth深度复杂太高了，在主要的处理方法中使用了太多的if-else嵌套语句，逻辑混乱，使代码的复杂度大大提升。分支语句占比 24.4% ，说明代码中条件判断等分支逻辑较多，逻辑控制较为复杂。

在开始时，我感到无从下手，于是我添加了CanReachInternal这个方法，使得判断能否到达下一内部楼层变得更加方便，但是仅仅是做到了这一点，到主要的判断逻辑时，仍然一头雾水，只能无脑的去堆砌if-else语句，现在去看我的代码时，根本理解不了里面的逻辑。
并且程序也没有进行注释，使得代码不适合阅读。
2. 第二次电梯题目

上图为第二次的类图.
这一次分为了四个类1、RequestQueue用于包含了内部队列和外部队列和对这两个队列的处理方法2、ExyernalRequest这个是外部队列的楼层和方向记录3、Elevator主要对当前楼层和方向的记录输出4、Controller管理类，以及两个枚举类用于记录电梯的运动状态和运动方向。

复杂度分析：main函数没有太大的变化，都是对数据的分割传入。与第一版比较，把一些类从第一次中拆分出来，使得程序并没有像第一次一样牵一发动全身，分支语句占比 20.4% ，最大复杂度达 21 ，说明该方法或代码部分逻辑复杂。说明代码中条件判断等分支逻辑相对较多，代码逻辑控制较为复杂。注释行占比仅 1.2% ，注释严重不足。

从雷达图可以看出，深度和复杂的仍然超出了正常的指标，说明代码的根本问题并没有改变。即使拆成了几个类，核心问题并没有解决。

这一次我也仅仅是讲一些类拆出原代码，并没有去过多的修改我的判断逻辑
3.第三次电梯题目

以上为第三次的类图
相较于第二次加入了乘客类，实现了单一职责原则，使程序的结构更加合理

复杂度分析：由图分析总结可知，这一次我将算法进行了大换血，将原来复杂的代码给拆分开，使得程序更有条理。复杂度也大大降低，随之而来的便是代码的长度的加长。最大代码块深度为 5 ，意味着代码中嵌套层次最深为 5 层，Percent Lines with Comments为 25.5% ，即有 25.5% 的行包含注释，说明代码有一定注释量，但是还有提升的空间。

在第三次的书写中，我问了好几个同学的思路，他们大多的核心思路都是进行方向是否一致的分类，然后进行判断返回对应的targetFloor，我的思路与他们不同，我是通过电梯的能否到达下一内部或者外部楼层进行判断，然后比较计算出下一楼层，我把方向的判断放进了能否到达下一楼层的函数里，节省了大量的代码。

然后我又把重复的代码进行删减，原来在改变楼层的情况里多写了一步，在改变方向后在那个方法里再次判断下一目标楼层，会出现判断失误的情况，由于我在问了别人的四种改变电梯方向的情况后，检查代码完善思路，并且根据同学的各种楼层情况进一步完善，最后以我的思路完善了各种情况，到最后也只是代码的长度变得长一些，并没有多层嵌套的情况，使得程序更加简洁易懂。

• 踩坑心得
  1、第一次的逻辑计算代码

第二次的逻辑计算代码

这两次的代码逻辑特别混乱，几乎是在测试用例对不上时，就开始if-else嵌套解决问题，导致程序就是各种条件堆积来的，后期根本没办法维护和阅读。

2、第二次的题目信息

对代码的错误视而不见，在发现错误后还是只是在原有的基础上进行改进，而不是重新构思优化结构
3、对时间的利用率不高，在在最后一次的电梯题目中，截止前一天的半夜两点提交的，从下午六点做到半夜两点，这反映出我没有合理的安排时间。
4、对代码的长度没有进行考虑，在最后一次时，我对代码进行了重构和优化，把所有情况都拆开来写，一些相同的情况也写在了一起，代码大量重复，最终长度超限

5、类的定义很奇怪，有些类本不应该出现在那个地方我偏偏使用它定义强行合理化，这导致有时程序会出现一堆错误。

• 总结
  这也是我第一次对一个题目进行死磕。在开始时并没有当成一回事，只是想着敷衍了事，越到后面愈发重视这个题目。在第二次迭代时，正值清明节假期，玩耍的心早就把第二次迭代忘到脑后，三四天没有打开电脑写代码，到截止日期了也只是在原有的基础上进行改进，导致只过了一半的测试点。到第三次时，我开始转换思路，但是迟迟过不去第一个和第二个测试点，我开始大规模的重铸结构，结果便是代码长度超限制，无法提交。我还是找回原来写的代码，开始推演，找到N多测试点开始手动计算，最后在测到第13个测试用例时，只是在一个条件上加了一个“！”号，就得到了满分，我从未想过我离成功就差了一个感叹号，如果我没有坚持下去一直调试程序，也许也不会得到满分。与其说这一次的题目是对面向对象思想的考察，不如说是对自己心性的一次磨炼。我在这次迭代的题目中学到了很多，都是我自己在平常中无法训练的东西。要对自己充满信心，别人都能干成的事情为什么自己干不成，况且又不是什么旷世难题，朝着正确的方向，坚持走下去，总会得到收获。
• 关于以后的学习计划
  多训练正则表达式和队列，这些都是处理问题的强力工具。
  多思考类的设计原则，使得问题变得可拆分，具体化有目的的抽象成编程解决的问题。
  养成阅读错误的习惯，及时改正程序中出现的错误。
  多写注释，在程序的书写中养成边写程序边写注释的习惯
  悟已往之不谏，知来者之可追