软工实践寒假作业(2/2)W班
软工实践寒假作业(2/2)
这个作业属于哪个课程 | 2021春软件工程实践|W班 |
---|---|
这个作业要求在哪里 | 软工实践寒假作业(2/2) |
这个作业的目标 | 阅读《构建之法》并提问、WordCount编程 |
其他参考文献 | 无 |
1.阅读《构建之法》并提问
1.1阅读并提问
1.在阅读《构建之法》3.1 个人能力的衡量与发展 中的
初级软件工程师如何成长呢?我认为有下面几种成长
......
3.对通用的软件设计思想和软件工程思想的理解。这一方面就比较虚,什么是好的软件设计思想?什么是好的软件工程思想?一个工程师开了博客,转发了很多别人的文章,这算有思想么?另一个工程师坚持做任何设计都要画UML图,这算有思想么?
我有一个问题:学习了软件设计思想和软件工程思想的知识之后,显然并不是任何时候都要死板的按照所学的知识进行开发设计,软件思想的运用边界在哪里?何时该使用,何时不该使用?
我在网络上搜索开发者何时会使用UML图,有些基本不用,有些认为在有正规流程规范的公司工作才会使用,有些甚至不知道UML,软件思想似乎在实际开发中的适用范围似乎和模糊。
思考:同样是UML,我在学习完UML之后恨不得每做一个项目都画类图,这样显然不太对。个人认为编程需要软件思想的指导,但是不能死板地用所学的理论框住自己。但是对这一部分的理解还是有限,这个问题似乎有点大,我依旧无法清晰地知道自己在什么时候应该按理论要求开发,何时不要。
2.在阅读《构建之法》3.2 软件工程师的职业发展 中的
21世纪以来,中国大陆每年招收六百万大学生,其中的百分之十是在学习各种IT相关的专业(计算机科学与技术、计算机工程、计算机软件、软件工程、管理信息系统等)。扣除读研究生(最终大部分也会走上工作岗位)、出国等分流,同时考虑到培训机构给就业市场贡献的大量劳动力,每年大致有四十万到六十万左右的“职业软件工程师”进入工作岗位。
我有一个问题:科班出身的软件工程师和非科班出身的有哪些区别?如何在就业市场就业压力如此大的情况下发挥科班出身的优势?
前段时间看到一档综艺节目,里面有个工作室的程序员都不是科班出身的,原来有在工地搬砖的,有当护士的,有当电话客服的,让我感受到了这个行业的竞争之激烈。知乎上的一个回答指出,两者之间的差距在于非科班缺少根基,他们会去学习那些更有“价值”的东西,而忽略了基础。
思考:我认为知乎的这个回答是很有道理的,要提升自己的竞争力,基础知识就是拉开差距的重要点,这是优势也是今后学习应该顾及的点。
3.在阅读《构建之法》10.1 典型用户和典型场景 中的
阿超:所谓“Person-a”,就是典型用户,吴石头/石头他爹就是我们系统的两个典型用户。我们的确需要了解我们软件系统的用户(不是公司的商业客户),那么,什么是典型用户?在产品开发的过程中,我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示用户,如“家用电脑初学者”、“经验丰富的系统管理员”,现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念,而应该是一个活生生的人物。典型用户一般有哪些特性?一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
我有一个问题:如何确定软件系统的典型用户?
查阅网络资料,确定典型用户需要先收集用户数据,找到不同用户之间不同的行为,确定行为变量,最后用行为变量来找到典型用户。
思考:感觉网络上的这种方法先收集用户数据依旧讲的和模糊,收集哪些用户数据呢?这种方法感觉会有很多的不确定性。
4.在阅读《构建之法》6.1.2 敏捷流程概述 中的
冲刺期间,每天要开一个每日例会,团队成员大多站着开会,所以又称每日立会。大家依次报告:
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度,迫使大家把问题摆在明面上。
我有一个问题:如果团队成员在每日例会中迫于压力、碍于面子对自己的实际情况撒了谎,可能会打乱整个流程,该如何处理?
思考:老拖延症了。这种情况应该很考验Scrum Master ,需要Scrum Master协调好团队,搞好整个团队的氛围,营造一种大家都能实话实说,有问题大家一起解决的环境。其实这个问题可以扩展成:如果敏捷开发过程中出现意外,流程被打乱该如何处理?我觉得敏捷开发计划的周期比较短,应该不会造成很严重的后果。
5.在阅读《构建之法》16.1.2 迷思之二:大家都喜欢创新 中的
如果使用QWERTY键盘,那么只有10%的英语单词能在手指不离开键盘中列的情况下敲出来。但是如果使用Dvorak键盘布局,你可以在键盘中列打出60%的常用单词!这样会减轻手指和相关肌肉的负担,减少劳损,同时加快打字速度。......但是,长期以来,人们已经习惯了QWERTY键盘,所谓先入为主。
我有一个问题:当前中国人最离不开的软件微信,是否正在成为中国的“QWERTY键盘”?这样的软件存在是否会打击行业创新的积极性呢?
思考:我觉得微信不是中国的“QWERTY键盘”,至少现在不是,毕竟微信有痛点,也不是不思进取。微信确实给聊天软件的创新带来了巨大的阻碍,垄断行业让创新很难被注意,但是有意义的创意被行业注意只是时间问题,不思进取,被行业淘汰也是时间问题。
1.2附加题
RSA算法在软件开发中是常用的一种加密算法,它的命名是由三个提出者Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母组成的。
Rivest在阅读一篇新论文后,对文章中前所未有的思路兴奋不已,将其中的思想忘我地对Adleman讲解,Adleman却并没有太感冒。于是Rivest找到隔壁的Shamir拉来做同盟,开始他们的探索之旅。尽管 Adleman 不情愿参与其中,他们还是会把结果拿给 Adleman,Adleman 的角色就是逐个击破这些方案,找出各种漏洞,给那两个头脑发热的人泼点冷水,免得他们走弯路。最后论文发表时,按照惯例,Rivest 应该按姓氏字母序将三人的名字署在论文上,也就是 Adleman、Rivest、Shamir,但 Adleman 总觉得自己贡献微乎其微,不过是泼泼冷水,不至于还要署个名,便要求 Rivest 拿掉自己的名字。在 Rivest 的坚持下,他最终要求至少把Adleman的名字放到最后。也正因为如此,RSA 叫做 RSA没有被叫做 ARS。虽然 Adleman 一开始认为这注定是他诸多论文中最不起眼的一篇,RSA 走红后他还是调侃说,越来越觉得 ARS 更顺口了。http://localhost-8080.com/2013/12/history-of-rsa/
Adleman的谦让很有风度,非常潇洒。我们应该看到这种行为对团队成员的启发,做好自己的事,不邀功,不抢别人的功劳。此外,我认为Adleman的角色在这三个人中,并不是可有可无,对成员进行鞭策纠正是很重要的工作。
2.WordCount编程
2.1Github项目地址
项目地址:TarsSE/PersonalProject-Java
2.2PSP表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 180 | 240 |
• Estimate | • 估计这个任务需要多少时间 | 180 | 240 |
Development | 开发 | 1380 | 1800 |
• Analysis | • 需求分析 (包括学习新技术) | 120 | 240 |
• Design Spec | • 生成设计文档 | 60 | 120 |
• Design Review | • 设计复审 | 60 | 90 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 60 | 60 |
• Design | • 具体设计 | 120 | 90 |
• Coding | • 具体编码 | 600 | 780 |
• Code Review | • 代码复审 | 120 | 120 |
• Test | • 测试(自我测试,修改代码,提交修改) | 240 | 300 |
Reporting | 报告 | 240 | 300 |
• Test Repor | • 测试报告 | 60 | 60 |
• Size Measurement | • 计算工作量 | 60 | 60 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 120 | 180 |
合计 | 1800 | 2340 |
2.3解题思路描述
思考过程:
1.第一次看整个程序的需求,脑子乱乱的,要求不多但是组织的有点乱,一下子看不过来,就决定先将程序分解成多个类,各自处理一些功能,最后再整合起来
2.按照对文件处理粒度先分为三个类分别处理字符,单词,行,因为从一整行内容中将单词分离感觉比较复杂,将这些类处理的基本单位定为字符,单词按照一个一个字符组成,行按照一个一个字符组成
3.处理字符的类主要用于判断ASCII码
4.处理单词的类要实现单词构建,单词校验,单词总数统计,各单词频数统计,以及按照频率和字典序排序单词的功能
5.处理行的类要实现行构建,有效行判断的功能
6.因为将程序分为多个功能,为了保证每个部分都可靠,减少后期返工的麻烦,单元测试部分打算每完成一个功能就测试一个功能,最后再测试整合后的程序
7.各个分离的功能都实现后写main函数和构造接口都是很自然的,会涉及文件的处理
8.最后对程序进行性能测试和优化,优化后再完整的进行一次单元测试
找资料过程:
1.《构建之法》
2.要求中提供的资料
3.百度/Google
2.4代码规范制定链接
代码规范地址:Tars的Java代码规范
2.5设计与实现过程
1.在一开始就把程序分出了多个类,分别处理字符、单词和行,三个要求的接口都封装到WordCountCore类下,此外使用一个类保存一些全局常量,方便修改一些需要经常用到的量,以及WordCount类包含main函数,共6个类
2.处理字符的类AsciiCharCounter主要用于判断字符类型
public boolean isAsciiChar(int inputChar) {
boolean result = false;
if (inputChar < 128) {
result = true;
}
return result;
}
函数通过字符编码判断是否为ASCII字符
-
统计文件字符数
将读入字符使用isAsciiChar判断,若为ASCII字符则字符数加一。
3.处理单词的类WordProcessor我认为主要的难点在于如何将单词从文件中通过一个一个读取字符,将可能符合要求的单词提取出来
StringBuilder possibleWord;
public boolean buildPossibleWord(char scanChar,boolean isEndOfFile) {
isPossibleWordAvailable = false;
if (!isEndOfFile) {
if (isLetterChar(scanChar) || isDigitChar(scanChar)) {
if (!isInPossibleWord) {
isInPossibleWord = true;
possibleWord = new StringBuilder(INIT_WORD_MAX_LENGTH);
}
possibleWord.append(scanChar);
} else {
if (isInPossibleWord) {
isInPossibleWord = false;
isPossibleWordAvailable = true;
}
}
}else {
isPossibleWordAvailable = isInPossibleWord;
}
return isPossibleWordAvailable;
}
函数在读取到字母数字以外的字符或读取到文件末尾时,之前读取到的字符就有可能组成全部是字母和数字的字符串,从而提取出文件中独立的字符数字串,进而进行进一步的合法单词判断。
-
统计单词数
将分离到的可能是单词的字符串使用isLegalWord函数进行判断
isLegalWord函数对合法单词的判断过程为
读取到合法单词就将合法单词数加一
public boolean allWordSumUp(){ boolean isLegal = false; if (isLegalWord(possibleWord)) { wordSum++; isLegal = true; } return isLegal; }
-
统计各单词出现次数
private Map<String,Integer> wordSumMap = new HashMap<>(); public boolean individualWordSumUp(String legalWord) { boolean isCounted = false; legalWord = legalWord.toLowerCase(); if (wordSumMap.containsKey(legalWord)) { wordSumMap.replace(legalWord,wordSumMap.get(legalWord) + 1); isCounted = true; }else { wordSumMap.put(legalWord,1); } return isCounted; }
使用individualWordSumUp函数对各个单词频数进行统计,统计过程为:
1.将单词都转换为小写,忽略大小写的影响,同时也符合输出时使用小写的要求
2.在存有单词和频数对的Map中查找要统计的单词是否之前出现过
3.若单词之前已统计,则将对应的频数加一,否则构建新的单词频数对添加到Map中,频数设为1
-
输出频率最高的10个单词及频数
要统计词频最高的十个单词,需要对单词-频数对进行排序,使用Java自带库将Map转换为List再使用List接口的sort方法对List排序
其中sort方法需要提供自定义的比较器Comparator,对照作业要求,比较器先比较单词频率,再比较字典序,字典序的比较使用String类的compareTo方法
private final Comparator<Map.Entry<String,Integer> > wordComparator = new Comparator<Map.Entry<String, Integer>>() { @Override public int compare(Map.Entry<String, Integer> stringIntegerEntry, Map.Entry<String, Integer> t1) {//s<t1返回正 int result = t1.getValue() - stringIntegerEntry.getValue(); if (result ==0 ) { result = stringIntegerEntry.getKey().compareTo(t1.getKey()); } return result; } }; public List<Map.Entry<String,Integer> > getSortedWordCountList() { List<Map.Entry<String,Integer> > wordList = new ArrayList<>(wordSumMap.entrySet()); wordList.sort(wordComparator); return wordList; }
4.处理行的类重点和处理单词的类相似,如何把行内容从文件中提取出来
提取行内容的方法与提取单词的方法相似,只是把分隔符换为'\n',对行内的内容不做要求,换汤不换药,这里不再赘述。
-
文件有效行数的判断
public boolean isEffectiveLine(){ return (lineContent.toString().trim().length() != 0); }
因为Java8没有isBlank函数,因此使用了一种曲线救国的方法,删去空白符,再根据字符串长度判断是否为有效行。从后面的性能测试来看,这种方法还是会消耗比较多的时间,不够直接。
5.接口封装
程序功能分解的比较细,计算模块的接口就是上述类方法的组合
-
统计字符数
1.将字符从文件中读入
2.使用AsciiCharCounter对字符统计判断
-
统计单词数
1.将字符从文件中读入
2.使用WordProcesser的buildPossibleWord方法对单词进行构建,若构成了可能合法的单词,使用WordProcesser的allWordSumUp进行验证和统计。
-
统计最多的10个单词及其词频
1.将字符从文件中读入
2.使用WordProcesser的buildPossibleWord方法对单词进行构建,若构成了可能合法的单词,并且经过验证是合法单词,使用WordPricessor的individualWordSumUp对各单词分别进行统计
3.最后使用WordCount的getSortedWordCountList方法获取排序后的单词-频数对构成的List,再对List进行修剪,最多保存10对。
6.WordCount实现
WordCount进一步对各个功能进行了整合,使用上述各种类方法,主函数执行时能够只读一遍文件完成对字符的统计,单词的构建校验和统计,各单词的词频统计以及排序,行的构建以及有效行的判断和统计。
2.6性能改进
性能测试方面使用一个8.17MB 包含8500k+字符的文件进行测试
优化前,使用JProfiler进行测试发现整个程序中InputStreamReader的read和StringBuffer的append方法耗费了较多时间,于是上网找资料进行优化:
1.使用InputStreamReader构造BufferedReader,用BufferedReader的read方法替换InputStreamReader的read方法,BufferedReader带有缓冲区可以将一定大小的文件内容读入内存,不必频繁地进行系统调用,读取硬盘,减少IO时间
2.经过网络搜索,发现对字符串的拼接有三种方式:String的concat,StringBuffer的append,StringBuilder的append,其中StringBuilder的append效率最高,StringBuilder的append次之,String的concat效率最低,看别人对这三种方法的测试,StringBuilder的append和StringBuilder的append差距并不大,将StringBuilder的append换为StringBuilder的append之后,性能是有所提高的。
3.在代码复审时发现了一个遗留问题,在实现各单词频数统计时使用的Map是TreeMap,TreeMap是基于红黑树实现的,查找和插入的时间复杂度为O(log n),而使用HashMap时间复杂度为O(1),在频繁插入的情况下,HashMap会快得多,统计各单词词频使用的Map功能基本上都是基于查找和插入实现的,因此将TreeMap换为HashMap,进一步提高效率。
性能优化后的调用数及执行时间:
在性能优化方面大概用了3个小时,包括学习JProfiler的使用,以及各种优化方法的学习
2.7单元测试
2.7.1单元测试覆盖率
2.7.2测试函数
单元测试大量使用到文件,将测试数据保存在文件中,这样的好处在于:1)一个测试数据文件可供多个测试函数使用,提高利用率;2)不必在测试类中保存测试数据,在重复使用到测试数据时,不用大量复制数据,让代码更干净
例如以下对核心模块的部分测试代码,一个文件可供多个测试函数使用,在其他测试类中也可使用,测试类中没有保存测试数据,整体比较整洁
class WordCountCoreTest {
WordCountCore wordCountCore = new WordCountCore();
File testFile1 = new File("testText\\test1.txt");
@Test
void countChar() {
int characterNum = wordCountCore.countChar(testFile1);
int actual = 237;
assertEquals(characterNum,actual);
}
@Test
void countWord1() {
int wordNum = wordCountCore.countWord(testFile1);
int actual = 25;
assertEquals(wordNum,actual);
}
}
测试数据的构造,先按照比较正常的数据测试保证基本功能的正确实现,再到比较诡异的测试数据,测试在极端情况下程序的执行,构造测试数据,需要足够了解自己写的代码,照顾到方方面面。这一点证明开发人员要负责自己所写代码的单元测试是合理科学的
2.7.3如何优化覆盖率
利用工具,比如使用IDEA测试,已覆盖的代码在左侧行数条上会被绿色覆盖,未测试到的为红色,根据非测试到的代码构造相应的测试数据就可以提高覆盖率。当然,单元测试覆盖率不能说明软件质量,依旧需要构建合适的测试数据进行进一步测试。
2.8异常处理说明
程序对文件不存在进行了异常处理,这种异常出现在用户传入的文件路径不存在时。
单元测试样例:
String notExistFilePath = "testText\\test1";//不存在的文件路径
@Test
void main4() {
WordCount.main(new String[]{notExistFilePath,"output.txt"});
}
此外还有UnsupportedEncodingException和IOException。UnsupportedEncodingException在传入的编码字符串错误时抛出,在程序中只有源代码被修改,代码里的编码字符串错误时才会出现,一般很少出现。IOException在读写异常时出现。
2.9心路历程及收获
2.9.1心路历程
- 一开始看到编程作业的要求感觉会是一个很复杂的系统,再看截止日期,心里就想,好日子到头了。很庆幸一开始就决定把任务分解成好多个小的部分,其实助教在作业要求里面也是在拼命暗示分解,最后实现的时候目标就比较明确,而且做完之后感觉也没那么复杂。
- 刚开始要分解是没错,但是我在实际的分解中依旧纠结,该怎么分,这样分对吗,依旧不是很有头绪。
- 在这次作业中实践了单元测试,感觉测试能给人成就感。做完一个部分,测试一下,这只有问题,改一改,再测一遍,通过,唔,我真的很不错。
2.9.2收获
- 更加熟练Git和GitHub的使用。以前使用GitHub进行团队开发是真的小白,每次提交都会有很多冲突,大家都是用GitHub Desktop手动处理冲突,现在进一步深入使用学会了.gitignore的使用,每次commit也越来越熟练了。
- 学会使用用工具性能测试进行性能测试。在这次作业中,我初步学习了JProfiler的使用,能够根据测试结果有针对的对效率低的代码进行优化,摒弃了以前想到哪里可以优化就优化到哪里的盲目行为。
- 单元测试是个好东西。原来测试是有章法的,以前对程序的测试也是盲目的,一般都是整个项目完成之后才会开始测试,这个时候测试通常都很头疼:项目已经有了一定规模,很难照顾到方方面面;找到bug却很难定位,改要改一大堆。现在把单元测试分散到开发过程中,问题好解决了,而且有工具辅助,让测试可视化,成就感满满。通过这次作业,还亲自体会了测试覆盖率不等于代码正确率的血一般的教训。
- 重拾Java。这次选Java进行开发,对Java一些基础的运用都有所涉及,自己也通过网络搜索等方式对一些生疏了的知识进行了复习。