个人作业——软件工程实践总结&个人技术博客

这个作业属于哪个课程	软工班级
这个作业要求在哪里	作业要求
这个作业的目标	软件工程实践总结&个人技术总结
作业正文	作业
其他参考文献	《构建之法》软件质量的定量评估

一、回望

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

A：我觉得通过这次软件工程实践，我对软件开发的流程有了更清晰的了解，我还掌握了一门非常实用的前端开发框架vue，这不管是对我未来的继续升学或者是就业都是具有非常大的帮助的，在这之前，我不太知道一个软件是怎么产生的，我只知道要编程要写代码，但是这次软工实践让我体验到了同样重要的设计和分析阶段，我原来的期望就是能够掌握软件开发的一套流程并且熟悉掌握一到两个开发技术，我觉得在这两个方面达到了我的预期，但是我感觉我在设计整体开发进程上还存在许多的不足，我可能是一个很好的执行者，但是我无法成为一个很好的领导者，我有许多地方需要向我们组的组长学习，我觉得他不仅技术十分过硬，还具备一定的组织能力，正因为有他，我们小组的开发流程能够如此顺利，我觉得我自己的编程能力还有很大的进步空间，这包括了测试能力和代码重构能力，所以我觉得我在编程硬实力和领导能力方面还存在的很多的不足，也希望以后能够补足自己的弱势，成为一个优秀的技术人员和leader。

Q：你在第一次作业的个人简历中描述了这门课程结束后，你预期你将增长的能力、技术、技能，并绘制了学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？

A：老实说，我觉得自己有了非常大的进步，在寒假以前我都不知道到底什么是前端，什么是后端，更不要提怎么写代码了，而且由于没有经历过团队协作，我不会熟练的使用github和git这种团队协作和版本控制的工具，所以在当时我给自己的目标是：

寒假期间学完Vue.js、Ant Design、以及高德地图相关API、争取在大三下学期完成一项前端项目的开发，在毕业前能熟练掌握1~2种前端的常用框架以及相关IDE。
能够学会使用团队协作所必须的一些例如github、gitee等网站的使用，能够学会版本控制，能够养成通过博客园来进行日常记录的习惯，能够在规定时限内完成相应的任务，并且能够尽全力进行优化和调试，养成良好的团队协作能力。

现在看来，我掌握了Vuejs和学会了一种比较常用的UI库：element-ui，而且我成功完成了软工实践的项目，并且正在开发导师接的企业的项目，我能够熟练掌握github来控制我的代码，我也养成了用csdn来记录学习历程的习惯，我给自己满分能打8分，唯一不足的就是需要由执行者向leader转变，并且继续加强自己的编程能力和设计能力，希望未来我也可以有机会能够管理好一支专业团队。

Q：（3）哪一次作业让你印象最深刻？为什么？

要说到印象最深的我觉得就是第二次作业了，是一个写程序统计每日疫情信息的，当时其实我连看懂题目都很费劲，不知道怎么下手，所以我就问了其他大佬，问明白了需求是什么以后，我就开始着手编程，当时还要求commit次数要在10以上，可把我愁坏了，我不知道怎么才能达到10，但是真的编程的时候我发现10次真的太容易了，我每完成一个子模块或者修复一个bug，都是需要更新我的仓库，最后我提交了26次，也是十分具有成就感了吧哈哈，我还记得很清楚，当我非常顺利了完成编程任务后，作业要求的单元测试和性能测试可把我难住了，我之前没听说什么叫单元测试，于是我又开始百度，然后去问大佬，好在最后完成了，然后按照晚上的步骤装了JProfile来进行了性能测试，截图，提交，一气呵成，这次作业我真的做了好几天，每天都感觉花费了非常多的精力在这上面，提交的那一刻，突然感觉心里的石头落地，顿时轻松了许多，但是最最最最不能让我忘记的是，我最终获得了0分，我就奇怪了，我这么辛苦的作品怎么0分，问了助教才知道，原来我的编码格式有问题，在助教那跑不起来，哈哈也只能怪自己当初没看清楚作业的要求了，也正是这个0分让我牢牢的记住了这次作业，获得了宝贵的教训：审题！审题！再审题！

Q：（4）在课程问卷中，我们统计了你在课程上花费的精力和提升；现在请你再次将这些数据罗列出来，作为个人的记录。包括以下内容：

