OO第一次阶段性总结

---

通过三次做业的历练以后终于来到了写博客这一周。回顾开学来的这一个月，令我印象最深入也是最累的一门课就是OO了。虽然上学期学过一部分Java，但这学期开学就来的OO做业仍是让我在第二周就开始熬夜了。不过虽然这几回做业相比于其余几门课在开学这一阶段的进度来讲感受很紧张，可是我从中学到的知识以及代码技巧也不少（给别人挑bug也熟练起来了（狗头））。

前三次做业的度量分析及类图

第一次做业

第二次做业

第三次做业

由上可见，三次做业中，个人代码中都存在一些较为复杂的方法，这些方法大可能是整个程序核心逻辑的部分。在未来的做业中我也将考虑如何减小核心代码的耦合度。

关于Bug

本身的程序

前三次做业中，很是幸运的是个人程序都没有被挑出bug。尽管我本身也对本身的程序进行了完整且花样繁多的测试，但这并不能彻底说明程序中彻底不存在bug（虽然我以为个人程序是bug-free了）。所以在这里我打算谈一谈本身debug的感觉。

前几回做业当中，我在做业中花费时间最长的就是debug以及寻找潜在的bug。我测试的步骤通常按照

• 分支树
• 简单的功能测试
• 复杂一些的功能测试
• 边界测试以及暴力测试

来进行。其中通常问题出如今复杂功能测试以及边界测试中。对于复杂的功能测试，找到bug的要点是构造一些足够特殊的样例。例如第三次做业中同层捎带屡次的问题。除此以外还能够构造一些较长的功能测试样例，例如让电梯反复上下行，以此检查出潜在的问题。边界测试部分让我印象深入的是第一次做业中的表达式，虽然我已反复确认正则表达式的逻辑没有问题，但因为正则表达式一次匹配过长，致使对于很长的表达式出现爆栈状况，这一点在以后使用正则表达式过程当中都有注意。

别人的程序

这三次做业我拿到的互测样例中或多或少都有一些bug。我寻找bug基本也按照了测试本身程序的步骤，但在测试过程当中也会经过注意对方代码中存在的缺陷来构造测试样例。印象最深入的是第一次做业中的我拿到的互测程序，因为其使用数组以及简单的排序来管理整个表达式，输出前将数组按指数从大到小排序，但输出时判断空多项式的逻辑有误，致使输出错误。这样的缺陷经过测试样例寻找，效率并不如直接阅读代码来得快。所以在后续测试过程当中我也会仔细注意对方的代码。
代码规范真的很重要，但愿你们尽可能少用诸如temp1，temp2这样的变量名来编写程序，也尽可能多写注释，本身看着舒服，测试的同窗看着也舒服

感想

前三周的做业仍是有惊无险的度过了，但我认为本身的代码仍有改进的空间。首先是能够进一步下降耦合度，其次是代码能够再写的可读性更高一些。固然这些改进措施的前提是须要有充足的时间，而不是赶ddl。虽然在研究一段指导书以后（看完大佬们讨论后）再开始编程效率更高，我仍但愿之后的做业我能够尽早开始尽早完成，也但愿指导书能够更加明确。