其他分享
首页 > 其他分享> > 莫生气❤可爱!?

莫生气❤可爱!?

作者:互联网

这个作业属于哪个课程 2021春软件工程实践|W班(福州大学)
这个作业要求在哪里 作业要求
这个作业的目标 课程回顾与总结
其他参考文献

第一部分:课程回顾与总结

给自己的总结博客起一个有意义的标题

很喜欢的一首诗,作业做急了就背一背。

给出以前提问题的博客链接

提问

请尝试对自己曾经提出的问题进行解答,并阐明,是如何通过看书,实践,或者讨论弄清楚的。

问题一

在第二章 个人技术和流程中,讲到如果用随机数以增加测试的真实性是不好的,他的回答是:

我们还是要用随机数等办法“增加测试的真实性”,但不是在单元测试中。

对此我有疑问,什么是单元测试?为什么不在单元测试中用随机数等方法增加测试的真实性?

当时我的答案是从构建之法和网上百度查到的:

单元测试(unit testing):是指对软件中的最小可测试单元进行检查和验证。
而随机数进行测试时导致程序出错后,不能确保下一次运行又能重复这次错误。单元测试是为了保证某一小部分功能的正确性,以确保不会影响到整个程序运行,所以它必须包括输入数据和预期结果。

在经历本学期软件质量测试和软件工程实践之后我才真正理解了单元测试并且实际动手进行了单元测试,也体会到了随机数测试的弊端,因为不能还原测试场景,所以就只能看到出错,难以进行debug,找不到出错的原因(这点在我β冲刺时深有体会)。

问题二

在第四章 两人合作中,提到的结对编程的方法让我难以体会到他的高效性,虽然说这样的安排可以让代码更规范,错误也会减少。但是就我自己来说,从来没有试过两个人一起编程。我认为结对编程会导致我在投入编程时思路被频繁打断。那为什么要采取结对编程呢?
我当时的回答时:

在查阅资料后我注意到一点,越是顶尖的公司,他们越愿意采取结对编程的方法,这从侧面证明了结对编程一定是有价值的,是利大于弊的。而且我还在网上看到一个软件工程师的发言“结对编程只有体验过的人才知道他的功效”,在他的观点中,结对编程是最好的“老带新”的方法,两个人的磨合可以让新人快速成长。在有些模块中,结对编程可能并不适用,但是在培训和做重要、基层模块时,它能起到十分优秀的效果。

而在软件工程实践之后,我切身地体会了结对编程,结对编程不仅仅适合老带新,在两个人都是新人的时候也会有很好的促进作用,虽然效率上确实没想的那么快,但是学到了很多,代码也更为完善。

问题三

在第二三四章中,我看到了审查的重要性,那审查环节是怎么进行的呢,是由专门的人负责吗?

在询问过一个认识的在佛山工作的程序员之后我才知道,不是所有的公司都会采取像教材中那样的方式。在小公司中他们采取的是每个人负责一块,自己进行自己模块的审查,只有测试环节是别人做的,甚至在有些小项目,测试环节也是自己进行的。这种形式更类似于我们学生在学校的合作模式。造成这种模式的原因我觉得是为了效率,以及团队代码的不规范。这种合作方式是有局限性的,所以我们要从现在开始就有意识地规范代码。

问题四

第十六章讲了好多关于创新的案例,但是我有个疑惑,关于创新的方向和时机这些问题是应该又程序员来考虑的吗,不应该是策划之类的?

一开始我一直认为程序员要做的就是完成自己的那块任务,但是实际上程序员的编程环节第一段就是需求分析,在实际工作中不像做题这样,划定了输入输出,有着标准答案。在需求分析中,我们就应该找到创新的机会。而策划的工作是负责公司项目企划工作的全面掌控。包括组织、参与、指导企划方案的制定。他可以进行工作的分配,而如何实现功能还是要看我们程序员。

