第一次blog作业

前言

通过本次大作业的学习我收获了很多

1.熟悉了Java基本语法
2.初步建立起了面向对象的设计思路
3.初步感悟了对于迭代和更新的设计
本次大作业主要运用了数组的集合框架，通过内外部数组的比较来确定电梯的运行方向和楼层，同时实现电梯与乘客请求不同类之间的相互协作
本次三次作业的题量不大但是三次作业的难度对我来说还是比较大的，因为主要卡在了第一次作业的运行超时导致不知所措

第一次作业
目标:编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
第一次作业的类图:

方法分析:

代码分析:

文件数量：共 2 个文件 。
代码行数：总计 278 行 。
语句数量：有 170 条语句 。
分支语句占比：25.3%，说明代码中条件判断等分支逻辑占比较可观 。
方法调用语句：48 条，反映了代码中方法间的调用频繁程度 。
带注释行占比：仅 3.6% ，注释过少可能影响代码可读性和后期维护，需适当补充注释。
类和接口数量：有 4 个 。
平均每个类的方法数：2.75 个，表明类的职责划分相对较为均衡，但可能存在类功能不够单一的情况。
最复杂方法：是 Main.main () ，复杂度高达 64 ，过高的复杂度意味着理解和维护困难，可考虑拆分重构。
最大复杂度：64 。
平均复杂度：11.18 ，整体代码复杂度偏高，开发和维护难度较大。
最大块深度：9+ ，平均块深度 4.53 ，说明代码嵌套层次较深，可优化逻辑结构减少嵌套。

改进建议：
注释占比极低，严重影响可读性与可维护性；分支语句占比较高，逻辑可能较为复杂；Main.main () 方法及整体平均复杂度偏高，最大块深度较深，代码嵌套多，理解和维护难度大，可能存在设计不合理之处。 整体而言，代码质量有待提升，尤其在简化复杂度、增加注释方面还需改进。
从SourceMontor的生成报表内容图来看本次代码还是比较垃圾的很多都超出了图形的外面，代码的方方面面都还需要加强和改进，但是对我来说第一次的要求能写出来我就觉得很艰难了，所以最开始没有去考虑那么多代码质量的问题。

踩坑心得：
最开始第一次作业并没有成功完成，代码if语句嵌套太多导致运行超时，搞得一直焦虑崩溃，同时电梯的运行逻辑也不够完善，只满足了输入输出的样例，并没有通过测试点的测试样例，最后重新整理的电梯的运行逻辑减少if的使用才没有超时，同时也让自己更加清楚写代码不要盲目写，要先思考类之间的设计和理清运行逻辑上的各种情况，不然会做出很多的无用功出来。这样才能提高写代码的效率。

第二次作业
目标：电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行乘客请求不合理，具体为输入时出现连续的相同请求，程序自动忽略相同的多余输入，继续执行，同时还要满足类的设计需求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程）。

第二次作业的类图：

方法分析：

代码分析：

文件数量：仅有 2 个文件，代码结构相对简单。
代码行数：共 407 行，不算特别庞大。
语句数量：有 258 条语句 。
分支语句占比：为 19.8%，说明代码中条件判断等逻辑不算特别复杂，但仍有一定占比。
方法调用语句：131 条，表明代码中方法间存在较多交互。
带注释行占比：仅 3.9% ，注释过少，会严重影响代码可读性和可维护性，后期理解和修改代码难度较大。
类和接口数量：只有 1 个，代码的封装和模块化程度较低。
每个类的方法数：高达 37 个，意味着该类承担了过多职责，违反了单一职责原则，会使类变得臃肿，难以理解和维护。
平均每个方法的语句数：6.78 条，整体较为平均。
最大块深度：为 8 ，平均块深度 2.12 ，表明代码存在一定嵌套层次，虽平均深度不算高，但最大深度提示部分逻辑可能较复杂。

改进建议：
从SourceMontor的生成报表内容图中来看，代码存在很多的缺陷
可读性差：带注释行占比仅 3.9% ，几乎没有足够注释来辅助理解代码逻辑，应该多添加点注释
类设计缺陷：仅有 1 个类却包含 37 个方法，严重违背单一职责原则，使得类的功能过于繁杂，增加了理解、调试和修改的难度。
最大块深度为 8 ，反映出部分代码逻辑嵌套较深，增加了理解成本。
结构指标不佳：分支语句占比 19.8% ，方法调用语句 131 条，说明代码中条件判断和方法间调用频繁，逻辑相对复杂，却缺乏足够注释辅助理解，进一步降低了代码质量。
看了生成的报表内容来看，代码质量还是不高有的爆表有的却几乎都没有，还是要提高代码的效率和各类之间的调用逻辑，同时要多添加点注释。

