软件工程-个人作业-提问回顾与个人总结
对曾经的问题进行解答
Q1：单元测试真的能产生可重复、一致的结果吗
单元测试应该产生可重复、一致的结果如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。
在第2章中，有如上的结论，但是以我在OO第2单元时的测试来说，我不认为测试结果可重复，在多线程中，往往出现各种多线程的小问题，而这些小问题都是在程序运行了非常长的时间后，在某一种非常苛刻的情况下触发的bug，而重复运行这一段代码，极有可能不会再次触发这个bug，结果也自然不一致了，我想在现在的各种软件项目中，多线程的项目应该占了绝大多数，这在测试中难免出现一些概率极低的bug且无法复现。
A：在实际的测试中，我们的测试也确实产生了可重复、一致的结果。后面在我们的缺陷记录中都是可以复现的，我们也对每一个缺陷进行了修复。
Q2：单元测试应该谁来写？
单元测试必须由最熟悉代码的人（程序的作者）来写。第2章中有如上的说明，但是我认为最适合写单元测试的人应该是最熟悉该模块需求的人，或者说由提出该需求的人来测试，这是因为程序的作者可能只是按需求完成了代码，那么在测试时，也会按自己的代码的理解来完成测试，而如果他在写代码时已经误解了该需求，那么无论如何去测试，都是测不出问题的，因为在他眼中这就是正确的，而在真正的需求上，可能该功能是有问题的，因此我认为应该由最熟悉需求的人来写测试。
A：在我们的团队中有一个专门负责测试的同学，我认为由于在经过团队会议后，所有人对需求的理解应该都是相同的，不存在我之前所想的两个人对功能需求理解不同的情况，因此我认为这个由测试的同学来写也是比较合理，当然，在代码移交给测试的同学前，这个功能已经被写代码的同学测试了很多次了。
Q3：在完成时间上使用六西格玛方法是否正确？
但是从标准方差来看，Al的方差是5.3，而Bob是1。第3章中有一个比较交付时间的分析，在实际完成时间与估计时间上进行六西格玛来评价，我个人认为不是很妥。我们看看六西格玛的定义：(百度百科)
六西格玛（Six Sigma，6 Sigma）是一种管理策略，它是由当时在摩托罗拉任职的工程师比尔·史密斯（Bill Smith）于1986年提出的。这种策略主要强调制定极高的目标、收集数据以及分析结果，通过这些来减少产品和服务的缺陷。六西格玛背后的原理就是如果你检测到你的项目中有多少缺陷，你就可以找出如何系统地减少缺陷，使你的项目尽量完美的方法。
扫描二维码关注公众号，回复： 15076860 查看本文章
我们可以看到，这个方法实际上是对项目的缺陷作评价的，6个西格玛=3.4失误/百万机会，也就是说对项目的失误率来作评价，而一个程序员过早完成任务，也能算失误吗，我个人认为用平均时间和超出时间来作评价更恰当。
A：在实际上，我们团队并没有选择该方式进行评价，而是采用了完成任务的个数与质量来评价，因为我们组并没有出现过多的因为某一个人的工作未完成导致其他人无法进行工作的情况。
Q4：真的建议使用goto吗？
问：我们能不能用goto？答：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
第4章中，代码设计规范中，有如上描述。但是在我个人开发来讲，我从未使用过goto，正如评论所说：
goto语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。
goto语句的结果：在C/C++等高级编程语言中保留了goto语句，但被建议不用或少用。在一些更新的高级编程语言，如Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使用，使程序简洁易读；尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套。
goto往往会使得程序结构变得奇怪，结对的另一方应该也很少使用goto，这就加大了理解难度。我认为goto可以使用其他东西来代替，不是很习惯在代码中看到goto。
A：我们团队根本没人用这种东西，我认为最终这个就是不应该使用的，在我们合作中，看他人的代码都是我们熟悉的结构，不会出现goto来goto去的情况，这也算一个团队规范问题了。
Q5：PM是否真的能做到与大家平等？
Program Manager 和一些公司的 Project Manager 的区别:
Project Manager Program Manager 是团队的行政领导, 带领大家在项目中工作。 和大家平等工作, 推动团队完成软件的功能。 通常是团队和外界打交道的唯一代表 一个团队可以有很多PM 对项目的功能有最后的决定权 和其他团队成员一起形成决议 管事也管人 管事不管人 不一定做具体工作 一定做具体工作 阅读第9章项目经理篇时，有如上的表格，其中描述Program Manager为与大家平等工作、与其他成员一起形成决议、管事不管人。但是在我大学里实际的项目中，我认为这是很难做到的。在我第一次当项目组长时，我最初的想法也是大家应该是平等的，共同对项目提出建议，然后投票决定项目的走向等等，我应该起到一个类似于主持人的作用，项目会议应该是所有人一起参与进来，各抒己见，然而，实际上，大部分项目到了最后都是我开一个会，全程也是我在说明，这个地方应该如何去完成，这个地方应该需要注意什么细节，这个地方有前人的博客可以借鉴，其他人可能基本不发言。就算这样，已经把相关博客找好了，实现的功能输入输出描述好了，干起活来，还是得催，比如我曾经有一个项目，在寒假便安排好了任务，要求两周内完成后给我看一下效果，但是这个任务硬是拖到了暑假，最后我花了一个晚上把之前发给他的博客复现了一遍，实际上按那篇来做根本不会出现很奇怪的问题。我认为不管人的话，至少在大学是很难完成一个类似于PM的任务的。当然在工作上可能不一样，但是我还是对PM可以于大家平等表示怀疑，PM理应对每一个项目中的人进行管理，对没有跟上进度的也理应去push，如何才能实现真正的平等呢？
A：在本次软工合作中，我们进行了很多次的会议，我认为在一定意义上PM是与我们平等的。我们组有两个PM，其中一个主要负责前端，另外一个负责后端，但是平常因为我们采用的都是将任务在CODING平台上指派到具体的人，同时也明确了完成时间，因此不存在需要PM来push的情况，PM所做的是一个主持人的角色，在开会时我们也是逐个进行发言，对一个问题形成最终决议。
每个阶段的知识点
需求
典型用户。由于我们项目是与中传合作的，我们在得到他们的一些大致方向的需求后，通过代入典型用户的方式，思考他们给出的需求是否合理，对模糊的需求进行进一步的细化、整合，最终化为具体的需求。
设计
图形建模和分析方法。通过图形化的方式对事物进行建模，能够很好地体现出事物之间的联系，让软件开发人员能够在后续时刻准确把握设计的内容。我们采用的是即时设计，可以清楚地看到整个软件的运行逻辑，如如何跳转？需要有哪些功能？对后续开发时很有帮助。
实现
进度管理。我们采用了CODING上的团队协作进行进度管理，在这里面可以看到所有人的任务与缺陷，可以看到总进度，每一个人都可以向其他人指派任务或缺陷，也可以很轻松地找到某一个部分是由谁完成的。
测试
错误报告。当一个人发现一个bug后，如何向其他人报告这个bug？这就需要进行错误报告或者说是缺陷报告的规范了，我们采用CODING平台上的团队协作，对每一个缺陷进行详细的说明，如何触发？触发结果？预期修复后的结果？这样每一个人都知道如何去修这个bug了。
发布
砍掉功能。遇到无法完成了功能？直接砍掉。在我们实际上开发时，我们打算做一个AR人脸的功能，但是后续我们发现这个功能只有少数人的手机可以使用，而且完成的难度大，最后我们也没有实现这个功能，直接砍掉了。
维护
结构化维护。每出现新的需求时，应该从需求分析开始，对整个流程进行分析，判断该修改对其他地方可能造成的影响，在尽可能不导致其他bug的情况下加上该新需求，同时利用后端的动态部署，不影响用户的使用。
心得体会
软工终于结束了，在这个项目中，我主要负责的是多人同步的部分，另外还有AR的部分，现在的我对unity多人同步有了更深的理解，甚至觉得可以自己去b站录个视频讲述如何实现一个多人在线游戏了，这里面实际上有很多是目前博客或官方技术文档没有写的，如如何同步所有人的衣服，如何实现场景的邀请，如何实现团队的邀请，等等。在这里面我学习到了很多东西。在最后的一周里，我基本上都是3~4点左右睡觉，早上起来继续干活，可谓是基本所有时间都在研究开发软工了，不过也有所收获，我认为是值得的。
除了技术方面，我也更加了解了如何进行团队合作，如何建立一个更方便的沟通渠道，如何合理分配任务等，在此之前我非常讨厌团队合作，因为我之前的团队合作很少有这次一样的体验，因此我也会从这次的团队合作中获取经验，之后做出更好的团队合作。比如多利用一些团队协作工具，比只使用微信等等效率更高，也可以轻松跟踪到每个人的任务和进度。
最后，感谢我的结对搭档和团队队友，也感谢老师和助教的辛勤付出！