OO1-3次作业总结

第一次作业

（1）oo度量

 

（2）类图

 

（3）分析

        这次作业虽然难度不大，但是对于Java新手来说，需要一个认识java的过程，这个过程有点痛苦，在此，感谢我的室友天猫会员张吕四。从度量表上也可以看出ParsePoly方法过于复杂，导致爆了红，设计对的过于粗糙。

       这次作业一个重要的点就是学会正则表达式的使用，拿到第一次作业之后，由于我并有自习研读pdf，只是粗略的看了一遍，所以我第一开始的时候并没有决定用正则表达式，足以证明我是有多傻，后来花了一些瞎功夫之后，我终于看到了指导书的要求和提示，这足以证明指导书的重要性，一定要好好地看指导书！！

　　正则表达式的功能十分强大，但是还是有些要注意的点，起初我是只进行一次匹配，那个正则表达式很深很复杂，就很容易爆栈，后来我分了两次，但事实证明，两次还是不行，因为我还是爆了栈。

        本次作业公测所有测试点，互测阶段被发现一个crash，原因是因为正则表达式爆栈。之所以出现这个问题是因为对正则表达式爆栈没有这个概念，没有想过这个问题，考虑不周。为了迎接公测和互测，我在自我测试的时候根据老师的bug树，构造样例，到了互测阶段，我把这些自我测试的时候构造的样例在用来测试我手中别人对的程序。第一次作业我拿到的同学的作业完成的比较好，我没有找到bug

 

第二次作业

 (1)oo度量

 

（2）类图

 

（3）分析

　　设计思路：先将所有的指令输入进行处理，包括判断，转化，生成相应的电梯指令，并将生成的电梯指令加入到指令数组中，然后通过scheduler类进行统一处理并输出结果。

　　这次作业相比起第一次作业难度加大了不少，但是因为对java有了一定的熟悉度，写起来倒比第一次顺手，但是这次debug的时间比第一次要多的多。需要考虑的问题也多，细节问题越来越多。并且要求了我们必须要有五个类，更加的面向对象。

　　第二次作业我有两个bug，第一个是炸了我的long型，第二个是支持了-0。第一个bug的原因是我只考虑了超int的情况，没有想到他还会超long，是我考虑不周。第二个Bug是因为看错了指导书。互测的时候发现了别人三个bug。第一个bug是炸long，第二个bug是楼层请求时间不递增，第三个是电梯请求时间不递增。

 

oo第三次作业

 （1）oo度量

 

（2）类图

 

（3）分析

　　第三次作业是在第二次作业的基础上添加了一些要求，并且要求继承，接口，还有toString.

　　这次作业的难度又比第二次的难度大了不少，指导书就有整整十页，在看完指导书之后我的脑袋是懵的，然后在那天夜里，我花费了很长一段时间去读指导书，理解清楚指导书的要求，并在纸上列上了自己的设计思路，经过了这一系列的准备，我开始写代码，在写完整个框架之后，我上床睡觉了，因为已经是深夜了。第二天，我不玩昨天的代码，然后开始自我测试，在接下来的几天中，我遇到了无数的bug，这足以说明我写代码之前的准备还是太仓促，并没有完全读懂指导书。

　　本次作业顺利通过公测和互测环节，没有bug，但是在写完之后发现了很多的bug。这些bug大多是因为没有正确理解指导书造成的。本次互测环节测到了别人的三个bug和一个incomplete，因为他没有实现继承，接口和toString的设计要求。bug的原因也是一些硬性要求功能并没有通过，没有达到指导书的要求。

 　　第二次第三次的作业自我测试是在自己手动构造一些特殊点之后再用室友写的python程序生成一百万条或者三万条来测试，然后在互相监测一些结果是否一样。

 

测试策略

　　在构建测试样例的过程是和自己写代码的过程同时进行，用各个节点的样例测试自己的程序，并且在程序设计过程中对自己解决的问题点对应地创建测试样例。这样在互测阶段基本上已经能够做到大部分的覆盖了。

 　　同时重视极限样例的测试，在电梯作业中即100条左右的大部分有效的指令，因为小短的测试用例很难发现深层次的难以发现的bug。

 　　在测试完所有的样例后，再从对方的代码进行分析，查看逻辑结构，和一些自己当时犯错和具有处理技巧的点进行研究，再从可能的错误入手设计新的样例。

　　自我测试中debug阶段基本完成的之后，可以尝试用写一个程序随机生成大的测试样例，和同学一起测试，对比结果。这样就能确保代码的正确性，在测试别人的时候，也可以先拿大的样例来测，如果发现输出错误，在详细的找到具体的bug

　　可以尝试用git中vim 指令对比两个 输出检验输出是否一致。

　　比如说在第三次作业限制是100条指令，但是无论在自我测试还是在测试别人的时候，我是先把100条限制的要求代码注释掉，再把前带有#号的输出代码注释掉。这样就能保证一个样例只能有一个正确输出。之后再用python的随机生成代码生成3万条，或者五万条指令测试。将实际输出和正确输出放到早已建好的git库learngit下，然后用vim diff file file 指令对比。如果一致的话，程序基本正确，如果不一致的话，在根据bug分支树，构造具体样例一一排查。（此处感谢天猫会员张铝四）。

 

总结 

　　命名要有意义，可区分，增强代码的可读性
　　注意封装重用
　　把握好边界情况
　　尽量减少private变量的get set方法
　　善于利用try-catch
　　代码修改先不要删，先注释掉
　　一定要写好readme!
　　认真阅读指导书
　　善用eclipse的TODO标注功能，每次作业都不可能一个下午一个晚上就能够完全实现的，而且每次编写代码的时候也不能保证某个地方的逻辑百分之百正确。这时可以借助　eclipse的TODO的标记功能，可以再有疑问的地方坐下标记，后续作为测试的重点。

　　一定要认识到设计的重要性。一定要进行细致的设计，甚至可以先构造大量的样例对设计进行调试，确保设计的完备性之后在进行编码 。