• 统计一下，你在这门软件工程实践中，一共完成了多少行的代码；
  2000-5000

• 软工实践的各次作业分别花了多少时间？（做一个列表）

软工实践各次作业	所花费时间
软工实践寒假作业(1/2)	6小时
软工实践寒假作业（2/2）	26小时
结对第一次—疫情统计可视化（原型设计）	28小时
结对第二次作业——某次疫情统计可视化的实现	15小时
Alpha冲刺	25小时
Beta冲刺	15小时
个人作业——软件工程实践总结&个人技术博客	6小时

• 累计花了多少个小时在软工实践上？平均每周花多少个小时？

累计花费121小时，平均一周8.64小时

• 学习和使用的新软件

Vscode、githubdestop、钉钉、Teambition

• 学习和使用的新工具

github、IDEA、Vscode

• 学习和掌握的新语言、新平台

vue.js、element-ui、vue-element-admin、vue-element-template

• 学习和掌握的新方法

RBAC权限设计

• 工程能力的提升

掌握软件开发具体流程、参与了软件编码前的系统设计部分，提升了编码之外的设计、测试等工程能力

• 团队合作上的提升

之前没有参与过团队合作，不知道该使用什么工具与他人协作，现在可以很熟练的掌握GitHub这种团队协作工具，并且擅长于与队友进行每日汇报和交流，互相帮忙解决困难和协商对接上的难处

• 其他方面的提升

提升了与他人交流的能力、提高了时间管理能力，学会当天任务当天解决，锻炼了集体意识，当自己的part完成后，会主动询问他人是否需要帮助

二、团队总结

• 你是组员还是组长？你觉得你自己在哪些地方做得好？你觉得自己还有什么可以改进的地方，具体可以怎么改进？

我是组员，我觉得自己在执行团队分配的任务方面做的很好，我很愿意且主动接下更难的任务或者更多的事务，并且我会在规定的时间内完成，如果遇到困难，我也会及时提出请求帮忙尽量避免让团队工作的推进停滞，我觉得我是一个很合格的执行者。至于改进的部分，我觉得我自己对后端事务的了解较少，因为我自己是一个前端人员，虽然后端的事务确实不在我的负责范围内，但我如果了解的太少，有时候在对接的时候会与后端人员协调很长时间，这样其实是降低了开发效率，所以我希望我在后面的时间可以也学习一下后端的技术，明白后端的思想，知道前端应该怎么拿数据或者怎么传数据是对后端来说最方便的，我觉得这是我应该要去提升自己的地方。

• 你觉得你的组长（组员们）在哪些地方做得好？你觉得ta（ta们）还有什么可以进一步提升的地方，有什么具体的建议吗？

先说组长，我们的组长是一个技术层面非常过硬的学生，也是一个具有组织领导能力的人，他会划分每个任务的粒度，然后让我们自己挑选适合自己的part，他也会经常向我们推送一些很好的博客和一些很好用的工具，极大了降低了我们的的工作复杂度，其次组长也会同时跟进前后端的进度，并且为我们提供一些建议，每天会定时举行小组会，他会认真听每个人的完成情况，然后进行一个建议和协调，我在他身上看到了一个具有多年开发经验的工程师的影子，很幸运能跟着这样的组长，可以学到很多东西。
再说到我的组员们，我觉得组员们都是非常积极主动的，我们团队从来不会出现有一个任务闲置了很久的情况，大家都很主动的揽下挑选剩下的part，而且每个人每天的交流都很活跃，前端之间，后端之间，前后端之间，正是这种积极的交流让可能会造成一定困难的bug迎刃而解，在团队答辩的时候，每个人也很认真的出谋划策来应对老师的回答，我们不是一个人在答辩，而是一整个团队在答辩，这也让我感受到了团队的魅力，如果说有什么可以提升的地方，我觉得包括我自己的每个人可以加强一下自己的工程能力，这样可以让组长轻松一点哈哈哈。

• 《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）

1. 萌芽阶段
   组队的那一天，学号最前面的同学拉了个群，然后大家加进来后，用一些表情包来掩饰尴尬，一起吐槽吐槽前几次的软工作业，大家都十分具有礼貌并且都不知道我们这个团队在3个月后会是什么样子的，我们的产品是什么类型的，我们的完成度如何，我们最后能得多少分，都是未知的，我们每个人要负责什么，谁是leader，也正是这种未知，才是随机组队的魅力所在吧！

