码迷,mamicode.com
首页 > 其他好文 > 详细

OO第一阶段纪实

时间:2018-04-03 17:28:44      阅读:164      评论:0      收藏:0      [点我收藏+]

标签:read   提交   压力   java编程   技术   影响   ros   状态   mic   


$ 0 写在前面
  在DDL一次次的推动下,历经三个周期的更迭,一个月的时光匆匆而过。谨撰此博文,以记录这一段见证成长的心路历程。



$ 0-0 JAVA“一天速成”
没有修习过传说中的“OO先导课”,在学期开始之前也从未接触过JAVA编程,真正的从零开始学JAVA。有了先前课程的基础,经过了一年的积累,在短时间内学会使用一门语言并不困难,在加上JAVA天然的与C语言之间的某种相似性,也使得“JAVA一天速成”并非遥不可及。


$ 0-1 “过程式”VS“对象式”
但值得注意的是,JAVA作为一种面向对象的开发语言,其本质上与C语言有着重大差异,只不过在第一次作业的时候,由于对JAVA的一无所知,就也只能按照头脑中既定的那种根深蒂固的过程式程序模式来编写。而作业要求“注意体会过程式和面向对象式程序的区别”也成为了一直困扰我的难题。


$ 0-2 棘手的需求
在第二次作业中,由于有了第一次作业和实验课的经验,我也阅读了更多身边同学所编写的代码,使我对面向对象的概念有了进一步的了解。同时由于作业项目引入了一个具体的应用背景,也使我对“类”的定义和使用更加得心应手。不过新的难点总是会不断涌现,这一次我所面临的新难题便是—指导书。可以说指导书就是一种用户需求,相比于在未来工作中可能遇到的需求而言,指导书可以说是将规定做到尽量细致了。但是大量的内容同时涌现,个别定义的模糊不清,成为了对我的新的考验。


$ 0-3 惨痛的教训
紧接着第三个工作周期,也就是刚刚结束的那项任务对我而言是一次惨痛的教训。由于第三次作业的内容继承自上次作业,同时对上次作业的内容有了更进一步的需求,这就考验了我们所设计的代码的可扩展性。另外捎带请求、同质请求独特的判定方式相互交织,也为调度方法的设计与实现增添了不小的难度。能否做好与上次作业的衔接、能否架构好顶层设计便成为了这次作业的主题。

 


 

$ 1 第一次作业



$ 1-0 从I/O开始
万事开头难,一个程序往往是要以一组输入作为起始,由于一上手还不了解“对象”的概念与使用,java的一组用于控制输入的语句在我看来显得“玄妙异常”。

import java.util.Scanner;
Scanner input = new Scanner(System.in);
if(input.hasNextLine()) {
text = input.nextLine();
}
input.close();

这里的input为实例化的一个java内置Scanner类里的对象,System.in作为Scanner构造方法的参数被传递进去,hasNextLine()和nextLine()都是Scanner类里的方法。最后的close()方法的调用也是编译器的一种建议,不写该方法会收到一条警告信息。

注意在读入一行前,一定要先判断是否存在下一行,从而避免直接落入Exception的处理之中。同时也尽量在读入阶段末尾调用close()方法,以免出现未知错误。
下面列出一些常用的Scanner类中的方法,便于日后使用时查阅。
技术分享图片

技术分享图片

(图片来源于网络资料)

 

$ 1-1 正则!正则!
在上一学期的《计算机组成原理》Project 0中我们了解到,正则表达式是一种有效的字符串匹配机制,其本质就是基于FSM实现。因而这里我也尝试了一下在java中用简洁的正则式来取代原来书写FSM所采用的繁琐的状态转移。
正则式的表达虽然简洁,但随之而来的问题也着实为我带来不小的困扰—爆栈
由于本次作业的输入是有一定规模的,总共输入项数的上限多达50*20。对于这种规模的输入,如果不加以拆分,直接进行整体正则匹配将无法通过压力测试(实验证实)。
由此我便得到启示:在待匹配的字符串规模较大时,可以采用以下语句,来实现对字符串的拆分:

// while(m.find())
//    m.group(0)

