201771030118-司绍斌 实验一 软件工程准备—博客园首秀

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/
本次作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12369881.html
我的课程学习目标	大概阅读《现代软件工程—构建之法》，对本学科有一定的了解
这个作业在哪些方面帮助我实现学习目标	软件工程基础理论知识，学习博客发布的方法

任务要求

快速浏览邹欣老师博客或《现代软件工程—构建之法》，参照参考文章的提问模板，尝试拟定3个准备从课程学习中找到答案的问题，并以写博客形式记录下来，博客要求使用Markdown排版。

请参考这篇博客修改博客园博客默认编辑器。

请参照这篇博客，在博客撰写中练习 MarkDown，有余力的同学可以进一步优化博客的阅读体验。

博客作业格式符合以下要求，详情请参照这篇博文

问题一

• 我在《现代软件工程—构建之法》 一书中看到了这样一段话

  问：为什么非得做代码复审不可？难道开发人员没有能力写出合格的代码？既然你招我进了公司，就是相信我有这个能力，对不对？

  答：首先，在代码复审中发现的问题，绝大多数都可以由开发者独立发现。从这一意义上说，复审者是在替开发者干开发者本应干的事情。

  问：这么说如果开发者做到完美，复审者的时间和精力就是一种浪费了？

  答：不对，即使是完美，代码复审也还有“教育”和“传播知识”的作用。更重要的是，不管多么厉害的开发者都会或多或少地犯一些错误，有欠考虑的地方，如果有问题的代码已签入到产品代码中，再要把所有的问题找出来就更困难了。大家学习软件工程都知道，越是项目后期发现的问题，修复的代价越大。代码复审正是要在早期发现并修复这些问题。

  另外，在代码复审中的提问与回应能帮助团队成员互相了解，就像练武之人互相观摩点评一样。团队中有新成员加入时，代码复审能非常有效地帮助新成员了解团队的开发策略、编程风格及工作流程。

  问：新成员是否应该在完全掌握了这些方面之后再写代码？

  答：理论上是如此。但是如果我们要“完全掌握”，可能需要比较长的时间，另外，如果不开发实际的软件，这样的“完全掌握”有意义么？还是在实际中学习吧。这也是“做中学”（Learning by Doing）思想的体现。

• 对于上一段话，我有了这样一个问题

  为什么要进行代码复审，一个项目复审的频率应该怎样把控，复审过程中应该注意的问题有哪些

• 自我看法

  1. 代码复审的首要目的是改善和保证代码质量，预防 bug。此外还有益于制定团队代码规范，形成团队技术氛围，加深技术团队成员沟通，老带新互助成长。

  2. 目前我们所接触到的项目是比较小的项目，无论是代码量还是各种功能，所以现阶段我们更多的是要学会自我复审。当一个项目是两个或两个人以上来共同完成时，可以进行同伴复审，这样有助于发现更多问题，因为自身可能会过度自信而忽略掉一些问题。

  3. 需要注意的问题：同伴复审和团队复审时应该做到对事不对人，学会把握说话的度。并且学会适当的夸赞别人，给一个团队的人一些鼓励，有助于团队的团结。复审过程中尽可能不要提和复合无关的问题，比如讨论功能或者完成用户需求，这样会影响工作效率。

• 我的疑问

  1. 一个项目正常的复审频率应该保持在一个怎样的频率比较合适？

  2. 新成员技术没有老成员完善，这时代码审核能起到什么作用，对新成员的促进作用大不大？

问题二

• 我在《现代软件工程—构建之法》 一书中看到了这样一段话

用户安装软件之后，软件第一次启动，软件设计者要给用户什么样的第一印象？用户头一回来访问你的网站，你要给他们什么样的第一印象？

很多软件设计者把用户界面等同于给领导汇报的工作成绩单，所有的功能都争先恐后地出现在用户面前，唯恐用户没有注意到。但是用户往往会被繁乱的界面弄得晕了头，无所适从。现在电视的遥控器大多数就是这样设计的。

还有的软件把自己当成-一个毫无感情的工具，早期的一些字处理软件就是这样。用户启动软件后，看到屏幕上部出现了一行菜单，紧接着好几行小按钮，下面就是全白的屏幕。

有更好的设计么？

• 对于上一段话，我有了这样一个问题

  怎样注意用户体验，在考虑用户体验的时候需要注意的问题有哪些？

• 我在邹欣老师的书中找到了以下答案

  1. 要注意的两个问题：

     • 谁会是我们的目标用户?他们是什么样的人?他们的使用方式是什么样的?用户是从哪里进人到这个软件或网站?他们知道这个产品是做什么的吗?用户想达到什么目的?怎样让他们尽快找到相应的功能人口，完成任务?我们的软件可能比较难用(学习曲线较陡),怎样才能让用户尽快掌握基本功能?

     • 用户和软件的第一次使用， 很大程度上决定了用户对软件的评价。怎样让用户在第- -次使用的时候，少花时间(或者不花时间)在对用户没有价值的部分上？

  2. 学会从用户角度考虑问题，把自己想成用户，想象用户需要怎样的用户体验，怎样更加方便用户使用软件

• 自我看法

  1. 比如用一个网页做例子，现在的人们一天会浏览很多的网站，哪些网站是好网站，用户是怎样进行评价的。我想第一位的应该是一个网站的打开速度，当然排除自身网速的问题，如果光打开一个网页就需要5秒或者更久，那么我想用户体验的第一感觉就是很差。其次应该是整体的布局及色调的使用，用户第一眼看上去应该是舒服的，并且可以很快的通过导航栏等其他地方找到自己想要看到的内容。最后用户才会关注网站里面的具体内容是否解决了他的问题，是否是他所需要的内容。

  2. 针对不同用户，软件的用户体验也是不同的。如果我们在做一个大学的官网，那么它的基调就应该是严肃简洁的，不需要太多的色调和图片。但是如果我们在做一个幼儿园的官网，那么活泼可爱应该是这个网站的基调。大学官网更多的是老师和同学，而幼儿园的官网小朋友是主要人群，学会“因材施教”。

• 我的疑问

  1. 任何事物都有两面性，在保证用户体验的同时，怎样保证用户需求的完整性？

问题三

• 我在《现代软件工程—构建之法》 一书中看到了这样一段话

用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分。

• 对于上一段话，我有了这样一个问题

  效能测试时应该更注意时间还是空间方面的效能

• 自我看法

  1. 我们目前所接触的项目数据都比较小，数据量也不是很大。但是当数据很大，访问量也很大时，我们的效能会有什么改变，这是我们在项目完成过程中需要注意的问题。不能等到出问题了再去修改，这样用户体验会很差。我们常说的某个网站或者软件“崩了”，很大原因可能就是访问量过大，数据过多导致的。

  2. 我们应该在保证用户需求的前提下，在效能测试阶段应该加入更多的数据或者访问量，尽可能模拟最多的情况，这样才能保证在实际运行过程中少出问题。

• 我的疑问

  1. 有时候我们在开发阶段为了保证时间效率可能会牺牲空间效率，这样的做法在效能测试阶段会有什么样的影响？

  2. 在时间和空间方面应该怎样权衡，有没有一个绝对的比例？

总结

通过大概阅读邹欣老师的《现代软件工程—构建之法》，让我对软件工程这门学科有了一定的了解，明白了一个软件的完成并不是我们想的那么简单。我相信在老师的带领下，可以学好这门学科，并且把它用到平时的软件开发中。

作业参考文献列表

类型	详情
专著	[1]邹欣.现代软件工程：构建之法.人民邮电出版社,2017.