牛小可-22371010-oopre个人总结

[耳机真好吃]

注：这个账号前两周刚改过名字，还不能改名，所以开了个小号重新提交了一次作业

最终代码架构

 

 

 最终代码架构大体采用作业要求。其中略有不同的是，我一开始就没有设置一个进行输入处理的类，输入的arraylist直接作为参数传入Adventure类进行处理，这成为了屎山代码的开端。此外，我把功能较为复杂的战斗模式单独设置成类，这似乎是不提倡的，但是我写爽了就行（

第二次作业提供的inputinfo数组被我直接作为参数传入Adventure类，这使我Adventure类的代码可读性极大降低，总是需要重新捋一遍。同时这样的参数传递对junit编写及其不友善。大约在第四次作业左右，我就陷入了是否重新架构代码的困境——过不了多久就结课了，有必要这么大费周章吗？但是不改的花每次新增功能又很难受。

最终我还是懒，硬着头皮完成了这一坨杰作，这样的精神值得赞扬。抛开事实不谈，除了Adventure类的其他类自认为写的还是不错的。

使用junit的心得体会

我从来没有觉得使用junit开心过……

junit在作业使用过程中对我帮助几乎没有。助教曾说不要使用setin与setout，而junit在测试单元中构造数据再断言的方式在功能越来越多时，显得极其繁琐与低效，加上前文提到的我的代码的特色，使得junit对我来说是纯纯的累赘。我在debug时使用的方法包括但不限于：反复品读作业要求并自己思考各种情况；从测评结果、同学等渠道获得测试数据并手动分析；……

以至于在后几次作业中，我只是想办法在junit中把所有函数调用一遍以满足覆盖率要求。

学习OOpre的心得体会

良好的代码架构

好的架构泽被万世，烂的架构遗臭万年。代码一定要从头开始打好框架，不然恶心别人恶心自己，，，

良好的审题习惯

oopre的题干实在是太太太长了。以至于每次做作业我都是扫一眼就开做。做到哪里再翻阅指导书的要求。这样虽然做着爽（其实根本不会快），但有时候做完后才发现，居然还有没实现的要求，就好像点了两个韭菜盒子却只送来一个，只能第二天再给补一个一样。

总之，oopre的题还是适合夜深人静的时候猛猛干。在发现这个规律后我几乎所有作业都是深夜完成的，白天反而很少碰（

对课程的小小建议

希望能把代码架构问题，尤其是输入处理的部分在第二次课或者第一节课就讲了，或者在第一次作业中加入这部分内容，不然代码一开始瞎写，后面越堆越难受:(

 

[洪陈天一]

看 MyGO!!!!! 看的