其中find()方法用于判定找到了带匹配的字符串,group()方法则可以用于截取出匹配到的字符串。
至此,正则式的两大用途都很清晰了:一是可以用于格式检查,二是用于从原字符串中截取符合规格的标准段。那么如何综合应用这两种功能,去解决对大规模输入的匹配呢?
我在第一次作业中就应用了分段匹配的办法,每次只匹配一个多项式的长度,并将匹配好的部分存入一个String中,逐次累加,最后比对存储的串是否和原串相同,即可完成匹配。
还有几点值得说明的是,在正则式中尽量应用^$来标记待匹配字符串的首尾,用非捕获性的(?:)来代替捕获性的()匹配。这两处细节可以优化我们的正则处理过程。

 

$ 1-2 防御与攻击

第一次在互测阶段被发现了一处bug,这处bug出现的原因在于我对“-0”以及“前导0”的理解不够全面。仅考虑了形如“-0”的情况,却忽略了“-0”也可能存在前导零。这就在被测试阶段,给测试者留下了可攻击的漏洞。

在进行测试时,我所遵循的逻辑也是由表及里的策略:即通读指导书、略读I/O、检查异常处理、深入理解代码逻辑几个步骤。
拿到的第一份代码的漏洞出现在缺乏try-catch(关于try-catch的重要性将在下节叙述)。在这个基础上,在合理范围内使程序crash的几率就大大增加。紧接着我发现,作者运用了大量的定长数组代替长度可变的数组,而且在Input阶段的正则匹配也采用了十分开放的贪婪匹配策略,这就为程序引入了潜在威胁。
因此,通过构造一组恰好数组越界的小型数据输入用例便crash掉了这个程序。

$ 1-3 try everything && catch me if I fall

任何情况下程序都不应crash。
这一要求一点都不过分,对程序鲁棒性的追求没有极限。让自己的程序在高强度的测试下保持稳定性,是每位设计者必须要致力于的目标。
因此,永远不要忘记try和catch!
此外,结合后续作业中的经验,try语句块不仅应出现在最顶层,在输入阶段、类型转换阶段、访问定长数组阶段等“危险”时期,最好都应用try-catch结构,而且为了忽略掉异常情况使程序继续正常运转下去,在内部的try-catch结构可以不用exit(0)。

$ 1-4 代码度量分析

技术分享图片

 

 


$ 2 第二、第三次作业



$ 2-0 “面向对象”的进一步理解
这一次作业由于有了具体的应用场景,在加上设计建议,让我有机会进一步理解了“面向对象”的概念。
为了便于我自己的理解,我认为我们在JAVA中定义的class视作和C中定义的struct类似,都是一类封装好的属性的集合,但class在struct的基础上还能在其中定义方法。尽管这种理解并不准确,但确实在我编程的过程中给我了一些提示。
“对象”则是我们实例化的一个具体的编程实体,实例一个对象的好处是其中的数据易于维护。这就和我之前在编程时喜欢用的全局变量截然不同,对象内部的数据易于保护,对外界不可直接访问与修改,这就大大降低了由数据共享所引入的风险。

$ 2-1 多变的需求与应对策略
第二、第三次的指导书内容庞大,issue的讨论区也有很大的信息量。如何整理出其中的逻辑,从何处下手是工作的重点。和测试同学交流过后,我也很认同他所提到的前期设计。而我也不得不承认,由于设计工作不够充分,导致了很多的细节考虑不够周到,也为我后来的debug工作造成了重大的影响。
一种值得借鉴的好习惯是,把指导书和issue中提及的关键点提取出来,记录到文档中,便于设计时查看;采取显式的设计模式,将设计流程完整的呈现出来,对自己的设计也是一个提示作用;测试驱动开发,测试点的设计要用心,多考虑边界情况,不断校正模型。