在创新创业课之后我有了更深的体会。程序员和项目的安排是分不开的,不管是项目的时间线还是项目的可行性,都取决于程序员。可以说整个项目的核心仍然是程序员,程序员的想法会左右项目走向,根据需求,程序员要确定方法实现。

问题五

在十六章中我了解到,那些行业的先驱者不一定就是最后的赢家,那些先驱者为什么没能保住优势,反而被后起之秀替代了?

通过网上收集资料和构建之法的例子中我发现,这些先行者失败的原因大多有两方面,一方面是资金不足。新的领域有着新的风险,新的创新的用户是有一个增长过程的,一开始的投入往往得不到相应的回报,便难以继续发展。另一方面是由于没能继续创新,成功的公司也需要不断的创新,比如google搜索引擎,虽然是后面才加入的企业,但是它采用了分布式爬行系统网页采集技术、页面等级技术和超文本匹配分析技术,提供图像搜索功能、学术搜索、地图搜索、在线翻译、新闻网站群、年度排行榜、网页快照、语言转换等功能。在先行者的基础上继续创新,才能有今天的成就。

是否原来的问题还不明白?如果有,请分析

是否产生了新的问题?如果有,请提出

请问你在项目的需求/设计/实现/测试/发布阶段(一共5个阶段)中,每个阶段收获最大的知识或能力是什么?

需求:

大多数情况都是和队友一起进行的,感觉到需求分析真的很重要,比如我第一次结对的时候需求分析没做好就到了原型设计就一直在回头翻作业要求。所以开个好头真的很重要。

设计:

在团队作业的时候我是负责游戏逻辑那块的,那时候和负责接口和服务端框架的讨论了好久游戏的逻辑实现方法。设计环节和队友的沟通很重要,要让全队达成共识。在设计阶段我学会了怎么和队友沟通,也学会了原型设计和逻辑的具体表达(如流程图等)。

实现:

结对作业中学到了VUE和TP5框架,在团队作业中学习了Unity3D引擎。都是没接触的东西,很好玩,原本都不知道一个游戏是如何运作起来的,现在看到了游戏的背后,颇有感触。
团队作业的实现未达到我的预期,我认为每天开会是很必要的,这可以监控全队进度,好把握项目方向,及时做出改变。

测试:

这是我团队作业最最最最最折磨的部分,卡牌游戏的逻辑是真的复杂,这阶段我做了白盒黑盒测试,每个单元都测过了,还压力测试冲了一下,主要我的代码只有我能维护,别人也测试不了,感想是以后就业一定不当测试。

发布:

在团队作业里这阶段我也不大清楚,我不是搞这块的,在结对作业的时候,我负责云服务器的部署,window大小写不敏感,CentOS大小写敏感,害得我找了好久问题找不到,只能说体验了一下云服务器部署,挺有意义的。

结合自己在个人项目/结对编程/团队项目的经历,谈谈自己的理解或心得

个人项目:

我在个人项目是没分数的,因为提交的格式不符合要求,虽然后来测试也错了两个点就是了。给我的感觉就是很功亏一篑,很亏。反思到了无论做什么都要自私,越接近结束越不能松懈。

结对编程:

学到了很多新知识,最开始拿到题目的时候人是很奔溃的,感觉无从下手,还好是结对作业,两个人一起加油撑过来了,也收获了很多新技术,就是压力好大。

团队项目:

一开始大家都很有梦想,敲定了做卡牌游戏,很神奇其实,我们这组没有半个人有unity基础的,都是从零开始的(队名的由来),大家也都撑过来了,罗汉组就是玩得很开心,大家一起搬去一个宿舍加班的时候效率是最高的。尽管成品没有达到预期,但是我认为大家已经做的很好了。虽然知道应该西区教训量力而行做好规划,但是如果还有下次应该还是会一股脑朝着感兴趣的东西冲,尽管完全不会。

第二部分:个人技术总结

标签:结对,单元测试,编程,作业,莫生气,程序员,测试,可爱
来源: https://www.cnblogs.com/Murasame-E/p/14940288.html