| 这个作业属于哪个课程 | 2020 春 | S 班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | <作业要求的链接> |
| 这个作业的目标 | 软件工程实践总结 |
| 作业正文 | <本文连接> |
| 其他参考文献 | Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87 |
一、回望
（1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
这学期远程学习过程中，我的确体会到了修复 bug、团队合作开发的乐趣。在这个过程中，我愈发坚定自己专业的选择，软件工程确实是一个对我非常有吸引力的课程。不过，在这个过程中，渐渐发现自己越来越少进行独立思考了：遇到问题，先上 Google，很多时候是面向 Google 编程。我认为自己在独立解决问题这方面还需要加强，不能太依赖于现有代码或工具，这只会让自己的大脑逐渐退化，变得不会思考了。人是一个会思考的动物，要多尝试锻炼自己的思维能力，大胆质疑，提高解决问题的能力。软件工程其实就是一个解决问题的任务，一个不断发现问题-分析问题-解决问题的过程。
（2）你在第一次作业的个人简历中描述了这门课程结束后，你预期你将增长的能力、技术、技能，并绘制了学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
由于项目使用的技术并不是很多，只用到了 spring boot 和 vue 的前后端分离开发，在开发过程中也学习了一些中间件（Redis），然而这些内容远远没有达到我最初的预期。
（3）哪一次作业让你印象最深刻？为什么？
结对第二次作业 —— 某次疫情统计可视化的实现。这次作业涉及到了我的薄弱处--前端。我对前端的兴趣不如后端浓厚。因此这次作业下来，我起初是很担忧的，担心无法完成这次作业，拖累队友。不过，也这是在这种压力下，我尝试去克服这种恐惧：先去网上找一下类似的项目，参考它们是如何完成类似的监控平台的。后端部分是比较简单的，完成得也比较轻松，这也为我打了气。最终，在我们的通力合作下，完成了这个令我有些担忧的作业。
（4）在课程问卷中，我们统计了你在课程上花费的精力和提升；现在请你再次将这些数据罗列出来，作为个人的记录。包括以下内容：
-
统计一下，你在这门软件工程实践中，一共完成了多少行的代码
GitHub 上的结果是 41,344，这个数字包括所有的修改过程。由于我在后期也做了一些代码复审，因此数字会偏大些。
-
软工实践的各次作业分别花了多少时间？（做一个列表）
作业 花费时间 软工实践寒假作业（1/2） 6 hrs 软工实践寒假作业（2/2） 14.2 hrs 结对第一次 — 疫情统计可视化（原型设计） 60 hrs 结对第二次作业 —— 某次疫情统计可视化的实现 24 hrs 个人作业 —— 软件评测 8 hrs 团队作业就不列举了，当初花费的时间应该是每天 80 % 的空闲时间都在做团队作业。
-
累计花了多少个小时在软工实践上？平均每周花多少个小时？
这个现在也估计不准，这边就拿 2020-05-25 ~ 2020-05-31 这周我花的时间来估算一下：那周是 Beta 冲刺阶段，我在后端项目 cms 的花费时间为 24 hrs 24 mins，在前端项目 zhishe-cms-web 的花费时间为 4 hrs 36 mins。这些数据是 WakaTime 这个插件统计的结果。这周花费了 40 hrs 左右在实践开发中。其它周是做设计策划，时间没有统计。
-
学习和使用的新软件
Redis client，用来连接远程 Redis。
-
学习和使用的新工具
GitHub issue，用于项目进度控制。
-
学习和掌握的新语言、新平台
简单学习了一些 Vue，掌握 Spring Boot 后端框架。
-
学习和掌握的新方法
使用 GitHub issue 进行项目跟进。
-
工程能力的提升
- 使用 GitHub issue 做项目跟进
- 使用 Git 多分支减少冲突，做好版本控制
- 使用 Spring Boot & Vue 进行前后端分离开发
- 对线上问题快速排查
-
团队合作上的提升
- 和团队成员沟通协调项目任务
- 前后端分离，又有密切的合作
-
其他方面的提升
- 时间管理。每次都尽量在作业下达时尽快开展团队合作开发/设计，为项目留出可调时间。
- 项目管理。对项目有清晰的认识，同时做好项目进度计划和风险管理。
二、团队总结
软件工程实践是大学里少有的团队协作经历。
在这次实践中，我很荣幸作为团队组长，和大家一起完成整个软件的开发。在这个过程中，我觉得自己的计划安排是比较好的，每次作业都能提前交付，保质保量完成。同时，我们组的开发流程也是项目推进的重要方法，我们采用 GitHub issue 作为项目看板，时刻监控项目的进度。说到需要改进的地方，应该是每日例会的时候，应该预留一些时间给组员发表对项目的看法，很多项目的开发流程、方法都是我一人在操作，难免有许多隐藏的问题，需要团队成员一起纠正，大家一起探讨。
我觉得我的组员大体上完成得很 。做得比较好的方面有：能够按照一些既定的开发流程/规约进行开发，比如 GitHub message 的规范；有问题及时反馈，和大家积极沟通。可提升的点有：勇敢提出自己的想法，比如项目开发流程方面的、业务方面的、个人进度需要协调等等。
《构建之法》中提到，团队的发展分为萌芽阶段-磨合阶段-规范阶段-创造阶段。我认为我们团队目前达到了规范阶段，但离创造阶段还有一定的距离。创造力是比较难的，尤其对团队而言。团队成员需要为了共同的愿景而奋斗。
从开发的角度，我在团队中担任了后端（95%）和前端（5%），首先我负责前后端项目的搭建、连接测试，之后主要在后端负责活动论坛接口、权限控制、全局异常拦截以及一些项目的配置，我觉得我挺适合这些任务。
三、人月神话
1、我学会软件工程了吗？
-
研发出符合用户需求的软件
可以看到，项目发布后，注册用户数达到了一定的数量。不过，由于项目将宣传力度不够，因此无法让更多人使用。
-
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
我们的项目经历了完整的软件工程开发生命周期：需求分析-系统设计-数据库设计-编码-测试-发布 alpha 版本-编码-测试-发布 beta 版本。同时，我们项目的开发是项目组所有成员共同努力的成果，而不是靠一两个大牛通宵一两天赶出来的应付式作业。项目提交记录可以参考我们在 GitHub 上的 commit history（前端、后端）。
-
通过数据展现软件是可以维护和继续发展的
同时，由于我们的软件使用了 Git 进行版本控制，每次冲刺结束都会 release 一个版本，项目的可维护性是比较好的。我们 Git message 的格式也进行了规约，形如 build(sql): backup database，可以很清晰理解每次提交的改动，了解项目的开发流程。下面这张图是后端的部分历史记录，可以看到我们的整个提交历史是没有分叉的，原因是我们使用 rebase 使每次提交都像是在上一个版本基础上修改的，方便代码复审和二次查看。
2、我的人月神话
个人或结对或团队项目实践中的经验总结 + 实例 / 例证结合的分析
项目功能点多，数据库设计时可以把一些功能放到后面再设计。项目开始时，由于我们对项目的开发进度都不熟悉，一致认为项目的功能较多，于是把点赞、评论功能搁置到了后面，等一些功能开发完后有时间再设计这些功能。我们的功能点是比较多，但是由于我们是前后端分离的，前端其实不涉及太大的改动，真正的工作量在后端。我们在设计时完全可以把所有功能都设计，而真正实现的时候就不用考虑数据库的设计了，这样会让我们的项目流程更加规范，项目进度也会推进的更快。总而言之，是我们陷入了思维定势：功能多就不一定开发得完，后期再设计不会花费太多时间。其实软件工程有点类似汽车制造，流水线式的生产才能使效率达到 max。而衡量一个项目的工作量不只是考量这个项目的功能点有多少，还要考量：
- 项目具体业务的难度
- 业务之间的依赖关系
- ...
在这次实践中，我们就只考虑了功能点的量，而没有考虑到质。
四、建议
对下一届同学的建议，或者对于开学初的你，对于大一的你，你有什么建议和想要告知的呢？请写下你对后来人的期许。
-
对于下一届同学，或者大一的同学，我想说：
基础课程一定要学扎实，技术是技校都会传授的一种技能，不要太早陷入技术。基础课程是学习技术的根基。
同时，知识要先有广度，放开自己的视野，尽可能多得去尝试各种任务/技术，给自己多留些后路。
-
对于自己今后，我有哪些建言？
明确目标后就要坚定地走下去，不可三心二意，同时全面提升自己。
-
对于助教工作，我有哪些建议？
助教做得很棒。在助教的帮助下，本学期我经历了软件工程实践远程学习，感谢助教的一路陪伴！
我对助教的建议就是：一些任务安排可以先征求一下大家的总体意见，这样不会引发大量反对的噪声。
-
对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除？
软件工程实践是软件工程学科必需经历的一门实践课。软件工程实践上课的形式有些单调：学生代表发言-老师助教点评-学生代表发言-老师助教点评-...。应该让更多的同学加入课堂，否则实践课很可能就是一部分同学的课堂了（大部分人可能没在听）。具体方式可以采用发言奖励等方式，提高同学的课堂参与度。
五、个人技术总结
使用 Redis 缓存实现点赞和取消点赞
概述：介绍如何使用 Redis 缓存解决高并发下的点赞和取消点赞问题，提高数据访问速度并进行定时数据持久化。
六、软件工程代码质量阅读笔记
原文：Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87
本文主要是介绍开源软件（Open Source Software，OSS）应该追求更高的代码可维护性。
开源解决了许多闭源的问题，开源可以生产出可靠的、高质量的、低成本的软件。很多人可以使用开源软件的源码进行二次开发或者提交 bug fixes，对已有的代码做出改进。我们这次软工实践便采用了类似开源的开发方式，我们将源码放在 GitHub 上，每个人都可以看到我们的代码，因此我们的开发是并行的：有些人提交新的 feature，有些人提交 bug fix，整个开发过程就是在不断地重复以上的操作。不过，我们的代码提交审查做得比较少，都是直接合并到 dev 分支，最后直接合并到 master 分支，并不是对每个提交都进行代码审查（inspect）。
不过，开源软件也有其缺陷：缺乏完善的文档或者技术支持。
那么，如何评估代码质量呢？代码质量可以通过源代码的测量体现。典型的测量指标包括代码量（行数）和代码复杂度。我们可以为每个指标设定一个允许的范围，每个指标的取值都必须在允许的区间内。
下面看几个比较常见的度量指标：
-
Number of lines of code，LOC（代码行数）
-
Percentage of lines of comments with respect to the number of lines of code (PerCM) ，用于表示代码的自描述性，简单来说就是注释占代码的比例
-
...
最终，文章中选用了 Maintainability Index（MI），因为 OSS 应该遵循这样的规则。MI 考虑了代码量、代码复杂度和代码的自描述性。MI 越大，表示代码的可维护性越高。
研究首先针对比了 CSS 和 OSS 开发相同功能的软件的代码可维护性的变化，可以看到，虽然两者的可维护性都在走下坡路，但是 OSS明显好于CSS。
之后，通过一个 CSS 转为 OSS 的例子告诉我们切换并不会降低可维护性。
最后，我们可以得到临时结论：
- 使用诸如 MI 衍生的工具来衡量代码质量，OSS 与 CSS 差不多，有时会更好。
- 由于不同发布版本间的突发变更，OSS 项目可能需要仔细的分析，20% 的组件会产生 80% 的可维护性问题。
- OSS 的代码质量问题和 CSS 的问题类似。
最后，重要的一点是要将 OSS 质量的结构视图和用户的感知质量视图集成到一块。