$ 2-2 新一轮的防御与攻击
在这一个周期的攻防阶段中,由于最后的提交阶段时间紧迫,没有来得及提交readme、还有很多细节的地方,比如Interface/toString()、包括一个已知的尚未来得及调试的bug。
在同质请求和捎带请求混杂在一起的情况出现时,边界条件的判断就显得尤为重要,尤其是同质判断和可捎带判断边界差了1秒的开关门时间。所以边界时间的+-1、是否取等号都需要纳入考虑的范畴。
由于设计工作的欠缺,后期陷入了调试的深渊。最终也因为一个边界取值的原因,被测试人员发现了一处bug。

同时测试中也发现了一些重要的bug,在类型转换过程中,溢出了数据类型规定的范围,导致程序异常终止。这也就是我在$ 1-3 中提到的,try-catch结构内置的意义,同时也要为输入的正则匹配加以限制,尽量避免贪婪匹配的使用。

$ 2-3 代码度量分析 && 类图
$ 2-3-0 第二次作业
技术分享图片技术分享图片



$ 2-3-1 第三次作业

技术分享图片技术分享图片

综合$ 1-4和本节的结果分析,从度量分析结果来看,代码的逻辑复杂度、嵌套块深度等指标在三次作业中均超出了标准值。内聚度不高、耦合度超标也是在设计中凸显的矛盾。在代码逻辑的部分、方法的抽象度不高,很多功能相似或相近的方法代码段出现大量重复。在第三次作业中这种矛盾更为明显:Complexity 均值高达6.3;Parameters per method 均值达1.3;Block depth 也超过标准值。这些显然都是由于代码中大量的循环嵌套、条件分支的交互错杂造成的,这也为我的调试带来了难以估量的灾难性后果。
工程化方法的指导思想在于“高内聚、低耦合”,但要做到这一点显然需要前期大量的准备工作,顶层的架构、显式的设计过程、测试驱动的开发,都将有效帮助我在下次的设计中进一步优化。

 


$ 3 关于Object Oriented 的一些其他感想


$ 3-0 关于申诉
第一次OO作业的申诉经历,足以证明:我航学子的学品与素养,托得住,信得过。即使在OO的高压双盲互测体制下。依然可以保持人与人之间最单纯的信任,真心希望能与诸位同行一道,摒弃流言蜚语,摒弃偏见,以此课程平台为契机,增进交流,建立信任。学在其中,乐在其中。共同收获技术上的不断提升!致力于正能量的传递,我们一起!

 

$ 3-1 关于无效作业
在OO Project2 中,我遗憾的看到了身边有很多朋友被申报了无效作业。而产生无效的原因也很令人诧异。看到查找别人个人信息的方式也不禁令我大跌眼镜。故意找别人的个人信息申无效,难道这是课程组设计的本意么?交流技术,看代码,看文档就好。一般情况下难道会有人特意点开pdf属性看作者?或是用强行打开.project文件?就为了找个人信息申无效?为了多得分方法有很多,最好的方法还是做好自己的任务,毕竟每个人都很努力,还是希望能够彼此多尊重对方的劳动成果吧。

 


$ 4 特别致谢


“没有人是一座孤岛”。说实话,前三次作业的过程充满了艰辛,一路走来,必须要感谢在这一过程中给我最大帮助的朋友们。他们是:
中国好室友LCJ,对于我解决各种琐碎的疑难总是回应以最大的热情,尤其是第三次作业ddl前极限操作时帮我赶制readme和interface,让我至今回想起来都很感动。
RHX哥、ZZH哥,给我在解决问题上提供了大量宝贵的思路。NYZ、GZP在具体的技术实现的细节上给了我大量的指导。ZKN、LHY、LQY为我提供的大量测试用例,帮助我有效的检验修正模型。JSH搭建了公共测试平台并维护,造福全系同胞。
当然更要感谢在每次互测阶段,秉持公平公正、认真互测的测试者,和坚持积极沟通交流并给我充分理解的被测试者们,是你们让我看到的跟多的是这一机制的积极一面。

希望在紧接着即将到来的挑战中,总结经验、继续努力,不断提高技术能力。也希望能尽我个人之所能,为这一课程做出一份贡献!

OO第一阶段纪实

标签:read   提交   压力   java编程   技术   影响   ros   状态   mic   

原文地址:https://www.cnblogs.com/chrischen98/p/8708790.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!