个人作业3-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	课程社区
这个作业的要求在哪里	作业要求
我在这个课程的目标是	学习软件开发的原则、方法，并对敏捷软件开发的具体技术有实践能力
这个作业在哪个具体方面帮助我实现目标	对整个学期的软件工程实践进行总结反思

回顾提问

传送门：之前的作业

Q1 什么是好的软件工程思想？

“总结来看，软件工程就是有原则的开发软件。重点就是这个原则，从本书来看，包括需求分析、设计、构建、测试、维护几个步骤，穿梭于其中的还有沟通交流这个重要的环节。这样看来，这个思想在于严格执行计划，记录所有过程并团高效队合作。”这是刚开学时的菜鸟软件工程师写下的文字。

说实话，我依旧不知道。

Q2 关于测试与构建的顺序

“在我的理解中，测试应该是开发人员完成代码 -> 单元测试 -> 签入 -> 测试人员进行测试。”

在团队项目中，我接触了新名词：DevOps、CI/CD。

所以反观这个提问其实没有意义，因为我和书上的认知差距就在这个持续集成（Continuous Integration，CI)和持续发布（Continuous Delivery，CD）的编程实践方法。当完成代码签入后，CI完成编译代码、打包编译输出，以及测试最终生成结果的流程，从而在开发人员高频签入的情况下提升合作效率和代码质量。所以在签入后确实存在这么一步单元测试。

Q3 冲刺的灵活性？

“可这样一分析下去，一次迭代和一个小瀑布的区别又在哪里呢？”

在我们的团队项目实践中，用户需求的变化几乎没有体现，更多的是团队开发时发现设计阶段认识的不周全。所以对于敏捷带来的灵活性，更多体现在细碎的ddl、每日例会与小组成员间更频繁的交流上。在alpha阶段评审的反馈中，助教说我们没有敏捷起来，仔细想来确实如此，我们的冲刺阶段更像一个瀑布，落完了=做完了，但不代表我们没有“敏捷”的意识。

Q4 软件团队如何才能准确而全面地找到需求？

“那么此时需求和技术（客户和团队）如何平衡？这或许需实践得真知了。”

从实践来讲，由于我们的项目（编译课程平台）与用户息息相关，所以我们首先从我们自己的角度出发，确定目标用户（老师、助教、学习编译课程的学生），结合针对个人直接询问与面向群体发布问卷的方式收集到的需求，对典型用户和应用场景进行抽象。简单来说，三步比较重要：确定用户范围，和用户交流，准确把握需求；多和用户交流是回答这个问题的答案。

Q5 关于一个用户使用它的概率是百万分之一的需求， 是否实现的问题

我依旧觉得书上这个例子举得不妥当。

“知识点”

需求：多和用户交流。

设计：按需、详细。

实现： 紧贴设计。

测试：重视鉴权和安全问题。

发布：环境隔离。

维护：稳定性。

总结

一些感谢的话语写在最前面。无论是和燕大神的杰队还是和人杰de0团队的项目合作经历都非常的愉快，非常感谢各位犇犇愿意带我/教我git使用/帮我解决bug/!@#$%^&*…。

当然，有一个陋习一定要改正，半夜三点的coding是错误的。

下面就是流水账了。

结对编程

我们使用结对的实践，完成了一个可以计算输入中最长单词连的程序，该程序拥有不那么良好的性能（我是蒟蒻）和非常优雅的UI（燕大神！）。在此期间，我第一次接触了结对编程这个概念，学习到了electron开发框架，认识了动态链接库的概念（并深刻的意识到了必须使用vs才能打包出正常的能用的动态链接库），接触了google test这一单元测试框架（的覆盖率统计原理，因为提升实在是太困难了），学会了心平气和地搜索和解决问题（因为全是环境问题）。

团队项目

在两个开发阶段，我见证了主楼的公共讨论空间从空无一人到人满为患；我也见证了我wx中各种orz从埋在表情包堆里到一个个被“移至最前”。

我很幸运，因为我属于“捡漏”，在最后才加入了这个超级棒的团队。所以我也一直有所顾虑，怕拖大家的后腿，但——大家都很可爱（我觉得很合适的形容词），实力都很强，沟通交流也非常顺利。反观从选题、用户调研、产品设计，到两次迭代以及中间的反馈总结等整个软工流程，7个人，10周，32篇博客，134个议题，427次合并，一个集课程公告、课程作业、小测、提交评测、竞速排序、课程资料、个人中心、用户管理、课程管理、班级管理、讨论区、即时通知、有AI对话的课程指导书等功能于一体的课程平台。我认为经过两个阶段的迭代，我们交付了一个解决用户痛点、功能上完善、界面上美观的“杰”作，我也很期待Compilify平台在下个学期编译课程中的使用。