作业格式
| 这个作业属于哪个课程 | 软件工程1916-W(福州大学) |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结作业 |
| 学号 | 221600417 |
| 这个作业的目标 | 总结这学期的软工实践。 |
| 其他参考文献 | [1]邹欣.构建之法[M] |
一、请回望开学初的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
整个软件工程课程中，贯彻着软件项目管理的思想。通过组队进行团队项目的开发，让我对于未来工作中的协作开发有了一个更好的认识，开发过程中的经验教训都将会让我在以后的工作中更好地融入团队，高效率地进行协作开发。在认识软件项目管理和提高协作开发能力都达到了我的期待和目标。
但明显的不足是，项目的代码质量值得商榷。即便课程包含项目测试的过程，但由于时间的紧迫，项目开发的难度较大，无法编写出高质量的代码。很多时候没有考虑到代码的鲁棒性以及性能，而是想着加快开发的进度。
2）总结这门课程的实践总结和给你带来的提升
1.统计一下，你在这门软件工程实践中，完成了多少行的代码
大概完成了6K行左右的代码。
2.软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业名称 | 时间/h |
|---|---|
| 第一次作业-准备篇 | 1 |
| 结对第一次—原型设计（文献摘要热词统计） | 4 |
| 结对第二次—文献摘要热词统计及进阶需求 | 7 |
| 团队作业第一次—团队展示 | 1 |
| 团队作业第二次—项目选题报告 | 3 |
| 团队第三次-项目原型设计 | 4 |
| 团队作业第四次-项目需求分析 | 8 |
| 团队作业第五次—项目系统设计与数据库设计 | 13 |
| 团队作业第六次—团队Github实战训练 | 12 |
| 项目Alpha冲刺（团队） | 60 |
| 事后诸葛亮（团队） | 2 |
| 项目Beta冲刺（团队） | 90 |
| Beta阶段团队项目互评 | 2 |
| 个人作业——软件工程实践总结作业 | 3 |
| 总计 | 210 |
3.哪一次作业让你印象最深刻？为什么？
项目Alpha冲刺最让我印象深刻。作为后端开发人员，长期面向功能点开发，而其他的前端人员则是面向自己的原型开发，导致后端的接口和前端一直对不上，接口的格式不对，又或者缺少接口。最后改变了开发的方式，结合前端的原型图，并和前端积极交流，砍掉原型图中冗余的功能点。最后也是慢慢的步入了正轨，没有在经常出现接口对不上的问题。
4.累计花了多少个小时在软工实践上？平均每周花多少个小时？
累计花了210+小时在软工实践上。平均每周花15个小时。
5.学习和使用的新软件和新工具
原型开发：墨刀
版本控制：Git
接口文档：Swagger
性能测试： JProfiler 腾讯压测大师
画图： ProcessOn
6.学习和掌握的新语言、新平台
无
7.学习和掌握的新方法
使用 MyBatis Generator 插件自动生成 Dao，Model，Mapping相关文件。
8.其他方面的提升。
协作开发能力，软件项目管理的理解，和队友的配合。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
团队项目实践中，我们团队经常不在一起同时开发，并且碰到问题时通过网络进行交流，此时就出现了一个开发效率上的问题。由于只能通过网络进行交流，往往一个问题需要解释半天，例如前端和后端讨论接口设计时，双方只能通过文字对自己的观点进行阐述，但如果换成口头交流，那么沟通的效率将提高很多。
因此，我得出的一个经验总结是：尽量使得团队在相同的地点相同的时间进行开发，遇到问题能够及时解决，整个开发的进度也会加快。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
下一届实践的建议：
这门课程能带领我们看到整个项目开发的过程，从需求分析，原型开发，系统设计等等一系列下来，每完成一个阶段的任务，也能从中学到一些新的东西，比如各种性能测试插件，原型开发软件，接口文档插件等等。虽然工作量相比其他课程不是一个量级的，但学到的东西也不是一个量级的！希望下一届，尤其是没什么项目经验的同学，一定要好好把握住这门课程，尽可能地投入到课程之中，过程肯定是辛苦的，但结果不会让你们失望的。
中途换队友：
换队友挺好的，能让我们充分感受到未来工作中队友离职所带来的危机感。但是，我觉得换队友还得换个差不多的队友，至少。。。语言是一致的。可以先调查每个团队所使用的语言，然后在相同的语言里面进行换队友操作。这样即便新队友不熟悉框架，但有了语言了基础，框架学习起来也就不会那么吃力，况且现在框架的门槛也是在不断地下降。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
萌芽阶段：
团队中每个人都表达了对项目的看法，并相互交流自己所拥有的技术栈。
磨合阶段：
前端和后端的接口没有对接成功，并且接口的鲁棒性不高，经常引起前端开发人员的烦恼，整个项目开发的热度以及效率都有所下降。前端的原型图也没按照完全按照需求进行设计，出现一些画蛇添足的东西。
规范阶段：
小组商议后，前端与后端的开发不再是独立的，封闭的，而是相互交流。通过大量的沟通，后端也就能够设计出与前端人员理想中的接口，不需要再进行频繁地修改，前端也修改了部分当初设计的原型图，整个开发的效率逐步提高。
创造阶段：
目前还没达到，会努力到达的。
五、怎样证明你学会了软件工程？
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件：
通过 Git 完成整个项目的提交，合理划分功能点，每完成一个功能点 commit 一次。将团队任务安排发布于博客之中，每天站立式会议确定今日任务的完成情况，解决问题，改进下一步任务。
并且通过数据展现软件是可以维护和继续发展的：
项目源码均保存在 GitHub 当中，在 Swagger 中在线保存着 API 文档，需求用例也留存在腾讯文档之中。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记
Code quality analysis in open source software development：
如何衡量自己的代码质量：
将分析限制在组件级别，即函数级别。收集项目中的数据，用于计算组件质量的10个指标。
度量指标及可接受的范围如下
| 指标 | 定义 | 可接受范围 |
|---|---|---|
| 语句数（N_STMTS） | 每个组件的可执行语句的平均数。 | 1-50 |
| 圈复杂度（VG） | 它是基于图论的度量，表示连接图中线性独立路径的数量，这里是组件控制流图，被认为是理解和测试组件所需努力的指标。 | 1-15 |
| 最大级别（MAX_LVLS） | 测量组件控制结构中的最大嵌套数。 | 1-5 |
| 路径数（N_PATHS） | 计算每个组件的非循环路径的平均数。 | 1-80 |
| 无条件跳转（UNCOND_J） | 计算GOTO的出现次数。 | 0 |
| 注释频率（COM_R） | 这被定义为注释行与可执行语句的比例。 | 0.2-1 |
| 词汇频率（VOC_F） | 由Halstead（1975）定义为唯一操作数n 1和运算符n 2的总和，它们是程序定义所必需的。 | 1-4 |
| 程序长度（PR_LGTH） | 唯一操作数和运算符的出现次数之和。 | 3-350 |
| 平均大小（AVG_S） | 每个组件的平均语句大小，并等于PR_LGTH / N-STMTS。 | 3-7 |
| 输入/输出数量（N_IO） | 计算组件的输入和退出节点数。该度量控制符合另一种已知的结构化编程原则（仅允许一个输入和一个输出）。 | 2 |
上述的指标以及标准充分反映了开源代码所需要的质量特定。
下面，通过一些指标，分析一下团队项目中后端方向的代码质量。（由于英语水平有限，部分指标目前无法理解
语句数（N_STMTS）：
较大部分组件的语句数只有30行不到，综合下来，平均数在35左右，符合要求。
最大级别（MAX_LVLS）：
从控制层，服务层，DAO 层 一共4层的嵌套，符合要求。
无条件跳转（UNCOND_J）：
GOTO 作为 Java 的保留字，但并不支持使用，没有出现的机会。出现次数0次，符合要求。
注释频率（COM_R）：
由于偷懒，或者没有这个习惯，大部分服务的实现类中的组件的注释频率小于0.1，不符合要求。
通过上述几个指标，我认为后端的代码质量还可以，值得提高的地方是注释频率。在以往的开发中，对于代码的注释并不太关注。但现在回过头看，发现开源项目的注释较多，例如Spring框架源码中，大部分的组件都包含一个注释头，说明了组件的作业，组件的作用，输入参数以及返回类型等等，这些注释有利于我们更好地阅读源码，提高整个项目的可维护性。在未来的开发中，我也将会试着在每个组件加入注释头，提高自己的代码质量。
七、个性发挥，包括图文、照片和创意等
不同人员看到bug的反应