2. 磨合阶段
   很快就到了需要讨论团队题目的时刻，我们觉得讨论之前还是需要先定个组长，于是我们采用自荐的形式，很幸运的是，我们有个非常优秀的同学自荐为组长，我作为他的舍友，知道他的能力有多强，感觉还是比较幸运能分到一组，大家不会像无头苍蝇一样去摸索而是有规划的推进。组长让大家各自提两个想法，最后我们定了是社团相关的产品，大家在需求方面也是非常踊跃的提供自己的想法，但是总觉得好像有些需求缺乏实际的技术支撑，团队中的很多人都还没有学习过技术，需求量非常大，很多人都感觉到最后可能完成不了，而且大家相互也不太了解，怕到最后整个团队只有几个人在做，剩下的在划水，于是大家就带着对未来的迷茫去学习新技术，去渡过这个磨合时期。

3. 规范阶段
   到了真正开始的时候，由于组长的领导非常到位，我们从需求分析到原型设计再到权限设计和数据库分析，整个流程都使用了规范的文档格式和规范的工具来记录，我们走的每一步都是有记录的不是盲目的，当有哪个步骤具有争议的时候，我们会马上停止网络上的聊天交流，而是直接开启群语音进行讨论，每个人的想法都会被倾听，最后会商讨出一个最合适的方案，所以我觉得我们团队的每一步都是和谐的、都是规范的、都是为后面的工作做好充足准备的。

4. 创造阶段
   真到了后面的alpha阶段和beta阶段，由于前面的工作十分明确而且规范，我们在编程的时候非常有目的性和规划性，每个人都在为自己的part而努力，查询各种资料，翻看各种视频，还解决不了的就会在每天的小组会提出寻求他人的帮助，我觉得最巅峰的时候就是alpha时期，大家从早上开始就在群里分享一些进步和一些困难，然后大家都会时刻关注群里的最新讯息变动，然后时刻跟上团队的步伐，每天的github提交次数都是非常恐怖的，大家不怕麻烦，对自己的工作改了又改，问了又问，反复如此，七天后，我们组的作品的完成度已经超过90%，在alpha答辩的时候，已经比其他组优秀了非常多了，其他组可能这是一个半成品，或者bug非常多，但是我们组已经是一个可以使用的小项目了，到了beta阶段，我们没有松懈，我们每天都往项目里添加小功能，并且进行了大规模的测试，前后端的主要工作都在测试，大家发现bug，提交issues，解决issues，项目的健壮性日益增长，我觉得我们最后的完成度到达了100%，甚至还有超出，我们也对自己的产品十分具有信息，认为我们的产品十分完美，这种感觉太棒了！

• 从开发的角度，你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？

我在团队是担任了前端开发人员的角色，我觉得自己非常高效的完成了该角色的任务，我不仅把自己的部分编写完成，而且还努力的帮忙找寻bug，然后进行修改，并且我还负责前端代码的重审，我觉得自己在这次软工实践中的表现对得起自己，我超额完成了任务，并且效率高，时效快，我觉得我非常适合作为一名执行者和开发者。

三、人月神话

• 怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一

1. 研发出符合用户需求的软件

我们小组所开发的社团管理平台在5月31日和6月5日这两天的注册人数到达了峰值，有12个新用户注册，往后的几天基本都是至少有1-2个人注册，其实大多数用户都是我们组员身边的朋友或者同学，也是因为我们是学生团体，宣传平台受限，我们在这方面确实还是做的不够好，用户基数不够大，可能是宣传方面或者是功能方面不够吸引人，我们也一定会在以后的开发中多多注意。

2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
   我们的QQ群文件记录了我们开发的进程，从需求设计到编码到测试到发布，一步一个脚印，大家都有参与其中，而不是一个人全部包办的，所有的记录按照日期推进，每个阶段都有事可做，保证规范
   
   
   
   

Teambition上同样有我们团队的规划记录

然后是我们的github，分为后端和前端两个项目，还有一个doc是记录各种文档的

我认为我们团队在规划、设计、和团队分工上做的非常优秀，有条不紊，缓缓推进

