2021秋季软件工程实践总结

这个作业属于哪个课程	构建之法-2021秋-福州大学软件工程
这个作业要求在哪里	2021秋季软件工程实践总结
个人学号	041903101
团队名称	G 猫的魔法
参考文献	Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

个人总结

• 对比开篇博客对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了期待和目标，哪些方面还存在不足，为什么？

本次我担任小组的架构师，同时也是第一次担任该职位。在学习和应用软工相关知识，尤其是设计和绘制各类 UML 图上基本达到了目标。然而，我也深深地意识到自己在工程开发上经验的严重不足，这是当前限制我架构能力的最重要因素。这又体现在两点，一是对课上所学的设计模式御用不熟练，甚至出现了运用错误的情况；二是对时下流行的开发工具、开发框架等不了解，例如 flask，django，云函数，idl 等。之后应多了解时下企业常使用的各类工具。

课程实践总结和带来的提升

• 在这门软件工程实践中，完成了多少行的代码：约 1.5k 行
• 软工实践的各次作业分别花了多少时间？

作业	所用时间(分钟)
个人作业一	40
第一次个人编程作业	1632
第一次结对编程作业	1400
第二次结对编程作业	1720
团队展示+选题报告	240
需求分析与原型设计	310
团队项目之现场编程	130
现场编程需求更改	240
alpha 冲刺	2700
alpha 冲刺完善	300

• 哪一次作业印象最深刻？为什么？
  最深刻的无疑是 alpha 冲刺作业。因为这是历时最长、难度最高的一次作业。在这次作业中第一次真正参与实现了一个包含完整前后端、数据库的工程，有许多收获。
• 累计花了多少个小时在软工实践上？平均每周花多少个小时？
  累计用时145.2小时，平均每周用时16.13小时。
• 学习和使用的新软件：墨刀
• 学习和使用的新工具：GitHub，Flask，微信开发者工具
• 学习和掌握的新语言、新平台：JavaScript，GitHub，优快云
• 学习和掌握的新方法：UML 设计和绘制
• 其他方面的提升：对软件开发有了更全面的认识

团队总结

• 结对编程时总是写写停停，不时停下来思考接下来要做社么。
  这是需求分析和开发计划没有做到位的原因，在开发前就应该先决定好哪些功能需要实现，哪些功能不实现。虽然由于该次作业所开发的软件体量较小，所以后期添加功能时也没有太困难，但要提高效率还是应该做好前期工作。
• 团队开发 alpha 冲刺阶段类图存在较多问题。
  对相关接口了解不全面，当软件需要使用第三方提供的接口时，应当仔细阅读其文档，并确认好哪些接口需要使用，以及如何使用，需要提供何种参数，以及使用是否存在限制等。
• 团队开发时后端所写函数与类图存在不匹配现象。
  要及时跟进开发，多与后端交流，明确好每个函数的含义、参数、返回值、函数名等，避免错误的累积。

提出建议

学弟学妹：
对于软工实践，我的体会是一定要提高自己的积极性。由于平时学业繁重而软工时间又有许多必须花费较多时间和经历才能完成的任务，许多人刚开始可能还饶有热情，而到中后期就开始不太顶得住了。但是其实，在一个团队中，一个人的积极性往往会影响整个团队的积极性，所以提高和保持自己的积极性本身就是一件对团队有贡献的事。当然，空有一身热血也不够，还需要合理的制定好阶段性目标，尤其是小目标，这样能更好地利用好空闲时间学习软工实践所需要的各类知识。

团队分析

《构建之法》中提到了团队合作的四个阶段：萌芽阶段、磨合阶段、规范阶段、创造阶段，我们的团队也在这次团队项目中经历了这几个阶段。
我们团队的萌芽阶段大致是从团队建立一直到团队现场编程之前。磨合阶段大致在团队现场编程及后续总结期间，此期间我们发现了自身的和团队的诸多问题，也遇到了部分矛盾，但同时也对每个人在团队中的职责有了更清除的认识，对如何进行团队协作也有了更深的理解。在 alpha 冲刺的前半阶段，我们团队就大致处于规范阶段，在这期间我们确定了包括代码格式规范，前后端接口规范等规范，同时每个人都更加积极地投入到团队项目之中，既参与各类安排的制定，又要求自身遵循制定好的安排。之后我们团队渐入佳境，逐渐到达了创造阶段，每个人都很好地适应了团队工作方式，团队成员间的交流也空前通畅，各类任务安排都能及时完成，每个人都尽力展现自己在团队中的价值。

软件要求

• 研发出符合用户需求的软件
  首先，通过前期的统计数据我们可以确定在 GitHub 中国用户不断增加的背景下，对 GitHub 使用上的不便也日益凸显，这尤其体现在语言的障碍和登录平台的不方便上。尽管我们所开发的小程序仍存在诸多问题，但毫无疑问，它确实能在一定程度上适应中国用户的需求。我们团队的成员也是该小程序的受众，所以我们也时常对这款小程序进行体验，所以我们也更有把握这么说。

论文阅读笔记

在该论文中，作者着重讨论了组件平均语句数、环路复杂度、最大嵌套级别、基本路径数、无条件跳转数、注释频率、词汇频率、程序长度、组件 I/O 结点数与开源代码质量之间的关系。
作者通过研究得出了其中对开源代码质量影响最大的因素为组件平均语句数、程序长度，这两个因素所对应的质量曲线与正态分布近似，换言之组件平均语句数和程序长度都是既不能太多，也不能太少。我在平常编写程序时就有注意函数和组件的粒度，使其尽量合适，故在自检代码后发现自己代码的组件平均语句数和程序长度还是比较合适的。
考虑到对开发过程的有限控制，作者认为 Linux 应用程序的结构代码质量比反对开源的人所期望的结果要高。但同时 Linux 应用程序的结构代码质量提供的结果低于标准所暗示的质量。这也提示我们，尽管开源代码的质量并不像反对开源的人所想的那样低，但它也确实存在不足。故作者提出以下三点提高开源代码质量的建议：

• 要求程序员在介入代码时考虑结构代码的质量。
• 项目协调员要根据预定义的标准评估程序员返回的代码的质量。
• 当项目出现严重问题时，项目协调人需要采取适当的代码重组决策。