个人作业——软件工程实践总结&个人技术博客
| 这个作业属于哪个课程 | 2020春|W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 软件工程实践总结和个人技术博客 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 软件工程实践者的研究方法,github |
1 回望
1.1 对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
在开篇博客中我当时写到:当时就觉得软件工程就是大家在一起指定开发计划,实现一个软件开发过程的软件,幻想着能够开发一些好玩的软件
- 到目前为止，我觉得代码的编写能力以及自学能力都达到了我的期待和目标。因为我觉得我从这门实践课中掌握了挺多的代码编写经验，自学能力也得到了提高,与此同时我学到了很多有意思的开发工具。
- 不足方面是缺乏规范的软件设计能力和代码风格。因为在最后的软件实践作业中，代码并不是特别规范，也缺乏相应的设计方法。再设设计软件的细节上还有很多欠缺,经常考虑不到位
- 我的团队合作能力还是不足,很多东西没有跟团队中的其他人商量好,导致拖延了时间,比如当初设计接口的时候没有实际更加具体的格式,有的需要@RequestBody,有的不需要,这个问题导致我们在刚开始登陆的时候就出现了问题
1.2 你在第一次作业的个人简历中制定的这门课程结束后，你预期你将增长的能力、技术、技能；和你针对你的目标绘制的学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
这是我在当时提出来的预期的目标
| 预期值 | |
|---|---|
| 工程能力 | 望能学习到能在团队中担任骨干,并指定开发过程,提升全局能力 |
| 技术技能 | 在后端技术的应用上更进一步 |
如果从现在上来看,这个目标定的还是太过宽泛,比如说担任骨干,什么是骨干,是担任了组长还是担任了后端开发的组长,还是带头进行了系统设计?
不过从现在上来看,我还是达成了一部分,在原本小组中,我负责制定了主要的接口,并带头进行了接口相关的讨论,完善了接口文档,为我们后续的开发提供了一定的参考价值,从这个意义上来讲我还是达成了我刚开始制定的目标
对于技术能力,我学习了许多的工具和框架,比如springboot,netty,postman等等,这些都给我的开发带来了许多的便捷,我认为我的后端技术虽然还有很多欠缺,但是我已经有了一些软件工程的感觉了
对于我绘制的学习路线图,当时给出了以下的学习路线图
可以看到这个学习路线图还是比较完整的,不过说实话这学期由于我的课还是比较过,再加上软件工程都在学习实践的东西,因此我主要看了JavaWeb基础到JavaWeb进阶的内容,其他部分还是看的比较少,但是我现在对Java后端开发已经有了一定的基础了,这个目标算是达成了一半
1.3 请总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
统计一下，你在这门软件工程实践中，一共完成了多少行的代码
我的总共代码行数在3000行左右
-
软工实践的各次作业分别花了多少时间?
| 作业 | 时间 |
|---|---|
| 寒假作业1 | 5h |
| 寒假作业2 | 30h |
| 结对作业1 | 20h |
| 种子队选拔和团队展示 | 5h |
| 结对作业2 | 24h |
| Github团队实战 | 8h |
| 需求分析 | 8h |
| 系统设计和数据库设计 | 9h |
| 软件评测 | 8h |
| alpha冲刺 | 70h |
| Beta冲刺 | 70h |
-
哪一次作业让你印象最深刻？为什么？
最让我印象深刻的是alpha冲刺,这次的作业可以算作是我真正意义上的第一次团队开发实践,其中的难点,问题数不胜数,有些很难解决,那种从早写到晚的感觉确实是第一次出现,最后反复的测试和修改bug更是让人印象深刻
-
累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 大约总共有300小时， 平均每周花20个小时。
-
学习和使用的新软件
idea: 现如今最流行的Java开发ide,虽然eclipse是免费的,但是论易用性还是收费的idea更好一点
github: github平台的熟练使用和使用频率在一定程度上体现了一名工程师的基本素养
-
学习和使用的新工具
- 原型设计工具: 由于不同人和后面团队开发的使用习惯,以及不同软件的功能差异,我使用了以下三款原型设计工具
墨刀
mockplus
Axure
-
markdown: 作为一名IT从业者不会markdown是难以想象的,我主要使用了typora作为markdown编辑器
-
postman: 我主要做的是后端,为了能够测试接口,接口测试软件是必须的
-
xmind: 思维导图软件是整理大纲的好用的工具
-
学习和掌握的新语言、新平台
-
java: 能够更多地了解Java的一些特性,比如说我就用到了一些jdk8的新特性
-
移动端: 这次我们需要开发移动端,我还顺便了解了移动端h5开发,算是对移动端有了一点了解
-
-
学习和掌握的新方法
- 原型设计: 在本软工实践中,前面的结对作业让我第一次认识得到了什么是原型设计,我还掌握了三种原型设计的工具
- 团队协作: 团队开发才能今后工作的主旋律,如果不能很好地融入到团队之中,就不能发挥自己的能力,在这次软工实践中,无论是结对编程还是团队编程,如果商量接口如何确定细节,都给我带来了很多的成长
- 单元测试: 单元测试是软件测试中一个至关重要的步骤,是保证软件质量的一个重要环节
- 代码调试: 通过使用idea进行断点调试能够比输出语句更快的掌握错误的位置
- 接口测试: 当今前后端分离的趋势越来越明显,通过一个专门的工具进行接口测试是必备的技能,比如postman
- 接口设计: 一旦接口确定下来了,编码功能就能够很快的进行,通过一些专门的工具进行接口的管理是很重要的
- 需求规格说明书: 通过编写完整的需求规格说明书,能够让原本看起来很难的应用逐渐明朗,减少编码过程中的问题
- 软件测试: 软件测试除了包括单元测试还包括了接口测试,模拟环境测试,真机测试,我们这次又安卓端的应用,因此采用了安卓模拟器和真机测试
- 版本控制: 在没有使用git之前每次不确定的改动都需要复制一份原来的文件,很容易导致混乱,在学习了git之后这份难题就比较容易地解决了
-
工程能力的提升
- 代码阅读: 我在aplha阶段其实没写几行代码,大部分时间都是在测试,这个时候阅读别人的代码,并能找到错误的地方就至关重要
- 代码重构: 在beta阶段,由于时间比较紧张,刚开始很多代码都没有仔细想导致出现了许多问题,后来再写的过程中抽取了一些公共的代码,优化了逻辑
-
团队合作上的提升
- 前后端沟通: 由于我们都没有接触过聊天类软件的开发,因此当初设计接口的时候很多东西都没有考虑到,因此很多情况下都是靠前后端开发过程中约定接口来实现的
-
测试: 每一个人对同一部份做测试的时候,有可能会从不同的角度对代码进行修改这时候要沟通好
- 设计商量: 我在第一部分主导了接口设计,我们开了好几次组会来修改接口中可能存在的问题,算是为后期开发奠定了一定的基础
-
其他方面的提升
- 变得更加有耐心，自学能力也得到了提升。
- 对于时间安排还是有有了一些自己的心得
- 具有了更好的抗压能力
2 团队总结
2.1 如果你是组员，你觉得你的组长分工安排是否合理？你对组长的选举有什么建议？
我觉得我们组（RATE-MAX）组长分工比较合理，只不过刚开始我们都不是很熟练,熟练了之后分工起来就轻松多了。
组长的选举我们采用了组内推荐,我认为就这样组内推荐蛮好的。
2.2 你这学期经历过换组吗？你对换组有哪些看法？谈谈你在这个过程中的感受。
我这学期经历过换组,怎么讲呢?其实很多人都是由思维惯性的,因为我们是自由组队,大家都会跟熟悉的人组队,我自己其实对自己的沟通能力蛮不自信的,很但是换到新组之后拖后腿或者说沟通不顺畅,还有一点就是谁都希望得在原来的组把原来的项目给做完,这种临时做一半的感受挺不舒服的
但是这算是对于真是工作的模拟吧,毕竟真是工作中调换人员的情况还是很多,整个交接中我自己表现得也不是很好,感觉自己能力不太行,有些倦怠了,最后的结果也不太好,但是都算是一种体验吧,以后希望我能够更从容一些
2.3 分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建之法》第17章 人、绩效和职业道德）
我们的团队虽然没有特别厉害的人,但是大家都还在尽力的相互沟通学习,在最后也拿出了一些成果,虽然已经达到了萌芽和磨合阶段,如果从结果上来看明显是还没有达到创造阶段
3 人月神话
3.1 怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一。
我们的软件是前后端分离的,都分别有一个github仓库,每个部分都能够独立的运行,我们能够在此基础上进行更进一步的开发和迭代
前端地址:https://github.com/giraffe28/sevenDaysUI
后端地址:https://github.com/HongJieBin/RATE-MAX_sevenDays
3.2 写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析，文字部分字数要求在100字以上，可以使用你自己喜欢的方式表达(如图文结合、视频)
- 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大
在aplha和beta阶段如果没有紧锣密鼓的安排好项目进度,很容易导致一些功能的完成时间被延后几天,导致对于整体进度的拖慢,比如在aplha阶段我们对于登陆验证的功能商量了一会,就导致了这部分本应该很快完成的功能被延后了
- 我们的构思是有缺陷的，因此总会有bug
这个点是比较明显的,在alpha阶段,我们有一些明显没有想好的点比如进入好友列表的时候会去抓取好友的列表来进行渲染,但是由于许多切换页面的时候都需要刷新,导致了可能会重复抓取好友列表,导致用户体验不佳,还有就是对于标签的渲染,刚开始我们没有商量好存储格式,倒是渲染会出现问题
- Brook法则：向进度落后的项目中增加人手，只会使进度更加落后
如果是已经经历过实际开发的团队可能是这种情况,但是对于能力还不够强的学生来说这个结论可能就不成立了在β冲刺的时候前端人手不够,原本后端的人员调整了两个去前端,虽然最后进度还是不太行但是还好还有有一点成品出现的
4 建议
4.1 对下一届同学的建议
请在正式开始这门课之前最好心理准备,一定要在每个环节都紧跟课程的脚步,由于任务比较密集,而且有一定的难度,所以请不要在任何一个环节松懈,绷紧神经,在课程结束后你会感觉到自己质变了
如果你能在大学前两年就参加过团队开发,那么相信你会比较得心应手,游刃有余,能够在软件工程这门课上大放异彩
我并不认为干一行爱一行是正确的,获取你们会在机缘巧合之下知道了你一生会从事下去的事业,或许你被调剂到了你很不喜欢的专业,但是请记住无论在什么情况下,如果你能厚着脸皮去追逐你喜欢的东西,那么我认为你一定会成功的
4.2 对于软工实践课程，你有哪些建议？
对于这门课程,虽然我完成得不是很好,但是我还是有一些建议提供参考
- 在Git实战中我认为时间最好是两天,其中一天最好能够讲解git使用过程中容易出现的问题
- 希望能够在课程中展示一下往期的作品,以供参考
- 希望能够提供一些团队开发中比较经常使用的工具集
4.3 对于助教工作，你有哪些建议？
- 助教可以多开开直播讲解一下自己的开发学历历程
4.4 对于自己今后，你有哪些建言？
- learn by doing如果想要学习什么技术,找到一个方向,大胆去做吧,不经过实践就不会成长,没踩过坑,就无法把控软件开发过程中的难题
- 请提升你的沟通能力,没人会在意你幼稚的言论,大胆出丑,虚心学习,成长就是这个过程
5 个人技术总结
概述:
在进行环境搭建的时候我发现国内的spring+springmvc+hibernate整合资料比较少,即使有的话要么就是将所有配置放在一个配置文件,不易于理解结构,要么就是版本太旧,因此这篇文章简单讲解了如何配置相关的开发环境
6 阅读笔记
我阅读的论文为
Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87
6.1 开源软件(OSS)与闭源软件(CSS)
是什么定义了一个软件为开源软件,这个答案并不简单,通常认知意义上来说我们会认为如果一个如果一个软件发布的时候伴随着一个符合开源定义的许可证那么他就是开源软件
一般来讲开源软件都是可以免费使用,修改重新发布,我们可以自由的访问它的源码,当然我们也会发现一些闭源软件转变为开源软件来获取好处的事情也越来越多,典型的就是.net core的开源
对于许多著名的开源项目,它的整体管理流程更像是一个专业的软件公司,
- 个人或者小组开发一个最初的版本
- 发布到网络,并邀请其他开发者加入
- 由项目的创建者进行整体开发流程的协调
- 而除了项目创建者其他人员被称为协调者,协调员的职责包括配置管理、发布计划、决定哪些代码贡献将被接受，以及其他管理活动
- 当然我们有时候需要注意,协调者可能会有更多的权力,很大程度上一个项目是否活跃,取决于它的协作者
OSS开发强调已发布的软件可维护性,正式由于这种模式,导致了一般情况下这种方式好像解决了传统软件开发的问题,当然这种模式也是有缺点的比如缺乏完整的文档和技术支持,如果我们联系一下显示就会发现微软的文档事无巨细,而开源软件的文档一般由参与者维护,但是对于个人来讲可能并没有太大的区别
除此之外我们比较难以对开源软件进行监控
6.2 源码测量
对于一份源码来讲我们如果能够预测其外部特性例如可维护性,可靠性等,我们对一份源代码就有了可靠的信息,我们需要对于源代码的每一个部件进行测量来获得一些有效的信息包括代码大小,代码复杂度,他有一套标准的评估方案,在这篇论文中他们使用了Debian GNU/Linux发布的一组测量程序,包括了以下几个部分
-
代码行数
-
用来描述代码的注释行数
-
Halstead数量,它提供了四个数量来度量软件分别为
- n1: 不同运算符的数量
- n2: 不同操作数的数量
- N1: 总操作符的数量
- N2: 总操作数的数量
在这之后我们有定义了三个标准
- n = n1 + n2
- N = N1 + N2
- V = N * log2(n)
-
环路复杂性V(g): 计算独立路径的数量
有了这些信息我们就能够计算一些有用的信息例如Maintainability Index (MI),它的计算公式如下
其中的指标是针对每一个部件来说的,如果说MI越高代表越好
6.3 衡量和评估开源代码
有了上面的指标就可以对一个开源项目进行评估了,在这里我们比较了几个项目
PrA最初是一个开源项目,随后演变为CSS
PrB最初是一个CSS项目,随后演变为开源项目
PrC和PrE是开源项目
PrD最初是一个学术项目随后演变为开源项目
经过比较发现,只有PrE维持了比较好的可维护性
6.4 代码质量需要监控和改进
尽管我们可以从上面的分析中得到一些结论,但是我们认为这些项目的可解释性如下
- 使用工具进行测量时OSS至少与CSS相当可能是与OSS的工程师动力比较大有关
- 由于OSS项目协调员的决定会导致后续版本之间的突然更改，因此OSS项目可能需要进行仔细的个人分析，这些更改对OSS软件配置有很大的影响。
- 随着时间流逝OSS的可维护性也会下降
从以上的分析表明从CSS到OSS软件的可维护性并没有下降许多,甚至会更好,对于开源代码软件的可维护性也变得至关重要起来
