软件工程提问回顾与个人总结
经过了一个学期软件工程课程的学习和实践，完成了一个结对项目和三个阶段的团队项目，我对软件工程有了初步的认识了解。在此过程中，有一些做的好的地方，也有值得改进的方面，因此在这里对此次软件工程课程做一下回顾和总结。
提问回顾
本学期开始时，完成了一次个人阅读作业。其中一个要求是阅读教材，列出不懂的问题。我一共提出了5个问题（在这篇博客的第1部分）。现在回顾这些问题，有些仍然不能完全回答，但也有了新的认识。
作业要求不仅要给出问题，还要提供上下文，说明问题的来源（来自哪一个章节），列出材料以支持提问，并且解释提问的原因。隐约记得当时觉得这个要求很繁琐。现在看来，这些是有必要的。对于读者来说，仅仅看见一个问题还不足以理解到为什么要提出这个问题，这个问题对于自己或者作者有什么价值。当提问者说明问题来源，给出事例支持并解释自己的看法后，读者才能对问题有更深入的理解。这里的读者不仅仅是提问者之外的人，还包括若干时间后的提问者自己，比如正在写这篇博文的我。在这里我要感谢这个作业题目的作者（邹欣老师），以及作业布置者，还有我自己（按照要求完成了作业）。
下面一一回顾之前提出的问题。这里把之前提出的问题复制过来，然后对问题做解释。如果你想看以前的解释，请查看这篇博客的第1部分。
-
如何在团队中建立相互信任的关系？
通过一学期的实践，我对这个问题有了更多的理解。
- 首先，团队成员是值得被信任的。在软工团队实践的过程中，我们有机会了解团队成员都做了什么任务。于是，便可以通过高质量地完成任务来向队友表明自己是值得被信任的。我认为评估质量可参考这些因素：是否在按时完成任务、任务完成的质量（例如bug多不多）。产生信任的人可能不会显式的进行这一个过程，但需要被信任的人应该主动检查自己完成任务的质量，以使得队友能够信任自己。
- 第二，信任是双向的。在之前的提问中，没有解释这句话的含义。通过实践，我认为要建立双向的信任，在发现队友值得信任后，还需要主动地表示自己对队友的信任。通过“充分授权给团队和成员”，团队成员能够自己决定完成什么任务以及完成任务的时间。在我们的团队实践中就做到了这一点。
- 第三，信任需要积累。在这学期开始时，我尝试着寻找在新组建的团队中是否存在一种快速建立信任的方法。经过一学期的实践，我认为可能不存在某种快速的方法。当团队成员都在认真完成任务时，自然而然就能建立起信任。有了信任的积累，就能达到“充分授权给团队和成员”。
-
在软件开发中，如何应用建模方法？
很遗憾，在实践中没有找到有关这个问题的线索，因为我们进行的软件开发没有用到建模方法。这个问题可能在以后的实践或者阅读中得到解决。
-
如何进行量化的绩效管理？
在之前的分析中，我主要关注到教材《构建之法》第17.6节介绍的方法的不足之处。这种不足之处体现在使用工作量和bug数量来衡量绩效忽略了内部的驱动因素。我们在团队实践中没有约定贡献分的计算方法，每个阶段的贡献分由PM根据工作量给出。其实使用书中提到的某些具有数量性质的量（例如代码行数、bug数）作为绩效衡量指标未尝不可。不过要清楚绩效管理的目的是为了激励成员更好地工作，因此对达到此目的有消极影响的方面，我们应该进行人为的控制，以减轻不好的影响。
-
为什么每日构建很重要？
尽管在团队实践中我们没有进行每日构建，但还是能非常清晰地体会到这一点。我们的项目是博客园的班级博客App，尽管没有进行每日构建，由于我们的项目比较小，所以每个团队成员都能访问到完整的debug版本。当每个团队成员都能看到我们的软件一天天变得更好时，无疑增加了士气，给团队成员以动力来更努力地工作。
-
如果错误的情况很多，怎么进行错误处理？
在之前的分析中，我怀有一种侥幸心理可以不必处理各种可能的错误。实践表明，忽略了对各种可能的情况进行分析可能带来致命的问题。在我们团队软件的alpha版本中，未考虑到用户还没有加入班级的情况，在此情况下，App会崩溃。那么，还没有加入班级的用户则不能进入软件来加入到某个班级，从而就无法使用我们的App。当某个App出现这种严重的问题时，我个人通常是寻找替代品或者不再使用该App。那么，假设大家都有这种想法，出现了这样的问题就可能失去很多用户。所以，需要对各种可能的错误进行分析和处理，即使这种分析显得十分繁琐。至于能否找到一种好的方法能够帮助分析各种可能的错误情况而无遗漏这个问题，暂时还不能解决。也许在以后的实践或阅读中能够获得更多的灵感。
团队项目中的知识点
- 需求阶段：在需求分析阶段，我们团队学会了使用竞争性需求分析框架，学习了NABCD模型撰写了需求分析的博客。
- 设计阶段：学习了图形建模的分析方法，例如实体关系图、数据流图。
- 实现阶段：学习了源代码管理的方法，使用了源代码管理的工具。
- 测试阶段：实践了不同的测试方法，例如集成测试、压力测试等。
- 发布阶段：软件按时发布的招数：渐进发布，如Alpha Release、Beta Release。
- 维护阶段：发布之后，使用ZBB方法消灭bug。
结合结对编程/团队项目的经历，谈谈自己的理解或心得
-
充分的交流
在开始的结对编程中，由于我和队友没有足够的交流，我们没有找到合适的时间进行结对编程。受于时间限制，我们选择了划分任务独自完成的方式。从结果上看，作业完成的效果不错。从过程上看，我们没有采用结对编程的方式，所以也没能对结对编程有一个完整的体验。如果以后还有这样的机会，我会更多的与队友交流协商，尽可能的到达任务的要求。
-
详细的文档与注释：
我们选择的团队项目是继承以往的项目继续开发。原来的项目有一个环境配置说明文档，我们能够根据文档的说明进行操作，使得整个项目能够运行起来。即便如此，我们在配置环境时仍遇到了不少麻烦。一个是文档不够详细，没有指明各个依赖包的版本，于是我们安装的都是最新的版本，导致了一些问题。第二是文档有一些与实际操作不一致的地方，配置环境时不知道怎么做才正确，走了一些弯路。
除了环境配置说明文档，原项目还有课程所要求的功能规格说明书与技术规格说明书。功能规格说明书还停留在一开始的设计阶段，没有随着软件的更新而修改，使得我们看到的功能规格说明书与实际软件不相符合，这样的说明书对于我们了解软件也就没有太大的帮助了。同样，由于技术说明书也是在设计阶段完成的，后来也没有更新。这样的文档对于接手项目的团队来说有用的信息就不够了，于是我们只好从通过阅读代码来增加对项目的了解。在阅读代码时，注释较少，有些地方很难理解原来代码编写者的意图，这使得接手项目的团队较为苦恼。好在整个项目的逻辑不算复杂，我们团队经过一段时间后就大致熟悉了原有的项目。
上面两段描述可以算得上一段经历，然而，即使体验了没有详细的文档与注释带来的问题，我们却没有以此为戒。对于上面提到的三个文档，没有做太多修改，仍然使用了原有项目的说明书。在我们进行的开发中，有了一些新的设计（例如界面设计、功能设计），但没有将这些设计用文字固定下来，只能从代码和实际运行的软件中去寻找和猜测。对于注释，稍稍有一些进步，我们约定尽量对自己认为难以理解的代码写上注释，从最终项目的注释比例统计数据（这篇博客的末尾部分）上看有了一定的提升。
之所以没有完善补充文档，我认为有以下原因。
- 缺少时间和精力：在第一个阶段我们既需要熟悉原有项目又要在其基础上扩展新的功能，使得我们在完成功能之外没有时间去写文档。
- 不知道如何写文档：在开始阶段，我们对项目还不熟悉，不知道应该怎么写文档。
- 没有写文档的激励：仅看课程考核的要求，完成功能是老师和用户能够体会到的最明显的工作，然而更新文档却不是。即使我们随着项目的推进不断更新文档，老师不一定能够注意到这一点。所以即使更新了文档，最后也不一定能够获得相应的分数。出于花费更少的时间精力获得更大的收益的想法，就可能选择对文档置之不理。
文档的重要性不言而喻，如果能够回到过去，除了功能实现外，我们一定会更加关注文档的完善问题。尽管前面描述了原来项目和我们完成的项目的一些缺点，但也不能完全否定。原来的项目是从零开始，为新团队的继承打下了坚实的基础，我们团队成员也比较积极，不仅增加了更多实用的功能，还美化了界面，改善了用户体验。
