oo到目前为止也算是结束了第一个阶段，作为一个在本学期开学之前一行JAVA代码也没写过的菜鸡，这几周过得真的很艰难。。。一切都是从零开始摸索，全靠查资料和翻书自学orz
在这次的课程总结中，因为电梯部分的作业更加困难，我出现的问题也较多，所以主要只对第二三次作业进行分析。
第二次作业——傻瓜电梯
一、程序分析
二、个人反思
拿到第二次作业之后，当时整个人是毫无头绪的，本来是想通过画出逻辑关系类图先理清思路，但是冥思苦想了一个下午还是不太能理解课件所给出的的设计建议，于是决定按照自己的想法进行尝试，由于不能理解楼层类的作用我最后只写了四个类。我在基本梳理了一下整体设计关系之后开始写代码，刚开始写得非常艰难，完全属于写了一行不知道下一行该写什么，从0到1很难，但是只要开始动手写代码，就像是一块一块地填补空缺的部分，从1到10就变得容易起来，由于傻瓜电梯相对比较简单，DEBUG的过程还不算是太艰难。
最后的结果是公测和互测各挂了一个，原因分别是：由于对matcher.find( )的误用，导致对输入请求的格式分析出现了问题，对于输入后面符合正则表达式、但左边有非法字符的情况出现了错误判断；另一个问题是由于scanner.close( )的使用错误，在只输入”RUN”时发生程序崩溃，导致了一个crash错误。
第三次作业——ALS电梯
一、程序分析
二、个人反思
第三次作业是我完成得最糟糕的一次，由于开始时觉得只是在第二次作业的基础上进行修改，可能比重新写一个新的程序要轻松一些，态度就有些放松。研究指导书时，由于最开始对“捎带”的定义理解的不是很清楚，于是决定先把大致框架写出来，后期再进行详细完善，这样的想法很愚蠢。。。前期不完全的思考给我带来了非常大的后期工作量，由于考虑的不完善，虽然开始时处理一些简单的请求队列没有问题，但是一旦请求复杂起来，就错误频出，最大的问题是：当捎带队列中有和主请求同楼层的请求时，应按照输入顺序输出，但我的写法是先处理捎带请求，再最后处理主请求，这个问题的修改给我带来的非常大的工作量，导致我捎带处理的主体部分都进行了很大的改动，改动之后重新DEBUG也是一个非常费时的过程。我在DEBUG上花了这么多时间主要还是因为对一些细枝末节的情况思考的不完善，不停地修改可能又会导致新的问题，这个过程的反复进行十分费时费力。
这次的作业虽然公测都通过了，不过互测被报了3个error和1个crash，当时看到被报了这么多错真的有点崩溃。。。虽然我的编程能力的确挺差的，但是看到辛苦写了这么久的作业被扣了这么多分还是有点难过TAT 不过也应该感谢大佬给我发现了这么多的错（。crash错误还是上次只输入”RUN”的问题，虽然上次被报错之后进行了修改，修改之后本地运行情况看似是正常的，但是这次又被报错之后我仔细分析了一下代码，最后发现原因是我的程序在这种情况时无法关闭scanner，进程并没有结束，仍可以在控制台继续输入，本地运行虽然不会报错，但是在oj上由于程序不能正常关闭，nextline没有检测到输入，所以会报错。第一个error是因为若下一条待处理请求发出时间大于当前时间时，当前时间应增加至与请求时间一样再执行请求，这个点并不是没有考虑到，而是因为思考得不够全面在某些情况下出了问题；第二个error是因为我在输出时将原请求时间的变量类型都强制转换成了int型，若是输入请求的时间过大则会发生错误；第三个错误是因为我在进行捎带判断预估请求到达时间时，是在当前时间的基础上进行计算的，而没有在请求发出时间的基础上进行判断。
在发现别人的问题方面，我一般是用为检查自己程序编写的测试样例来检查别人的问题，并通过对方的公测错误发现代码编写过程中的逻辑问题，从而发现新的问题，我在这方面做得比较差，以后要加以改进（毕竟我连自己的错都发现不了还怎么找出别人的错。。。
这三次作业的完成情况虽然都差强人意，但是以我的水平来说也算是尽力了。在这些作业中反映出来很多问题，主要是编程过程不够规范化，动手写之前没有把思路理清楚，导致写的时候基本是想到哪写到哪，代码逻辑十分混乱，但是我觉得这个问题的原因主要是我编程能力太菜，一时半会也没法解决，因为以我目前的水平只能走一步看一步，没有办法在写代码之前就把整个过程清楚规划好，只能慢慢改正了。
第一阶段已经过去，新的征程即将开始。。。
原文地址：https://www.cnblogs.com/impact0/p/8711168.html