| 这个作业属于哪个课程 | 课程地址 |
|---|---|
| 这个作业要求在哪里 | 作业地址 |
| 这个作业的目标 | 软件工程实践总结&个人技术博客 |
| 作业正文 | 作业正文地址 |
| 其他参考文献 | 《构建之法现代软件工程》 |
一、回望
（1）目标与不足
对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
刚开始课程确实给我们大家带来了很多的学习上的压力，课程的工作量很大，使我们不得不放弃很多东西来应对软工实践的课程作业。对比目前的所学所练所得，软件工程实践课这门课程更加锻炼了我的专业能力，而且也因为这门课程，自己学习了很多新的知识，获取了很多新的能力，在抗压方面、以及巩固旧知识的方面上达到了课程刚开始时的期待和目标，在新知识的学习上，比如rust，angular内容的学习还是一片空白，因为针对的课程作业跟这些关系不大，也没有新的时间来学习这些知识，或者说有的看完也就忘记了。
（2）预期与实现
你在第一次作业的个人简历中描述了「这门课程结束后，你预期你将增长的能力、技术、技能」，并绘制了「学习路线图」。对比当前你的所学所得，你达到了当时的预期值吗？
还暂未完全达到，在实践课程的过程中，学习的主要是前后端基本知识，以及数据库设计，UML设计等等，很多都是在复习之前课程的内容，而新知识的学习相对来说会比较稀少，当时有些目标比如卷积神经网络，在其他的课程学习到了，并且在这段时间也通过空闲时间接触到了，但还是没有掌握好，但是也复习了前后端知识，比如使用vue，axios，跨域，ngnix，docket技术，redis缓存数据库，也复习了相关的知识点，前端webpack，以及各种前端框架和css框架的使用，但是一些类似于django，ruby等框架没有接触学习，也算是一种遗憾吧。
（3）印象深刻的作业
哪一次作业让你印象最深刻？为什么？
印象深刻的是读取日志文件统计疫情情况的作业。这个作业第一次学着使用git工具，而且因为utf-8的编码问题，最后做了半天正确率0%，在第二次重新测试作业后是满分，说明我代码数据读取是没问题，就是最后输出的时候忘记设置编码规则了导致了错误，说明自己还是不够认真，总要对此买单。
（4）个人记录
- 统计一下，你在这门软件工程实践中，一共完成了多少行的代码
粗略计算7000行。光是最后的实践课程就写了至少四千代码，加上前面代码量比较多的疫情统计1500。 - 软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业名称 | 估计用时（h） |
|---|---|
| 软工实践寒假作业（1/2） | 21 |
| 软工实践寒假作业（2/2） | 50 |
| 结对第一次—疫情统计可视化（原型设计） | 21 |
| 结对第二次作业——某次疫情统计可视化的实现 | 35 |
| 个人作业——软件评测 | 25 |
| 团队作业第一次—团队展示和项目展示 | 28 |
| 团队作业第二次——团队Github实战训练 | 13 |
| 团队作业第三次—项目需求分析 | 20 |
| 团队作业第四次—项目系统设计与数据库设计 | 25 |
| 团队作业第五次——alpha冲刺 | 75 |
| 团队作业第六次——beta冲刺 | 45 |
- 累计花了多少个小时在软工实践上？平均每周花多少个小时？
累计：340h，平均每周：17h - 学习和使用的新软件；
进度猫，webstorm，axureRP，postman，winSCP，starUML，xmind - 学习和使用的新工具；
git，vue-cli - 学习和掌握的新语言、新平台；
jquery，vue，elementUI，semanticUI - 学习和掌握的新方法；
原型设计、接口开发、单元测试 - 工程能力的提升；
1.学会使用部分前端框架；2.学会使用团队多人开发工具git； - 团队合作上的提升；
更加容易在团队中快速寻找定位，快速融入团队开发过程中，与人共同更加有耐心。 - 其他方面的提升；
管理能力和抗压能力
二、团队总结
（1）自我职责
你是组员还是组长？你觉得你自己在哪些地方做得好？你觉得自己还有什么可以改进的地方，具体可以怎么改进？
我是组长。
组长作为领导组织组员的重要任务，肯定要凝结起一个小组的力量，所谓：聚沙成塔，团结协作，才有可能“九臭顶诸葛”，还有就是“另起炉灶”，领导经验不足，需要自己成立一套管理方案，边执行边修订，所以我属于“解释性”组长。每天的会议也很轻松愉快 ，遇到问题大家互相帮助，遇到都不能解决的问题，那也只好让“提问者”，自寻“好”路。我也很尊重大家的意见，肯定的是，大家都不想“人为刀殂，我为鱼肉”，都希望承担自己想要完成的任务，所以我也算是半分配工作，将工作实际细分，首先让组员自己选择感兴趣的方面，然后再根据组员们自身能力对比，来进行适当调整。起初对组员的能力了解肯定会有偏差，在冲刺过程中，根据大家进度进行适当调整，重新分配。特别的事，期间还有一项烦人的工作，就是，催促大家提交感想和督促大家完成各自的任务，这个工作很重要，因为要实时保证任务正常完成，同时期间可能给会因为一些事情耽搁，要重新调整等等。刚开始冲刺的时候，因为经验不足，大家编码过程经常遇到很多问题，也都是大家齐心协力，共同克服下来的，大家都很棒。
虽然组员之间原本不熟悉，但是组员基本都是两两熟悉的，首先让他们自己班的同学互相交流，作为组长，我只要深入他们的互相讨论的小团体就可以了，大家虽然之前不认识，但缘分这东西说来吓人，聊着聊着不就熟了吗，大家互相开开玩笑，不也 挺好的吗，就是不知道回校了会不会像网上聊天这么活泼哈哈哈。组员一般有问题都是直接找相应人员解决问题，有时联系不到也会找我，我和大家的沟通都很耐心，当然也发过一次脾气哈哈哈，被写不出代码冲昏了头脑，我也认识到了错误及时改正。随机拼凑的组员，大家都很随和，交流起来很舒服，没有严肃的感觉。
我觉得自己可以在分配任务之前多多了解组员，平时多多在群里活跃气氛，比如可能可以一起K歌之类？使得大家互相多多了解，找共同话题快速融入确实比较困难一些，如果是线下可以多多的在一起拍照啥的可能会比线上好很多。
（2）评价他人
你觉得你的组长（组员们）在哪些地方做得好？你觉得ta（ta们）还有什么可以进一步提升的地方，有什么具体的建议吗？
我觉得我的组员们做的都很好，特别是在工作和沟通的方面都十分尽心尽力，安排的任务也都十分出色、认真的完成，只是对于冲刺每天要写的目标和总结，希望队员能够及时完成，而不需要我每天催。
（3）团队发展
《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
从刚开始的萌芽阶段，大家都不认识，个人的角色和职责不清楚， 做事的规程往往被忽略。 成员也在琢磨任务到底有多大， 怎么去完成它。每个人都忙着适应环境、 团队结构、 角色、 日常流程等。 有鉴于此， 严重的问题不一定能够及时地提出来讨论。 重要的事情并不能够真正得到解决；也经历了磨合阶段，不得不认真地面对问题， 开展讨论。 随着讨论的深入， 有些人会沉不住气， 就会出现小的意见分歧和冲突。 这些冲突不一定都是技术问题， 也许是关于角色、 职责、 相互关系， 甚至是各自性格、 文化的冲突。 这时， 成员之间会出现竞争， 不少人都想成为某个领域的“拥有者”；进入规范阶段，随着项目的开展和成员们的互动， 一些成文或不成文的规则逐步建立起来了。作为一个整体， 团队要做什么、 不做什么， 都更加明确。 团队定下了更现实的目标和决心。
最后还是没能达到创造阶段，团队无法脱离领导自我进行。
（4）开发角色
从开发的角度，你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
从开发的角度，我在团队中担当了前端开发的部分工作。我完成了前端自己对应工作的任务，在保持相应的界面的简洁优美的前提下，还完成了其他功能，类似词云等等；我觉得我适合这个工作，而且我完成的很出色。
三、人月神话
1、自我证明
怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一。
（1）研发出符合用户需求的软件必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
（2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
（3）并且通过数据展现软件是可以维护和继续发展的。而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
通过查看用户表、查看后端数据等方式可以看到，在我们的软件在发布后有73个用户注册记录，有一定的用户量。我们的项目都是进行了细致的项目规划然后一步一步执行需求阶段、设计阶段、实现阶段、发布阶段；代码放在github上，是通过git工具进行协同开发的，是可运行的，有issue，debug的资料的。
2、我的人月神话
写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析，字数不限，开放命题，可以使用你自己喜欢的方式表达
每个人对团队项目的作用都是不一样的，但又都起到了重要的作用。有些人作为开发的重要任务，有些人起到了活跃团队气氛，有些人起到leader的作用...就是因为这些形形色色不同人物的相互补充，团队才可能在未来的时间段里越走越好，而不是几个人在纠结于到底是谁好，谁不好的问题，这些问题是leader需要自我衡量并且去沟通队员的，不是每个队员需要关心的，队员只需要把自己的分内之事出色完成即可。本人有幸成为团队leader，润滑成员之间的沟通等摩擦是我的职责，特别是对于一组完全不认识的成员来说，首先有效的沟通可以先让我们能够得到互相了解的作用，然后通过有效的沟通可以解决很多问题，比如工作量孰多熟少等等，不仅作为一个leader，同时也要完成很多开发任务，而且还要每天准备冲刺博客，还要各种截图保存图片（不得不吐槽一下博客园上传照片的功能，不能同时上传图片，还要一张一张上传，麻烦得很，有时候烦的开始自我生气，怨天怨地，看来我戾气很重）。总的来说，在团队项目中，你要担任好自己角色要担任的任务，有问题就要互相协商，共同解决困难，有时候作为leader可能要完成比较多的事情，心情也比较烦躁，要沉得住气，随时keep a good spirit，快乐开发吧！
四、建议
对下一届同学的建议，或者对于开学初的你，对于大一的你，你有什么建议和想要告知的呢？请写下你对后来人的期许。
相对开学初的自己说，后面的工作量真的很大，希望你自己保持一颗不被击垮的心认真的完成自己的任务，同时和队友们进行有效的沟通，“俯身倾耳以请”，不会就问，不要自己纠结于一个bug不对任何人说，也不要自己完不成任务也不和组长说，这样组长既不能重新协调任务，最后也会耽误大家的进度，这种事千万不能在你的队伍中发生，如果你是leader，就要及时发现这种事。
1.对学弟
对于下一届同学，或者大一的同学，你想说：
大一的同学要经过两年的知识积累，认真学习每一个课程，课程知识都会在实践任务中有所体现，主要还是多多接触项目，多多从项目开发中获得经验。
2.对今后工作
对于自己今后，你有哪些建言？
在工作中，肯定需要自己有认真负责的态度，而且有自我学习的能力，毕竟工作过程中可能会遇到很多不涉及自己学过的的东西，所以需要继续学习。
3.对助教工作
对于助教工作，你有哪些建议？
助教已经做得很好了，无论是博客的评价，或者是答辩过程中的各个意见都做得很好了。建议是或许可以加入到团队群聊中进行适当监督？
4.对课程
对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除？
课程相对来说很完整了，希望可以有一节课对实践过程进行回顾；课程可以先进行适当地讲解，然后再让我们实践，不然我们自己学习相应内容确实有些辛苦。
五、个人技术总结
在第一次作业“准备篇”中你为自己制定了学习路线，现在学习了怎么样了？你在团队开发中是否担任了开发角色，你在开发中解决了哪些技术问题？获得了哪些技术进展？
第五个部分中要求你从个人技术学习角度和团队开发技术角度中选择你最擅长的一个相关技术，进行分析描述并总结。
相关技术的粒度不宜太大，比如不应该选择诸如Java语言/Html/JS这样的大类，而是一个较细的分类，如Axios的使用总结、Spring Boot上传和下载文件、在团队开发中我采用的推荐算法等。
要求为这个相关技术撰写一篇博客（单独，在第五部分仅需要提供链接和技术概述）
（1）前端框架的部署
概述：如何使用nginx对vue进行部署。这个技术是项目完成之后必须经历的部署阶段的任务。因为需要让别的用户能访问到我们的项目，因此需要将其部署服务器，vue项目需要部署到服务器才能访问，如何在服务器部署vue项目，成为一个技术难点；而且因为之前在服务器中已经部署了其他项目，因此，由于跨域问题，多个项目部署在同一服务器还是有点困难的。
（1）如何设置标签云
概述：通过在线数据，各个标签的数值，来实现一个标签云，这样可以比较直接的显示对应标签的数值大小，用户看起来很客观，同时也很美观。该技术作为必要的增强使用体验的一个功能，技术难在，使用vue来完成相应标签云的设置。
六、阅读论文
阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
[1] 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.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] 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] 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.
该文介绍了使用Logiscope作为代码测量和评估工具。该工具会评估每个组件并根据四个基本标准对其进行评估，使用测量值，即可测试性，简单性，可读性和自我描述性。该标准是采取从一个国际标准有关的子特性的软件品质。本标准由软件行业的众多公司共同发起，尽管遭到批评，但仍被认为是软件质量度量开发中的重要里程碑。
通过使用工具可以做到更好的审查代码，更加遵循代码规范。相比自己之前开发的代码，不太规范，审查起来错误百出，需要借鉴一些审查工具来对自己的代码进行合理规范。
通过相关资料查询，发现Logiscope 有三项独立的功能，以3个独立的工具的形式出现，即Audit、RuleChecker、TestChecker，它们之间在功能上没有什么联系，彼此较为独立。
“Audit”——审查、检查的意思，Audit的功能与它的名字也很吻合，它用于审查代码的质量。
使用Audit来审查代码的质量分为两个步骤：首先是建立被测程序的Audit项目，然后是分析Audit给出的质量审查结果。
RuleChecker是Logiscope的另一个功能，它是一个静态、白盒性质的测试工具，用来检查代码书写规范性。使用RuleChecker来检查代码的规范性分为两个步骤：首先是建立被检测代码的RuleChecker项目，然后是分析RuleChecker给出的代码书写规范性检测结果，得出报告。
TestChecker是一个白盒、动态测试工具，用于统计被测试程序的测试覆盖率。TestChecker重点统计的覆盖率是边覆盖率，也叫判定到判定的覆盖。
使用TestChecker统计被测试程序的测试覆盖率分为两个步骤：
首先是建立被测程序的TestChecker项目；
然后，在TestChecker环境中运行被测程序，执行测试用例，TestChecker会给出执行测试用例后的覆盖率。
该工具为每个软件组件和标准提出了具体的建议。建议级别如下：接受，评论，检查，测试，改写。
该文研究了结构代码分析可以提供的好处。结构分析可以使开发者清楚软件系统的整体实现构架，减少在开发中恐慌与困惑。
该文介绍了代码可维护性。同时介绍了OSS软件产品，根据资料，OSS是一种可分发的软件产品，阿里云对象存储服务（Object Storage Service，简称OSS）为您提供基于网络的数据存取服务。使用OSS，您可以通过网络随时存储和调用包括文本、图片、音频和视频等在内的各种非结构化数据文件。关于代码可维护，很多程序员不屑于维护代码，其实维护代码也是极其重要的，对维护者的软件素养和技能水平要求也是非常高的。软件维护有四个部分：
1 发现并修复bug（纠正性维护）
2. 系统需要去适应操作环境的改变--例如OS或者技术的升级（适应性维护，如适配Android版本升级）
3. 用户有新的需求，或者对之前的需求有变化（完善性维护）
4. 确定可以改进质量或者预防将来可能产生bug的方法（预防性维护）
对于既有的软件系统，它们可以被修改的难易程序是不同的。一个软件系统可被修改的难易程度称为它的可维护性。从软件的生命周期及成本来讲，使软件系统具备高维护性是极其重要的。遗憾的是，可维护性经常被忽视。
总结来说，代码规范可以大大减轻后期维护成本，同时也会减轻开发成本。学习使用代码规范工具可以纠正自己的代码规范性。
七、参考博客
- 《Logiscope使用说明书》——cmy673986
- 《代码的可维护性》——塞外的风