3. 并且通过数据展现软件是可以维护和继续发展的
   我们团队的源码和文档都是记录在github上面的，不存在后续无法进行二次开发的情况，都是有地方可以找到当时相关的开发记录的
   知社github
   知社后端github
   知社前端github
   知社相关文档github

• 我们团队的人月神话

其实在立题的时候，我们团队就暴露出一个问题，那就是对于需求的把握和功能的设计是十分模糊的，大家各抒己见，但是最后可能缺少一个统一的处理方案，有一些似做非做的功能就在这个时候被遗漏在了角落。
举一个最简单的例子，就是我们项目的附件上传功能，这个功能是否实现关系到我们数据库的设计，因为如果不尽早定下，等到后面可能会涉及修改到数据库，这样是十分不好的，但是我们团队就是在这个问题上反复的讨论，很多次都是没有得出结果的，我们在需求分析的时候以及老师助教的建议下是决定实现的，因此添加了附件的url这个属性，但是后面考虑到实际情况下，一个社团提交材料肯定是要线下面对面的，在平台上提交显得多此一举，又决定不做了，但是可能通知的时候有一些误差，导致一些人知道不用做了，一些还以为是需要实现，这就造成了团队开发效率的停滞点。

再比如说，我们团队在项目的设计上是侧重于项目功能的量了，在项目功能的质上并没有把握的很好，为什么这么说呢？就是因为很多的界面的功能都是重复的，比如社团的活动论坛，不管在学生还是社员还是社长，都是几乎一样的功能，但是我们并没有在代码复用方面做的很好，这也是因为我自己在代码复审环节可能做的不够好的原因，造成页面与页面之间重复使用组件模块的范围较小，这个在以后的维护工作中是会造成一定的隐患的，我也会深刻的检讨自己在代码复审方面的工作疏忽。

总结来说，就是我们团队只把握了量，没有把握住质，缺少规范统一的意见统一，执行层面较为不果断。

四、建议

对下一届同学的建议，或者对于开学初的你，对于大一的你，你有什么建议和想要告知的呢？请写下你对后来人的期许。

1. 对下一届同学的建议：软工能力的培养不能全部等待和依靠大三下的软工实践，这样会有一点迟，希望好好理由暑假寒假学习一些常用的开发框架或者技术，将技术学扎实了，软工实践也就轻松了，万一到时候自己想要考研或者有其他打算，也可以熟练的完成软工实践任务后去进行自我提升，不然到时候技术不熟练，课程安排又紧急，万一有一些其他想做的事，会让自己的进程变得特别急躁。

2. 对于开学初的自己：希望自己能够确定读研的方向，然后提前联系好读研跟的导师，然后从大四就开始跟着导师学习以后读研的内容，这样读研后就会比别人多很多的时间来进行自我提升。

3. 对于大一的自己：大一的学生好好完成课内任务后，其实应该多多参加社团部门活动，多多结交朋友，好好的感受大学生活，好好的玩一把，那些科研项目或者竞赛等到大二吧，毕竟人生不只有学习。

4. 对于自己今后，你有哪些建言？
   既然选择了读研，就好好在研究生期间做出一番成绩，注重结交一些优秀的研究生同学作为自己的同伴一起奋斗，好好学习导师的品质并且珍惜导师给的每一次机会和资源，在别人开始增加工作履历的时候，你在读研，那就再继续加油三年，要悄悄努力，三年毕业后一鸣惊人。

5. 对于助教工作，你有哪些建议？
   其实一直想对助教说，我知道人不可能每时每刻都在看手机，但是既然是助教，那应该尽量做到及时回复信息，大家有时候有一些疑惑或者有一些需要商讨的地方，都找不到人，还是希望助教们能更及时的为同学们答疑解惑，感谢！

