ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

哈哈哈

2021-06-28 11:05:16  阅读:169  来源: 互联网

标签:MVP 结对 代码 编程 用户 测试 哈哈哈


软工实践总结博客

这个作业属于哪个课程 2021春软工实践|W班级(福州大学)
这个作业要求在哪里 软件工程实践总结&个人技术博客
这个作业的目标 对该学期的课程学习进行总结

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

博客链接

寒假作业2

问题一:

在2.1.2中,作者认为,单元测试必须由最熟悉代码的人,也就是程序的作者来编写,从大体上来讲,我是支持这个想法的,毕竟代码的作者是最了解代码的目的、特点、流程的人。但是,有时候可能往往因为这代码是自己写的,自己的想法就已经局限在这里面了,就没有意识到某些问题。比如这次作业的单元测试环节,我在编写写测试样例的时候,能想到的例子往往都是在编写代码时候有考虑到的情况了,而一些潜在的易错的点往往自己却不容易发现,因此我认为作者该处的说法并不完全正确。

通过本学期的课程学习,以及软件工程实践,我认识到了软件测试的过程并不是单一的,它包括了单元测试,集成测试,确认测试,系统测试,验收测试等环节。因此,我逐步对2.1.2作者的想法有了理解和认同,除自己本身外的专业测试人员,可以站在更高的层次对软件进行测试,通常采用黑盒测试。当发现有问题或者bug的时候,再详细到更具体的模块、单元,然后由最熟悉改块代码的程序作者进行单元测试的编写找出真正的问题所在,通常采用白盒测试。

问题二:

在4.5.2中,作者提出了结对编程的协助模式,每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样,程序中的错误就会少很多,程序的厨师质量就会高很多,这样会省下很多以后修改、测试的时间。书中介绍了不少关于结对编程所带来的好处,这里就不详细列举。不过,在我看来,作者的想法是否过于理想化?如果回归到现实,在一些相对极端的情况下如两个同学编程经验都不多,这样是不是就等于一对跨了呢?又或者出现"一神带一坑"的情况,编程能力高的人是否会被拖后腿,编程能力低的是不是就可以"躺赢"呢?

体验过结对编程之后,对该模式的开发有了不一样的认识。首先结对的双方是互帮互助的,可以得到能力上的互补,当两个编程经验不多的同学结对,能够降低学习的成本,对知识和经验进行共享;出现“一神带一坑”的情况,经验丰富的同学能够为经验不足的同学指明方向,帮助其更快上手,另一方此时也能起到监督督促作用,两者结合能够增强代码和产品质量减少bug。

问题三:

在5.3.6中,作者介绍了一种名为MVP(Minimum Viable Product)——最小功能集的方法,它的具体做法是把产品最核心的功能用最小成本实现或描绘出来,然后快速征求用户意见。诚然,该开发方法符合敏捷思想,它适用于市场不确定的情况下,通过设计实验来快速检验产品是否可行。
但是,MVP这种方法是任何时候都可行的吗?如果乔布斯发布的是最小可用的 iPhone,我们是不是会得出结论说大家更喜欢键盘?如果 Tesla(电动车)制造的是最小可用汽车,还有没有人去开它?带着我的疑惑我上网查找了资料,有人解释到,这不是“最小可用”理念本身的问题,硬件不是免费的而且也不能方便快速更新,所以说只是有些市场不合适。但是我还是不太懂,就好比饿了么跟美团两家公司,如果它们只是把最核心的功能——"点外卖"(我个人理解是这样)做出来,在市场上他们会不会失去竞争的能力?所以,MVP的方法在什么情况下最适用呢?

当时对最小可用的概念并没有完全理解,在老师的引导下我对MVP最小功能集的概念有了更深刻的理解,它虽然说是用最快、最简明的方式建立一个可用的产品原型,但并非建立一个仅有单一功能的产品,它的功能大致可以划分为三类:必有的功能、锦上添花的功能、可有可无的功能,需要对这些功能进行优先级的排列,MVP的特点就是速度快迭代小,试错成本低。

对于之前两家外卖公司是否适用MVP方法,我目前的理解是,MVP适合的是最先开创市场的,查阅资料了解到,饿了么比美团外卖早了大概5年的时间,因此早期饿了么在市场试错的时候,可以采用MVP方法,但美团在已经线上外卖市场前景良好的情况下,可以不一定采用MVP方法。

问题四:

在12.2中,作者在介绍用户体验设计和步骤时讲到,用户体验设计的一个重要目的就是降低用户的认知阻力,即用户对软件界面的认知和实际结果的差异。
读完这段话我产生了一些思考,是不是说认知阻力极大的软件会降低用户的体验感?这里举一个关于自己的例子,曾经有段时间我的同学强烈给我推荐vim编辑器,据说各种便捷、强大、无所不能、不可思议、上天入地等等等等,当时我就兴致勃勃地去学习了各个命令并且在常用的IDE里面安装了插件强迫着自己去使用,但是对于刚入门的我来说这个认知过程总感觉磕磕绊绊,甚至在赶作业ddl的时候心中有了卸载的冲动。对此我想问的是,针对这种专业性较强的软件来讲,降低认知阻力还是用户体验设计的一个重要目的吗?还是说在一些情况下,总有一些软件是开发给那些需要功能强大,忽略认知阻力的受用团体的?

对此问题,经过老师的解答,已经能够得到充分的理解:是否降低认知阻力需要看的是用户定位 ,也就是看企业打算面向哪些用户提供服务。不同定位有不同的策略,如果面向专业用户,可以将软件做得更强大充实,认知阻力大一点。如果面向的是大众群体,则降低认知阻力是很有必要的。

