提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程（罗杰 任建）
这个作业的要求在哪里	提问回顾与个人总结作业要求
这个作业在哪个具体方面帮助我实现目标	回顾，反思，总结，提高
课程开始时写的博客	个人博客作业

一.回顾自己的问题

1.单元测试是否必须要快？

• 第二章开始时提到了一个好的单元测试的标准。作者认为，单元测试应该准确、快速地保证程序基本模块的正确性，我对这一点表示肯定。但接下来的一个描述让我有些疑惑，具体如下

  单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）

  快，才能保持效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。

  我认为不是任何软件的单元测试都符合“快，才能保持效率”的。比如我们在大二学习OO时写的多线程电梯，由于有各种时间上的规定，人坐电梯不可能太快；涉及机器学习的测试，面对极其庞大的数据量，测试速度也不可能有多快。但是，不能因此而说这样的单元测试就没有效率，不是一个好的测试。亦或许是作者此处说的“单元测试”与平时理解的“测试”有所差异？

• 这个问题确实属于自己的理解错误，把单元测试和其它类型的测试搞混了。我在这学期的项目中主要负责API的编写和单元测试部分，通过编写单元测试代码和当时与助教的讨论，认识到单元测试实际上是对每一个小部分（某个具体的函数、方法）的测试，通常来说这些部分的运行速度都是挺快的。比如之前说的坐电梯的问题，它有某个方法是“人上电梯”，那么我们需要测试的可能就是这个方法运行后，排队人数是否减1，在电梯上的人数是否加1，现在承重是否等于之前承重加上此人体重。对于“人坐电梯”，测试范围就比较大，应该已经不算是单元测试了。

2.goto是否符合代码设计规范？

• 在4.3.2节中，作者提出

  函数最好有单一的出口，为了达到这一目的，可以使用goto。只要助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

  而著名的计算机科学家Dijkstra在他的论文《Go To Statement Considered Harmful》（Go to有害论）中的原文如下

  More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages.

  他提出，goto语句有着“灾难性”的影响，应当从“高级”编程语言中取消。现代则普遍认为goto语句会降低代码的可读性，破坏程序的“结构化”，带来编程的混乱，并且容易出错。我认为这句话一定有它存在的作用，我们应该尽量避免使用goto，取而代之用if-else语句实现，增强代码的可读性。

• 如果只能回答“是”或“否”，那这个问题确实很难回答，可以当辩论赛论题了。目前好像没有什么设计规范明确地禁止使用 goto，但是计算机科学家又说它有害······所以，我还是认为应该尽量避免使用 goto。实际上，我们写代码的过程中很少用到 goto，大部分的逻辑都可以通过 if-else 或是其它语句来实现，倒也不必过分纠结这个问题，难为自己也难为别人。

3.关于4.5节结对编程

• 在这一节，作者认为

  在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。

  在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一堆程序员中各方面水平较高的那一位。

  同时指出了三点结对编程的好处。我认为这只是对结对编程的一种积极的构想，并不全面。假设这对程序员一开始可以平等互补地工作，但某一天两人突然产生了一种不可见的矛盾，比如程序员A认为他在开发过程中贡献比B大，变得骄傲自大，B又不服A······这样的结对编程就会适得其反，没有真正实现结对的目的，这样的情况应该不在少数。

• 通过这学期的结对项目，我体会到了结对编程的好处，能和队友相互合作，长短互补，没有产生过太大的矛盾，有的问题也都通过协商解决了。我相信结对编程消极的一面还是存在的，但目前看来大家都很和睦友好。

4.如何发现用户背后的动机？

• 在10.1节中，作者以网络漫画为例，并指出

  光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定。

  言外之意就是我们要推测出用户的更深层次的需求。但现实是，许多用户就如漫画里面一样，有时候就希望开发者可以照猫画虎，对于自己需求的形容也往往不够专业，不能完全让开发者理解。就像前段时间网上流传的一个事例，某酷似甲方的人员打电话说道：“你先这样，然后再这样，接着再这样，最后再这样，很简单吧？”也就是说，一些用户很难沟通，我们很难找到他们背后的动机，就连他本身想干什么都搞不清。这种情况，我们是否应该直接按照用户的表面语言或行动进行开发，或是有什么发现其背后动机的更好办法？

• 这个问题有一定难度，但就这次的开发项目而言，我们并没有主动去发现用户背后的动机，因为用户的动机比较明确，不存在“背后的”动机，或者比较少，当然也不排除是我们能力不足没有发现。比如社联的同学希望区分社团管理者，社联，以及普通团员，增加活动审核评价功能等，我们就针对不同角色显示不同界面展示不同功能，并增添一些新功能，没有加入什么新元素，这样就已经满足了他们的基本需求。我认为如果想要发现用户背后的动机，首先自己要是一个阅历丰富见多识广的开发者，见的用户多了才能推测他们的普遍需求，推测才有了根据，否则像我这样没经验的人，如果一味地猜测，可能就会把自己绕进去，把一个简单的问题想的异常复杂，事倍功半。总而言之，要发现用户背后的动机，开发者要多积累经验，经验不足还是优先选择表面动机比较好。

