2021软工-提问回顾与个人总结
2021软工-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于那个课程 | 2021北航软件工程 |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 掌握软件工程的相关技术 |
| 这个作业在哪个具体方面帮我实现目标 | 对软工经历进行回顾与总结 |
一、提问回顾
学期初我在阅读完《构建之法》后，提出了几个问题，对于其中的一些问题，我在当时给出了我的想法，但对于其他一些问题，留下了一些疑惑。现在经过一个学期的学习后，希望能对当初的不解进行解答。
1. 大陆高校中的计算机专业与软件专业是否并不像书中说的那样雷同？
问题出自1.2.2 软件工程与计算机科学的关系：
······大部分老师做的都是偏工程方面的研究（所谓“横向项目”），大部分学生毕业后也投身于解决具体的工程问题，这跟软件学院、软件工程系（院）的研究和培养方案非常雷同。······
对于这个问题，我当初就给出了我的想法，即我认为“两个专业雷同”“的这个现象在我们学校表现得并不明显，在体验一学期的软件工程课程后，我还是保持我当初的看法。
在我的所有经历中，《软件工程》课程是唯一一个能与软件专业扯上关系的，虽然不能将这门课与软件专业划上等号，但这也算是我亲身了解软件专业的一个窗口。从这个经历来看，软工课程与其他课程给我带来的感受就有很大的差异，最明显的一个区别就是软工课程并不会实际教授你什么技术，而主要在讲各种方法论。换句话说，虽然其他专业课程也多少与工程有点关系，但软工课程是纯粹地只与工程有关。而我认为这种课程上的差异其实就是计算机专业与软件专业差异的一种缩影。
当然，可以认为这是一种诡辩，但确实是我的真实想法。
2. 单元测试能由别人来写吗？
问题出自2.1.2 好的单元测试标准:
单元测试必须由最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人选了。
当初提出这个问题的时候并没有实际的多人编程经历，所以仅凭自己的臆测提出了这个疑问，现在我认为我能为自己作出一定的解答。
首先，我的答案是最好不要由他人来编写单元测试，理由有二：
- 我在结对编程与团队项目中都有过替他人的代码编写单元测试的经历，但感觉并不会对软件的整体质量有什么正面提升。因为如果你要为他人编写单元测试，你就需要知道这个单元的功能，但由于这个功能是从你对源码的阅读中理解来的，可能与编写者的想法有一些出入，这就导致了单元测试可能并不会有很好的覆盖效果，并且不断阅读别人的代码本身也不是一个太好的体验。
- 单元测试主要是对一个单元的功能进行检查，也就是说，编写者一开始就要对单元的功能有所了解，然后在编写完后通过单元测试来检查在编写过程中是否有逻辑错误。这也就意味着并不会出现我在当初提问题的时候所提到的”自己跳不出自己的逻辑错误“这种情况。
3. 有关“本函数时间“以及”所有时间“的定义的疑问。
该定义位于2.3 效能分析工具，表2-1中：
调用者（caller）：函数Foo() 中调用了Bar()， Foo() 就是调用者。
被调用函数（callee）：减伤，Bar() 就是被调用函数。
本函数时间（Exclusive Time）：所有在本函数花费的时间，不包括被调用者使用的时间。
所有时间（Inclusive Time）：包含本函数和所有调用者使用的时间。
由于这个问题只是针对《构建之法》书中的几个名词定义所产生的疑问，在实际体验中并没有遇到与这个问题有关的事，自然也就没法为自己做出新的解答。并且我认为这个问题也并不是什么亟待解决的问题，因为即使实际遇到类似的名词解释疑惑也可以通过上下文来比较高效地得到答案。
4. 给予反馈时，对方接受的难易度是否更基于给予时的态度而不是层次？
问题出自4.6.2 如何正确地给予反馈：
反馈的分为三个层次：
- 最外层：行为和后果
- 中间层：习惯和动机
- 最内层：本质和固有属性
我们的反馈还是要着重于[行为和后果]这一层面，不要贸然深度到[习惯和动机]、[本质]。除非情况非常严峻，需要触及别人内心深处，让别人悬崖勒马。
经过结对编程以及团队项目过程中对他人提意见以及接受他人意见的经历后，我还是持有当初的观点，即”对方对意见的接受程度更多是基于你提意见的态度“。
当然，我的这种想法可能只适用于我自己身上或者只适用于一种团队内各个队员相互平等的情况。这种平等并不是说团队内权力上的平等（如果有 PM 在权力就不应该平等），而是一种心理上的平等，在这种情况下，大家心里都会有一种谦逊的心态，也会很积极地对待他人的意见。这时候只要保持一种友好的态度，那么即使提出较为深层次的意见，一般也能被接受，同时也不会太破坏团队氛围，因为大家都想把事情做好。
5. 在敏捷流程中，如何保证不同任务间的协调性？
问题出自6.3 敏捷的团队：
以前规划说明书由PM来写······现在每个人都全面负责，自己搞定规划说明书，······
对于这个问题，我在团队项目过程中有切身体会。在 alpha 阶段就因为前后端之间缺少沟通与协调而导致结果令人沮丧，所以我们团队在 beta 阶段就吸取了一定经验并做出了一些改进。我们应对任务之间协调性的方法是分层次地进行共同讨论：
- 对于软件的整体结构以及前后端关联的地方，由整个团队共同进行讨论形成一个总体规划，有想法的人发表自己的观点然后再由 PM 进行定夺。
- 对于前后端内部的详细设计，有前后端人员各自独立组织讨论，在形成一个详细的开发规划的基础上再进入开发阶段。
更明确的说，要解决任务之间的协调性，就是要尽早做好整体任务规划。
6. 为何课程要求结对项目不能出自同一团队？
这个问题是当我看完4.5 结对编程后产生的。
在亲身经历过结对项目之后，我认为算是能给自己一个合理的解答。首先从课程设置的转会等内容来看，课程组是希望对软件工程的场景进行具体的模拟，所以对于要求结对人员不能出自同一团队我认为可能也是出于相似的考虑。一种比较能令我自己信服的原因就是希望模拟实际中快速融入一个比较陌生的环境这一情景。
7. 有关快速阅读教材与”做中学“宗旨的疑问。
这个疑问来自于书中的以下内容：
- 经过2007年以来的探索，我总结了在16周内让同学通过”做中学“，掌握实用软件工程技术的教学方案。
- 本书内容具有以下特点：······面向实战，强调做中学。
当初提出这个问题的时候，主要是针对一个单独阶段的具体任务，是我当时对为何要进行这个任务的不解的体现。而从现在临近课程尾声这个节骨眼来看，为什么要有这个任务的理由也很简单，我觉得就是希望同学能先在一个大致范围内容软件工程的方法论有所了解，这样有利于顺利地开展之后的工作。同时这也不能算是违背”做中学“的宗旨，因为：首先，如果没有一个基本的概念，那么从何开始”做“就无从谈起；其次，并不是要求我们通过浏览一遍书就完全学会书中内容，而是只需要在一个较大尺度上对教材内容有所了解即可。
二、新的问题
进入到团队开发阶段后，发现了一个与之前设想有很大差别的地方，也就是是否需要专门设置测试人员。在一开始阅读《构建之法》以及之后进行案例分析作业的时候，我都以为即使是一个6人团队，也需要专门分配人员进行测试工作，但到了实际进行团队项目阶段时，我才发现，在有限的人力下，基本上很难专门分出一个人进行测试工作。所以我的问题就是：在一个小规模团队（比如6人）中，是否真的有必要专门设置测试人员，以及如果真的有必要，那么在人力受限的情况下怎么达到这一目标。
三、知识点
1. 需求
提到需求分析，自然会想到 NABCD 模型，其中很关键的一点是 N 也就是需求，因为一个软件的后续功能设计需要以需求为基础进行展开。而要做好需求部分，就需要充分考虑不同人群以及不同场景。
2. 设计
设计的过程是一个自顶向下的过程，也就是一个从抽象到具体的过程。这样做的好处是可以控制参与设计的人数，使得不至于每个人都需要知道所有细节，徒增复杂度。举个例子，在进行软件整体设计的时候，需要所有人员参与，这时候只要讨论设计出软件的整体框架就行；在进行前/后端详细设计的时候，再分别由前后端人员各自组织讨论相应的详细设计。
3. 实现
在实现的过程中，应先明确好每个模块的功能再开始编码，而不是在编码的过程中细化模块功能，前者的好处在于减少对代码的频繁更改。此外，考虑奥卡姆剃刀原理，对于同样的功能，尽量使用简单的实现方法。
4. 测试
对整个项目来说要综合使用多种测试方法。对于个人，在实现过程中需要同步进行单元测试以保证代码逻辑上的正确性；对于项目的发布，还要进行压力测试以及场景测试等。
5. 发布
发布前需要注意关闭开发阶段设置的 debug 接口，并注意一些需要满足的要求，比如：如果是一个网页项目，需要申请并注册域名；如果要使用 https 就需要先申请证书。发布后需要注重产品的宣传。
6. 维护
要在软件后台保留详细的日志信息，用以分析与解决问题。同时要设置方便的用户反馈渠道来收集用户提供信息，并以此作为改善软件质量的一个依据。
四、个人总结
1. 个人项目
在看到个人项目这个词的时候，我第一反应是：软工课什么时候还做过个人项目了？然后仔细一下，觉得应该指的是课程初的那三篇博客。想来当初在写那三篇博客的时候可以说是蛮不情愿、怨声连连，心想“这不是我以为的软件工程”。到现在我再回顾这些博客的时候，已经没有了当初的不情愿，反倒是觉得他们给了我一个走进自己、走进软工的机会。如果没有第一篇博客，我应该一直都不会去想我为什么会读我现在在读的这个专业。如果没有第二篇或是第三篇博客，我应该会被困在“自己的软工幻想”中很长一段时间。纵使当时有不理解，现在再看也算的上一个好的开头了。
2. 结对编程
结对编程应该是三个阶段中带给我最好的实时体验的一个阶段了，因为感觉整个过程和当初上 OO 课的时候有点类似，所以在感到熟悉的同时也做得游刃有余。同时，由于只是两个人的小项目，所以可以感觉到自己对项目的质量还能进行整体的把握，这一点我在进行团队项目的时候是体会不到的。除了完成了一个小项目之外，这个阶段给我最大的收获就是了解 CD/CI 等一些工具的使用并积累一些合作开发的经验，为之后的团队项目做铺垫。
3. 团队项目
在团队项目的alpha 阶段事后分析以及beta 阶段总结中，都有我对阶段进行的分析总结，所以这里就不总结详细的过程了。从结果来看，团队项目应当是三个阶段中结果最差的一个，但我并不觉得我在这个阶段付出的精力比前几个阶段来的少，可惜软件的效果总是多多少少没有达到期望的效果，而这种无力的感觉有时就会令人感到沮丧。当然，即使有一些负面的情感也不是针对队友的，因为在我看来我们团队内的氛围还是比较融洽的。而造成效果不太理想的主要原因我认为在于三方面：首先开发一个成熟的聊天机器人在技术上就有比较大的难度，而我们团队缺少相关技术的专业人员；其次是团队的管理还不够规范，也就是 PM 制度体现出的效果并不明显；最后是人力的问题，因为我们团队只有五个人，而且大部分人要开发这个项目都需要从零开始，所以在对软件进行设计、实现的时候就会受到开发能力的限制。
最后的最后，我还是要对我的组员以及他们所付出的精力，同时也对课程组在这一学期中所付出的努力表示感谢。