踩坑心得：
本次作业相比于第一次难度更低一点因为电梯的运行逻辑不需要改变也就不需要大改，只需要在输入读取数据时将重复的去除，不添加到队列即可，有了第一次的基础第二次就比第一次简单的多了，但是对于我来说难度还是有一点的，在读取数据的时候逻辑容易出错和遗漏，需要不断的去调试和完善才能达到想要的效果，其中让我搞了最久的就是当电梯楼层一样时还需要判断方向是否相同，相同才要删除，我第一次是只要电梯楼层相同则删掉，导致后面有一半的答案错误没有拿到分，但是在后面还是及时发现了问题所在进行了修改。

第三次作业
目标：电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

第三次作业的类图

方法分析：

代码分析：

文件数量：2 个，代码结构相对简单，便于管理。
代码行数：共 378 行，语句数量为 211 条，规模不算庞大。
分支语句占比：19.9% ，说明代码中存在一定比例的条件判断逻辑，但不算特别复杂。
方法调用语句：122 条，表明代码中方法间交互较为频繁。
带注释行占比：仅 4.2% ，注释过少，严重影响代码的可读性和可维护性，后续理解和修改代码难度大。
类和接口数量：仅有 1 个，意味着代码的封装和模块化程度较低。
每个类的方法数：高达 31 个，该类承担了过多的职责，违背了单一职责原则，会使类变得臃肿，难以理解、测试和维护。
平均每个方法的语句数：6.58 条，相对较为均衡。
最大块深度：为 8 ，平均块深度 2.21 ，说明代码存在一定的嵌套层次，部分逻辑可能较复杂，虽平均深度尚可，但最大深度提示需关注代码结构优化。

改进建议：
从SourceMontor的生成报表内容图中来看代码质量上还是纯在很大的问题
可读性严重不足：带注释行占比仅 4.2% ，几乎没有足够的注释来解释代码逻辑。这使得代码对于其他开发者或后期维护者来说，理解成本极高，难以快速把握代码意图、功能和关键实现细节。
类设计不合理：只有 1 个类却包含 31 个方法，严重违反单一职责原则。一个类承担过多功能，会导致代码高度耦合，可维护性和可扩展性变差。比如，修改其中一个功能可能会意外影响到其他功能，且新增功能时也难以合理地融入到该类中。
最大块深度为 8 ，表明部分代码逻辑嵌套较深，增加了理解和调试的难度。
结构指标尚可但需优化：分支语句占比 19.9% 、方法调用语句 122 条，说明代码中有一定的条件判断和方法间调用，逻辑不算特别简单。但因缺乏注释辅助，理解这些逻辑关系变得更加困难。
总体而言，这份代码质量较差，在可读性、类设计以及复杂度管理等方面都存在严重缺陷。

踩坑心得：
本次作业相比于前俩次，比第一次简单一些，但是比第二次难多了，因为电梯的逻辑没有改变，得从电梯的目的楼层和请求楼层来判断该外部请求的运行方向，同时要改变将外部楼层运行到请求楼层后将外部的目的楼层添加到内部请求队列的后面，难度不是特别大但是很繁琐，电梯的运行逻辑中判断外部请求时要添加很多的判断方向以此来不改变电梯原本的运行逻辑，这次作业也卡了一会，主要是对于电梯运行逻辑的理解，最开始是理解为不需要判断外部请求的运行方向，结果导致运行全部错误，后面又仔细想了之后才发现问题所在改为正确的运行逻辑

总结：
本次三次作业的题量不大但是本次三次作业的难度对于我来说还是比较大的，主要还是卡在了第一次，最开始根部不知道要写成一个什么样子的代码，同时最开始正则表达式也不太熟练，在main中读取数据也用了很多的时间，最后就上午写了太多的if语句导致运行超时，后面发现是if的嵌套太多了，自己的电梯运行逻辑不够清晰，分类分的太全了导致的运行超时，没有拿到第一次的分。第二次作业则是在第一次的基础上进行了类的分类，将类分全，因为有了第一次思路的铺垫，第二次将类分出来则就更加简单了些，但还是花了我太多的时间去将逻辑重新理顺去将第一次的代码进行类的重构。第三次作业则是将第二次外部请求改掉输入的形式同时将外部请求的目的楼层加入到内部请求的外面，电梯运行的逻辑大体上没有改变。第一次作业的难点则是理清楚电梯的运行逻辑，第二次作业难点则是对于重复楼层的判断，是楼层和方向都相同时才为重复，要忽略请求，第三次则是通过请求楼层和目的楼层来判断运行方向同时将外部请求的目的楼层添加到内部请求中去。但是这些问题都反应了一个点，自身对于java代码还是不够熟练运用，对于复杂一点的逻辑思维还是不太跟的上来，要花费大量的时间去完成，真的好痛苦AWA，但是这样一轮下来对于自己的提升还是很大的，首先对于java的基础语法应用是有了一定的了解，同时java的面对对象的设计理念也有了更加清晰的认识，对于正则表达式也是初步体会了其方便性，过程虽然痛苦但是还是收获了许多。对于今后还是在提升思维的基础上，然后尽可能的去提升自身代码的质量。