5.技术创新是否是关键？

• 在16.1.6节中，作者认为“技术的创新是关键”是一种迷思，并举了商业模式的创新，用户体验的创新，生态系统的创新的例子。我认为这样的推理并不是很完备，只能说明除过技术创新，还有很多其他创新的方式，可以印证“创新不只存在于技术”。说到创新的关键，我依然认为是技术。
• 这个问题有些局限了，也有些不灵活。创新的关键因素可以有很多，技术，模式，体验都是一部分，他们都很重要，不必过分纠结哪个最重要，意义不大。

二.在实践中学习到的知识

1.需求

主要学习到了课程要求的NABCD需求分析法，认识到了需求分析的重要性。分析用户需求就像是制定目标，当我们知道用户想干什么的时候，也就知道了自己要干什么，不会像无头苍蝇一样。我们主要与社联的人员进行交流，了解他们的需求，并且通过他们的反馈将双方所描述的需求一致化（用户和开发人员语言表达不同，但意思相同），然后才开始着手工作。

2.设计

由于我们的项目是接手上一届的，在看了他们关于代码规范的设计文档之后，我充分体会到了任务开始前规格、功能设计的重要性与必要性。按照设计文档的规范写代码，可以有条理而不乱，别人也可以看明白我写的是什么，比如规范的变量命名，json格式的定义，适当的注释，规范的API请求路径等。此前，由于一直都是自己写代码自己用，规格也比较小，很少与人合作，所以对于设计文档比较忽视，也没有怎么写过。但这一次的项目庞大，不知道传了多少届，下一届同学是否还要继续使用，如果没有一个规范的设计文档，不仅前后端交流困难，也不利于项目的维护或延续。

3.实现

对于个人，通过这次的项目，学会了前后端分离这种现在比较新颖的方法，由于后端使用了 Rails 的框架，对 Ruby 和 Ruby on rails 也有了更深入的了解；对于团队合作，我们几乎每天都要开一次会，这也是解决问题效率最高的时候，深刻感受到了 Scrum meeting 的重要，只有不断 push 才能解决问题。同时，学会了更多 github 的高级功能，不再局限于 add commit push 这种基础个人操作。

4.测试

在 alpha 阶段我主要负责新增 API 的编写，beta 阶段主要负责测试。通过编写 Rails 单元测试文件，进一步掌握了 Rails 的单元测试方法，也对单元测试有了新的理解。除单元测试，我们还进行了一些场景测试，正确性测试，从中发现了一些小 bug，测试这一步不可或缺。

5.发布

我们的项目主要是发布网页端和微信小程序端，由于没有负责服务器部署之类的工作，所以对于发布的过程只是有了一个大致了解。如使用 Nginx 进行反向代理，申请域名、证书，微信小程序开发者平台注册，小程序发布审核等流程。

6.维护阶段

根据用户反馈修理 bug，熟悉了 mysql 的使用。

三.理解与心得

个人项目和结对项目都是比较小型的项目，难度也不是很大，但是由于个人和队友能力有些不足，所以完成的不太好，在代码能力方面确实还需要提高。由于疫情原因，一些问题讨论起来也不是很方便，主要的体验在团队项目上。

印象比较深刻的有两点，一是刚开始接手上一届的项目时，面对几十个 Ruby 文件和代码手足无措，除了自己在网上疯狂搜索，也多亏了助教给发的一份 Rails 教程，学习实战 Ruby 和 Ruby on rails 的过程相当漫长，但是收获很大，从一开始的“天书”到最后根据自己的理解并新添 API，是一个巨大的飞跃。另一个就是几乎每天一次的 Scrum meeting，要汇报自己的工作进度，和大家一起讨论解决问题，不断地被 push，只有 push 才能产生效率。在这个过程中，认识了新同学，也培养了自己的人际交往能力，积累了实际开发经验。

本学期的软工是一门可以和计网媲美的重课，不仅要完成相应的项目开发，还要不停地写博客。说实话一开始博客写的很烦，但是后来觉得写博客就像写日记一样，记录一下自己的学习生活也未尝不可。而且在以后的项目开发中，一定还有类似的过程，比如写一篇汇报总结，不可能只是让你闷声写代码，所以提前培养自己写文档的能力也不错，这也是罗杰老师软工课的一大特色了。

相信在软工课上的体验和学习到的知识可以在日后受用。