| 这个作业属于哪个课程 | 2020春s班 |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 总结实践学习成果 |
| 作业正文 | 正文链接 |
| 其他参考文献 | Code quality analysis in open source software development |
1. 回望
1.1 对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
学习到了软件工程的整个开发流程，在开发过程中掌握了如何进行项目设计、需求分析和提高了编码能力例如后端Spring开发，软件工具也达到基本目标例如GitHub、IDEA以及测试工具Junit、Jmeter等工具，提高了我的实践动手和文档编写能力，对于团队交流和debug也进行有所加强；
当然也存在着很多不足，例如项目的管理、进度安排、任务的粒度控制和分配、软件的代码重构和质量控制，这些软件工程方面的专业知识并不充足，仅仅体验一次实践经历，还需要加强在理论上的学习，避免以后在软件开发上的错误和手忙脚乱。
1.2 你在第一次作业的个人简历中描述了这门课程结束后，你预期你将增长的能力、技术、技能，并绘制了学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
本次作业的全过程没有用到学习路线的Linux技术，服务器系统是用的windows，所以在这上面并没有增长；但是在Spring boot的开发积累了很丰富的实践经验，结合学期课程JavaEE，对spring框架的配置到使用有了很大的提高，同时在其他的方面比如测试（学会IDEA-Junit、Jmeter）、项目管理和代码审核（GitHub）的能力有了一定的提高和经验积累，这对以后的任何开发都是益处良多。
1.3 哪一次作业让你印象最深刻？为什么？
beta冲刺；beta冲刺是整个团队以及我个人完成度最高的一次作业，它是在alpha经验上进行进一步完善软件的过程，让我看到了在软件工程方面无论是文档还是开发和debug实实在在的提升，特别是在debug上，每天都要测试修复测试修复（开发远不如寻找bug来的麻烦），而且beta冲刺还带来了相对完善的软件成果，这是比较令人开心的。
1.4 在课程问卷中，我们统计了你在课程上花费的精力
| 作业 | 时间 |
|---|---|
| 软工实践寒假作业（1/2） | 5 |
| 软工实践寒假作业（2/2） | 20 |
| 结对第一次—疫情统计可视化（原型设计） | 10 |
| 团队作业第一次—团队展示和项目展示 | 3 |
| 结对第二次作业——某次疫情统计可视化的实现 | 16 |
| 团队作业第二次——团队Github实战训练 | 9 |
| 团队作业第三次—项目需求分析 | 8 |
| 团队作业第四次—项目系统设计与数据库设计 | 8 |
| 个人作业——软件评测 | 10 |
| 团队作业第五次——站立式会议+alpha冲刺 | 70 |
| 团队作业第六次——beta冲刺+事后诸葛亮 | 60 |
| 个人作业——软件工程实践总结&个人技术博客 | 6 |
| 总计 | 225 |
1.5 在课程问卷中，我们统计了你在课程上提升；现在请你再次将这些数据罗列出来，作为个人的记录
- 整个过程的代码量：
10000+ - 累计花了多少个小时在软工实践上？平均每周花多少个小时？
225h；12.5h。 - 学习和使用的新软件
IDEA、Postman、Jmeter、GitDesktop、Axure、ngrok。 - 学习和使用的新工具
Github、Redis。 - 学习和掌握的新语言、新平台
Spring框架、博客园。 - 学习和掌握的新方法
压力+单元测试、原型制作、本地服务器的前后端对接、生成jar包、燃尽图绘制等。 - 工程能力的提升
文档编写、代码重构、项目管理、后端开发等。 - 团队合作上的提升
合作交流能力、线上对接测试、任务分配和管理、活跃团队气氛等。 - 其他方面的提升
自我debug能力（单独解决难题）；编码能力（spring框架、java的提升）；自我管理（严格开发）等。
2. 团队总结
2.1 你是组员还是组长？你觉得你自己在哪些地方做得好？你觉得自己还有什么可以改进的地方，具体可以怎么改进？
组长；活跃组内气氛和鼓励组员交流问题做的比较好，会主动监督组员开发进度督促组员完成任务并要求每日交流成果和问题；在任务的粒度划分以及分配上不够理想，进度安排也不够严谨；如果今后还能在项目当组长或者负责人，在任务的划分上不仅仅考虑功能模块之间的耦合度，还要考虑之间的粒度，尽量做到低耦合的情况下满足粒度合理，可以在分配任务的时候更为平均，或者从人员上组合分配，较大的模块由两人或者以上合作完成，从而减小模块粒度，同时进度安排要紧凑且循序渐进，项目初期的进度安排尽量宽松可以熟悉项目，到中后期紧缩进度安排，提高效率，同时留下缓冲时间，不要将预计时间安排满满，避免出现突然的任务增加。
2.2 你觉得你的组长（组员们）在哪些地方做得好？你觉得ta（ta们）还有什么可以进一步提升的地方，有什么具体的建议吗？
在任务的完成情况和态度都很好很积极，会主动进行项目的协同管理，不是被动的参与项目，对待任务负责任同时可以应对突然的职责和任务变化；在开发效率和一些功能逻辑的处理需要提升，debug较为薄弱需要加强这方面的知识和实践。
2.3 《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
萌芽阶段-磨合阶段-规范阶段-创造阶段。都经历过，从萌芽阶段，大家都很陌生，合作交流没有碰撞，仅仅讨论自己观点，到磨合阶段，会主动碰撞，摩擦想法取得一致，然后进入规范阶段，大家观点突出，想法取得一致，依照规范进行开发；我们团队应该可以说达到了规范阶段，团队可以很好的合作，协同开发，但是在创造的路还需要走近一步。
2.4 从开发的角度，你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
项目是前后端分离的项目，前端为Android开发，后端为spring开发，在团队开发中我主要负责后端开发和涉及的一两个网页；完成；适合，后端开发是比较适合我的，相对于前端的布局和美工，交互响应优化，我觉得我在面对数据处理加工更游刃有余一些，对于本次的后端开发虽然有些不足（对数据库还需加强），但是可以满足软件使用。
3. 人月神话
3.1 怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？
-
研发出符合用户需求的软件
因为没有做后台功能，所以没有统计页面观看，每天有些许人（很少，自己人）在使用这个软件的，每天都有人进行专注。 -
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件,有项目规划/需求/设计/实现/发布/维护，有定时的进度发布
在冲刺阶段完成了整个项目，每天都要提交代码，进度发布，同时组里没有大牛，软件都是合作一起努力完成的。
-
并且通过数据展现软件是可以维护和继续发展的。而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
后端GitHub仓库
前端Github仓库
3.2 写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析。
初期设计十分关键尤其是UML和数据库设计和创建。从我个人在项目的alpha和beta冲刺中，时常会被数据库在面临临时变化带来的麻烦搞得头疼，这些很大部分是由于数据库设计得不够合理，考虑得不够全面带来的。一个软件的起点来自于需求分析，所以UML是整个软件的关键，而且我们对软件的数据库进行设计一定要紧跟着需求分析后的UML，而在这次的软工实践中，出现了很多数据库设计和UML不够结合的问题，设计数据库的人也不够了解UML，尽管在答辩后有进行修改完善，但是还是会有一些没考虑到的地方，同时负责建立数据库的人不是设计数据库的人（分配任务确实不够好，希望以后能够加强），这导致尽管表的数量不是特别多，但是却异常混乱，关联和字段都有很多问题，例如进行团队接口的编码时出现了很多关联上的问题很难控制住，bug繁多。同时数据库设计谨慎自增主键和外键的关联使用，每当表在迁移重建时，自增主键作为外键是十分致命的，而且会带来非空外键插入的困难。数据库修改又是异常麻烦，涉及整个软件的脉络，稍不留神会搞崩项目，所以要做好一个软件完成一个软件，必须设计好UML和数据库，如果想要做好软件工程师，加强数据库学习是必不可少的。
4. 建议
4.1 对于下一届同学，或者大一的同学，你想说：
明确自己的目标，如果希望升学就努力读书，尽可能保研毕竟现在考研越来越拥挤，如果希望就业，那么尽可能的精通语言学习前沿技术，多参加比赛积累成绩和经验，如果犹豫不决，请一定仔细思考，同时在学习上保持着对软件工程的激情和积极性。
4.2 对于自己今后，你有哪些建言？
希望可以不断变强同时保留头发，希望可以不断进步同时身体健康（愈发觉得身体才是最重要的），任何事情自己一定要努力但是要健康。
4.3 对于助教工作，你有哪些建议？
助教做的很好，加油，希望助教能够凶一点。
4.4 对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除？
时间上可以调整，避免考研上的冲突（但是学习JavaEE后更好做这个，而且还要配套调整理论课，不太好调整），或者集中内容（将前期的设计工作尽可能集中，文档工作的周期太长，其实一个组九个人，负责一次设计可能只需要两三天）；可以加强实践的教学，比如GitHub使用等（可能因为这学期线上教学，所以开始的GitHub使用很生疏）；随机组队可以在项目的成员技能组合前提下随机，保证团队的配置较为合理。
5. 个人技术总结
概述：
@Scheduled是spring自带的定时工具，强大的corn表达式基本满足所有简单的定时任务工作，利用@Scheduled可以完成服务器的数据后台自动更新操作，非常方便。
6. 文献笔记
这篇论文主要旨在：（a）了解结构质量的含义；（b）找出对开源样式开发所交付的代码进行结构质量分析的好处。该案例研究的另一个目标是研究开源模块的问题，因为开源的支持者认为这种特性对于此类软件开发至关重要。根据经验评估了应用程序组件的大小与通过用户满意度测得的交付质量之间的关系。确定，在一定程度上，应用程序的平均组件大小与该应用程序的用户满意度负相关。
首先介绍开源软件开发（开源）：系统的核心由单个程序员或一组程序员在本地开发。原型系统已在Internet上发布，其他程序员可以自由阅读，修改和重新分发系统的源代码。例如发布在GitHub上的代码是开源的，这种开发就是开源软件开发，比较出名常见的开源产品例如Linux操作系统，Apache Web Server。
然后说明研究的测量以及评估依据：
- 使用Logiscope，一套全面的工具，能够自动执行代码测量并与用户定义的编程标准进行比较，Logiscope代码检查器和查看器功能对程序进行了分析，以计算选定指标的值并获得建议以改进代码。
- 检测SUSE Linux 6.0中100个C程序的示例，检查代码的总大小为606 095条代码行。
- 指标：
- 语句数（N_STMTS）：计算每个组件的平均可执行语句数[1-50]。
- 圈复杂度（VG）：由McCabe（1976）定义。它是一种基于图论的度量，表示连接图（在我们的情况下为组件控制流程图）中线性独立的路径的数量。它被认为是了解和测试组件[1-15]所需工作的指标。
- 最大级别（MAX_LVLS）：测量组件的控制结构中的最大嵌套数。过多的嵌套会降低组件的可读性和可测试性[1-5]。
- 路径数（N_PATHS）：计算每个组件的平均非循环路径数。它是测试组件[1–80]所需的测试次数的另一个指标。
- 无条件跳转（UNCOND_J）：计算GOTO的出现次数。这种类型的陈述与顺序控制流[0]的结构编程原理相矛盾。
- 注释频率（COM_R）：这定义为注释行与可执行语句的比例[0.2-1]。
- 词汇频率（VOC_F）：由Halstead（1975）定义为程序定义所需的唯一操作数n1和运算符n2的总和。此度量标准提供了不同的组件大小视图[1-4]。
- 程序长度（PR_LGTH）：测量程序长度，作为唯一操作数和运算符出现次数的总和。此度量标准还提供了另一个有关组件大小的视图[3-350]。
9.平均大小（AVG_S）：测量每个组件的平均语句大小，等于PR_LGTH / N-STMTS [3-7]。
10.输入/输出数（N_IO）：计算组件的输入和出口节点数。此度量标准控制与结构化编程的另一种已知原理的一致性（仅允许一个输入和一个输出）[2]。
- 质量标准和指标之间的关系以及建议：
然后根据上述工具以及指标，对100个代码示例进行检测，得出指标的度量统计，根据分数转换得出五个推荐类别中分配的组件百分比的统计描述，
最后得出结果表明可接受成分的平均值约为50％。平均而言，有31％的人需要进一步评论，有9％的人需要检查，有4％的人需要进一步测试，另外5–6％的人需要完全改写。
紧接着讨论组件大小与满意度：
- 通过代表用户满意度的因子（类别变量）USRSAT 对每个指标进行了单向方差分析（ANOVA）。
- 发现我们拥有的大多数指标之间没有任何关系，但是，发现组件大小和用户满意度之间存在关联
- 关联指标结果（语句数（N_STMTS）、程序长度（PR_LGTH））
根据文中的观点，与工业标准LOGISCOPE的比较的结果，可以作如下解释：
- 考虑到对后续开发过程的有限控制，Linux应用程序的结构代码质量所提供的结果要比反对开源的人期望的结果高。
- Linux应用程序的结构代码质量所提供的结果低于标准所隐含的质量。
第一个结果是支持开源开发。传统开发人员可能会担心开放源代码很可能会产生无法读取的代码，质量低下且无法维护。他们可能认为开放项目之所以能够生存，是因为大量的程序员（出于个人兴趣）具有无限的耐心，可以纠正错误并提供附加组件。从我们检查的数据来看，这种猜想似乎无法得到支持。整个程序中可接受组件的平均百分比仍然很高，因为一半的组件处于良好状态。另一方面，必须重写的组件的平均百分比并不妨碍代码上的更正活动。但是，应该注意的是，根据帕累托定律，
相反，第二个发现与开源开发哲学背道而驰。考虑到内部和外部质量特征与本案例研究的发现之间存在直接联系，开源社区似乎应该认真考虑开发更高质量代码的需求。这是因为以下事实：平均而言，所检查的每个应用程序中几乎有一半的组件未收到ACCEPT推荐，必须以某种方式进行重新处理或重新审查（即，重新编写，测试，检查或评论）。尽管开放源代码的优势来自大规模的代码级同行评审，但这种建议暗示着代码的结构方式需要进一步的工作。
使用三种不同的关键实践来帮助获得高质量的代码：
最后得出结论平均组件大小相对较小的应用程序似乎比平均组件大小较大的应用程序更好。
进而设想一个开源的过程：
结合本次实践，提高代码质量可以：
- 项目开始时每个开发人员必须遵守编程标准
- 发布新的内容或改动时，对代码进行分析，验证规范标准
- 使用测量使用作用于新版本配置
- 项目代码评审人员可以根据预定义的标准来评估程序员返回的代码的质量，如果不符合直接拒绝，保持代码的质量始终保持标准
- 当项目遇到严重困难问题，项目评审人员重新设计开发策略，避免项目进入死胡同，而最终失败