从入门到不放弃——OO第一次作业总结
写在最前面：
我是一个这学期之前从未接触过java的小白，对面向对象的理解可能也只是停留在大一python讲过几节课的面向对象。幸运的是，可能由于前三次作业难度还是较低，并未给我造成太大的困难，接下来我就三次作业，从程序以及个人体会谈谈我的分析与感悟。
第一次作业：
度量结果以及UML图：
度量结果：
UML：
分析：
这次作业是我人生中的第一个像点样子的java程序，刚拿到指导书真是一脸懵逼。由于我还什么都不太懂，于是我就采用了“照猫画虎”的策略，直接模仿老师ppt中给出的代码框架，然后自己填充并加以修改。从上面的分析结果来看，总体上还算是不错的。只有getstring方法结果标红了，确实我感觉这个地方写的有点复杂，我将字符串从输入到处理完成全部放在了getstring方法中，一共大概80行左右。现在回过头来看，或许把这部分再拆分成几个子方法会更好一些。
关于Bug：
对于这次作业，我觉得其实只要利用正则表达式并且正则表达式写的正确，基本上可以避开绝大部分的bug了。我的程序在公测中，被测出了一个bug，是最后一个压力测试，因为我写了一个巨型正则表达式一次性判断输入是否，输入过长的情况下会造成栈溢出，以至于crash。这一点我感觉可能由于我的编程经验不是很充足，再加上对java以及正则表达式的不了解，之前并没有想到。现在想来如果改成两个或者更多的正则表达式进行判断，再加上try-catch，应该就是万无一失的了。我拿到的程序是一个十分优秀的程序，从程序风格以及代码质量以及Readme来说，都挑不出一点毛病。总的来说，这次作业还是很简单的，如果正则表达式无误，并且算法无误，基本上就只剩下栈溢出和crash的bug了。
心得体会：
常言道“万事开头难”，我觉得第一次作业其实是我这三次作业中花费时间最长的一次。从读懂老师的ppt，再到读懂指导书，再到开始能正确写并且编译运行简单的程序，再到学习正则表达式以及java中各种内置方法以及输入输出的使用，我体会了一把一步步踏入java面向对象的大门的过程。我觉得可能学习任何事情都是这样吧，最初一定是困难的，只要度过这段日子，后面就都是柳暗花明豁然开朗了。
第二次作业：
度量结果以及UML图：
度量结果：
UML：
分析：
从上面的度量结果来看，我个人觉得整体还是不错的，但是还是有两个地方复杂度过高。第一个地方我觉得是犯了和第一次作业一样的毛病。我在h2main这个主类的main方法中，完成了从输入到提取请求再到反馈结果报错的全部过程，大致数了一下大概有100行左右。现在看来还是将提取输入这一部分为几个子方法更好。同时在电梯作业中由于存在两种类型的输入，一种是电梯内一种是楼层，我采用的方法是把它们分开处理，这样也造成了代码有一部分是重叠的，显得比较臃肿了。第二个地方是在调度类Schedule中，shagua方法里完成了电梯的调度。在这个方法中，我将判断同质，取出请求以及执行请求都放在了这里，现在回头来看应该将判断同质单独做成一个方法可能更好些，因为这一部分的功能是一个完整的模块。
关于Bug：
很凑巧，这一次的作业中，我的程序公测互测都没有bug，我拿到的人公测互测也都没有bug。这次作业的内容相对来说也比较简单，经过上一次作业后，这次作业的输入输出已经基本不会出现什么bug了，值得注意的地方就是关于同质请求的判断，除此之外应该没什么值得特别关注的了。
心得体会：
或许上一次作业有的同学还能拿面向过程的程序来水一水，但是这次作业开始我感觉是真正进入面向对象了。从这次作业中，我觉得我参透了面向对象的精髓——设计。面向对象我认为最重要也是最难的地方，不在于你能不能把这个程序编写出来，而是在你理解需求的情况下如何设计出一个漂亮的程序。我从周六开始写这次作业，周六一天我都在阅读指导书，以及在纸上初步的设计我的程序结构和算法。而真正的写程序我在周日可能只用了五六个小时。我觉得面向对象还是首先要理解好需求，必须彻彻底底的理解好，然后彻彻底底设计好，再开始写，这样才能写出质量比较高的代码。切忌一上手刚有点思路就开始写，这样往往写出来的程序是最糟糕的。
第三次作业：
度量结果以及UML类图：
度量结果：
UML：
分析：
由于第三次作业是基于第二次作业的，只是增加了捎带功能，所以我的程序也只是继承并重写了Schedule中的override方法以及修改了一些输入输出。所以在第二次作业中度量出现的问题在这次也出现了，在此不再赘述。上述的度量结果显示了我新写的类也就是ALS_Schedule类的复杂度也比较高。确实，我从第二次作业到第三次作业，可以说仅仅是增加了这一关类，并且这个类中只有一个方法，但是这个方法却有近200行。同时，在这个类中，我将判断同质的代码重复写了三次，而且由于我的算法是从楼层遍历，于是我将上行和下行这两段接近80行的代码重复写了两次（当初的考虑是他们之间略有一些差别，不能轻易的完全归为一个方法，反正复制粘贴就行，也不费事）。现在回想看来，可以模块化的代码还是应该单独地写成方法，这样就更有利于维护，更能提高了可读性与代码的质量（我在后期改bug的时候就需要在上行下行分别改，如果单独模块化出来就只需要改一次了）。
关于Bug：
这次我的代码在公测和互测中都没有发现bug，我拿到的代码也仅仅有一个bug（就是关于输入时序，与主请求相同楼层的指令也需要按输入顺序输出）。我觉得这次作业的bug测试的关键就是捎带了，这个我觉得还是看个人捎带算法的严密程度，如果写的好的话，我觉得完全可以没有bug，同时很简洁。
心得体会：
对于这次作业，我有两个方面的体会。一方面就是，在你写程序的时候，要有意识的预料可能会增添什么功能，在写第二次的作业时，便听闻第三次作业是增加捎带功能，所以当时我就有意写的很方便添加东西。事实也如此第三次作业我仅仅是增加了一个类然后修改了一些输入输出，不算设计算法光写代码+debug可能只花了3-4个小时。第二个方面就是，写代码之前的设计真的很重要。我在写之前，完完整整的在纸上和脑子里把代码过了一遍，所以写起来就是一气呵成行云流水最后修改也只是de了一个bug，如果在设计之前考虑不周到，就会造成全是bug或者这个算法本来就是错误的。
最后给出一些不能称之为建议的建议：
1.写代码前的思考和设计真的很重要！！！我经常看到周围同学debug，一de就是数个小时甚至十几个小时，还看到了有人熬夜写的代码第二天推到重来，我觉得目前对我们这个水平的选手来说，bug的产生方式无非是两种：1.手误。错打一些变量什么的，导致了bug出现，这个事其实我也经常遇到，我的解决办法就是每写完一段代码，就回看一下刚才写的，看看有什么疏漏，虽然可能费点时间，但是这真的是避免手误的好办法。2.算法设计上本身有误。可能这个bug就是在你设计这个程序的时候就出现了错误，我觉得解决这个问题的最好办法就是写之前考虑清楚。首先应该认认真真读指导书，这一点简直太关键了，如果你连你需要做什么都不知道，就根本不可能进行下面的步骤了（有些同学还会出现漏读或者误读指导书的情况，导致写完的代码还得大改）。其次，在动手敲代码之前，一定要完完整整想一下你设计的算法能不能实现，先在脑子里把过程捋顺了，发现可以，再开始动手写，千万别写到一半了发现不对然后再在原来的基础上改，最后越改越糟，白白的浪费了时间。
2.合理的安排好自己的时间。我觉得作为一个成年人，安排好自己的时间是最基本的能力，包括你可能遇到的突发状况，都要考虑在内。对于熬夜，就我个人而言是不赞成的，可能某些人体质好就喜欢不睡觉那就另当别论了。目睹了室友前三周每周二晚上几乎通宵，我真是怕突然发生啥意外那岂不是要上微博热搜然后这门课也就凉凉了？这三次作业除了第一次我在ddl前一晚熬到了1点，剩下两次基本都是周日或者周一就写完了，周二写个Readme然后提交美滋滋。我觉得其实也没啥拖延症啥的，说白了就是懒+今朝有酒今朝醉明日愁来明日愁么。说了这么多可能有的人觉得不乐意了，可能觉得我太自己以是，其实我只是想表达希望每个人都能健健康康度过这学期然后少熬夜，其实有时候你的熬夜是自己一手造成的。
写在最后的最后：
最后的最后我想抒发一下开学到现在关于OO课的一些题外感悟。我真的觉得好神奇，小小一门OO课，竟能发现如此精彩的人间百态。上了大学越来越感慨，“哇，大学真是什么样的人都有唉”（诚然这样的想法是建立在我觉得我的三观以及道德行为准则完全是正确的前提下的）我觉得，OO的意义，不只局限于教会你写代码，教会你面向对象，更重要的是，它是对你整个人的一种提升。你需要学习怎样去读懂一篇文章，你需要学会管理好自己的时间，你需要学会和别人交流，你需要学会如何对抗压力，你更需要学会如何去控制好自己的情绪......我真觉得如果只是把OO当做学会码代码的一门课，那简直是太浪费了。其实从上学期的计组我就有这种感觉，总有些人，还没学会如何做人就学会了写代码。大学其实还是一个包容的环境，老师和助教都是善良的，即使我们做的有些过分，也不会有太严重的后果，未来我想可能形势要比这严峻的多吧。其实想写的还有一些，但怕写太多了让某些同学有代入感了对号入座了可就糟糕了。最后说几句：希望大家都能给别人以尊重，别老是以自我为中心。然后就是，现在可能你觉得OO这个事挺让你糟心，有很多槽点，我想说未来比这糟心的事多的去了，看开点，没啥大不了。最后，希望每个同学都别放弃，坚持到最后，一定会有巨大的收获。