6. 对于软工实践课程，你有哪些建议？对于软工实践课程的上课形式和内容，你有什么具体的意见和建议？在哪儿需要强化或者剔除？
   软工实践课程我觉得放在大三下有点晚了，应该尽早让同学们接触实际开发，好让同学们决定自己未来的方向或者选择进行读研，放在大三下的话，实际上与就业和考研冲突在一起了，大家很难把心思都放在这门课上。对于软工实践课程的上课形式和内容，因为今年比较特殊，由于疫情原因只能在家通过网络学习，不知道原先是什么模式，首先我对随机组队这个机制还是比较满意的，毕竟我自己这次的体验十分的好，也认识了其他班的一些同学，但是后来的模拟企业换人大可不必，大家是学生，企业是员工，还是有很大的区别的，学生有其他的安排，比如考研，比如找实习，在beta冲刺的时候再采取这种模拟换人的机制多少显得有点扰人，然后就是在上课内容的方面，我觉得既然每一次作业都对应着《构建之法》中的某几点，那么是否可以安排一些做成简练的ppt先跟学生们讲解一遍，不然抱着一个电子书pdf在那啃有些难以坚持下去，而且电子书想看前面的某一处翻来翻去又很麻烦，希望这个点可以改进一下。然后就是在每次安排作业的时候，我觉得任务博客的编排有待改进，现有的问题是前言、实际要求、目的、选做的部分杂糅在一起，我看完博客的第一感受就是我不知道我到底要做什么，可以将需要做的事情具体标出来，比如是做一个原型，或者是写一份代码，或者是写一份博客，将实际要求以外的其他地方与实际要求分开，并且界定清晰的界限，至少让学生们一看就知道这次任务是要做什么，毕竟对于学生来说，重点肯定是放在怎么完成，完成什么，而不是为什么要完成，我建议还可以将往届优秀博客附个链接出来，让学生们看看，到底做成什么样的是令人满意的，我认为这样的改进可能能提高这门课的教授质量。

五、个人技术总结

社团相册多图上传
概述：
介绍了在实现多图上传过程中遇到的一些困难，然后如何分点解决并且是通过哪些渠道和资源完成了技术

六、软件工程代码质量阅读笔记

文章原文
本文是介绍了软件质量的定量评价。
首先我们需要软件是不是只需要做到按时、在预算内交付，并正确、高效地执行所有规定的功能？答案是否定的，原因如下

1. 如果这个软件产品是难懂且复杂的，那么可能在后续的维护工作中需要支付更大的代价
2. 如果这个软件的使用难度特别的高，又或者是这个软件的使用方向模糊导致容易被误用，对于用户来说也是很难接受的
3. 如果这个软件特别的依赖于某些机器或者是集成环境，那么随着机器版本的不断更迭，或者是集成环境的更替，那么这个软件的质量就会受到比较大的影响

那么知道了软件评估的重要性后，我们就要从以下几个特性方面去了解软件质量

1. 软件产品的质量规范。针对项目的需求制定对应的性能规划、可理解性、性能保持等是十分重要的。
2. 检查质量规范。昂贵的费用可能导致影响人们的事情，但是这种规范的质量监测确实十分具有意义的。
3. 权衡开发成本和操作成本。尽量避免在开发阶段因为成本的问题而导致许多问题的遗留使得后续在操作阶段造成更多的代价付出。
4. 选择合适的软件包。许多用户需要一个评估每个包适应其安装的难易程度、不断变化的需求和硬件基础

选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。
在选取评估指标时，我们还应该按照如下原则去进行软件质量评估：

• 针对性
  即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。
• 可测性
  即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。
• 简明性
  即易于被各方理解和接受。
• 完备性
  即选择的指标应覆盖分析目标所涉及的范围。
• 客观性
  即客观反映软件本质特征，不能因人而异。
  应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。

那么回到我们自己编写的代码，可以发现如下几个比较大的问题：

1. 代码过度侧重功能的完成，在代码设计和性能优化方面完成度较低，这也是新手开发人员的通病，对于开发人员最直观的就是功能、任务的完成，那么对于抽象的软件质量评估则早已抛之脑后。
2. 代码的简洁度有待提高，后续维护工作的工作量大。
3. 代码复用性低，使得对于一个地方的修改导致牵一发而动全身，会造成性能效率极大的降低。

虽然软件质量评估是十分重要的环节，但是从文中我们可以得知当今的软件质量评估技术尚未成熟，还处于发展阶段，计算机技术、数据融合技术、网络技术和通信技术的发展过快也导致了我们对软件评估的要求越来越高，虽然我们已经制定合适的指标体系，但是软件评估有其领域内特殊的规范，我们目前受限于许多不确定性、涉及面太广、较为抽象难以量化等困难，这条路道阻且长。