问题五:

在17章人、绩效和职业道德中,这里讲到对于创造性思维的活动来说,创造力的激发和金钱成反比。对此我存在疑惑,为何两者会形成负相关的关系?在我上网查阅资料之后,了解到,参考的文献中通过一个实验说明了虽然基础良好的待遇的工作环境,是基本的保障,人们在良好的基础保障上在发挥创造力,就是现实的可操作的。但是人脑其实非常孱弱,因此要好好发挥其灵光闪耀,则必须提供和营造良好的分享氛围,强调和激励工作人员去关注创造力本身,而不去纠结奖金激励。我对此想法是赞同的,但是我认为作者观点中金钱与创造力不是简单的形成反比,它们一个是有一个临界条件的。

目前仍然保持着之前的观点,金钱与创造力并非简单地形成反比,在一定范围内,随着金钱奖金的增多能够对创造力产生一定的刺激,在这个范围之外,可能随着奖金的增多,人们更关注与奖金而非创造,因此才会导致形成反比。

做中学

  • 需求阶段

    该阶段我学习了如何进行需求分析,需求分析的特点是需求的完整性、一致性和可追溯性。一方面我们需要能够准确、全面地描述用户的需求(也就是在校大学生对于停车困难的问题),同时也要通过分析整理剔除需求的矛盾点。另一方面,我们需要不断地和用户进一步交流,在目标用户(目前是在校同学)沟通交流时需要能够自己的想法详细地表达出来。除此之外,我还认识到了,需求分析应该是建立在有技术保证的基础上的,本次软工实践非常有幸我们组内有能够提供人工智能算法技术支持的成员,这才使得我们需求的分析有了保证。

  • 设计阶段

    设计阶段不仅包括原型的设计,还包括了项目系统设计、数据库设计。在这个阶段我本人主要负责的是数据库的设计,数据库的设计需要对需求进行详细的分析,并且在系统设计的基础上,对每个类以及类之间的关系进行表结构的设计。本阶段我理解了要善于识别与正确处理多对多的关系。

  • 实现阶段

    在该阶段,学习了对全局异常的处理,学会了基于Sa-token权限验证的实现,理解了AOP的思想。同时我的团队协作开发能力也得到了一定的培养和锻炼,Github的使用,前后的接口的交互,都使我对团队合作有了更深刻的体会。

  • 测试阶段

    测试阶段主要做的是对完成的项目进行测试,结合了《软件工程》和《软件质量测试》这两门课程,我学习了许多测试的技术,如白盒测试、黑盒测试、集成测试、系统测试。测试阶段在之前往往是容易被我忽视的环节,在经历了本次实践,我认识到了测试的重要性,它不仅能够提高软件的质量,而且也能够提高软件开发的效率。

  • 发布阶段

    发布阶段我学习到了:让产品上线,能够获得更多数用户的使用,也能够更大可能性地发现产品的不足。

项目经历心得

个人项目

  • 代码风格规范很重要,能够提高代码的可读性而且方便bug的修改
  • 单元测试很重要,它使我们的工作完成得更轻松,而且会令我们的设计变得更好,甚至大大减少花在调试上面的时间。
  • 认识到了即使一项小的任务,想要把它做得完美也是很难的一件事,它不仅需要逻辑思路,还需要综合考虑多个方面的指标,如性能、耦合性、实现可行性等等 。

结对编程

  • 第一次结对编程,所做的是原型的设计,结对给我带来了最大感受就是效率的提高,对于一个有较强拖延症的我来说,结对使得我更加专注于这个任务中,换成是原来的个人作业,我并不会积极地在作业一发布下来就立刻去思考和进行分析,总是会缓上几天,结对的模式给予了我一种向上的约束,每天都应该保质保量地完成今天自己所应该完成的工作。
  • 在第二个结对编程过程中, 使我对springboot有了进一步的学习,也对MVC模式有了更深刻的理解。在这次项目中,我使用了之前未使用过的MyBatis框架,相比于之前的项目中直接使用的JDBC,代码量减少了不少,并且它提供了数据映射功能,支持对象与数据库字段的关系映射,方便了不少。 除此之外,还有对于特殊情况的判断和处理,如null时应该进行的处理,这些都是我们在专注的同时也可能忽略的东西,希望自己以后编程能够更加严谨,并且要养成每个功能模块完成后进行单元测试的习惯。

团队项目

  • 在alpha阶段
    • 在权限验证模块中学习使用了SaToken框架,这款轻量级的Java权限认证框架能够解决一系列权限相关的问题.本次的开发中体验到了它的简单、强大、易用、高拓展的优势。
    • API文档的阅读能力以及需要对其返回的数据进行解析。在调用的同时也遇到了不少阻扰,例如获取用户画像这个接口中,其要求的参数比较严格,日期的格式以及范围都需要进行一定的处理,否则总能遇到61501错误码。
  • 在beta阶段,我主要负责的是权限管理模块的代码编写,针对不的角色和权限对请求进行拦截,本次代码的编写让我对AOP的思想有了更深刻的认识,感受到了面向切面编程的好处。
  • 团队项目开发使我学会了在团队协作过程中的沟通交流,与队友进行配合。

第二部分:个人技术总结

个人技术博客

概述:轻量级的Java权限验证框架,主要解决: 登录认证、权限认证、Session会话、单点登录、OAuth2.0 等一系列权限相关问题

------软工课程完结撒花------

标签:MVP,结对,代码,编程,用户,测试,哈哈哈
来源: https://www.cnblogs.com/ldy316/p/14943471.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有