2021秋季软件工程实践总结

ChenYH 2021-12-10 15:56:07

这个作业属于哪个课程	https://bbs.csdn.net/forums/fzuSoftwareEngineering2021
这个作业要求在哪里	https://bbs.csdn.net/topics/603669220
团队名称	Undefined
这个作业的目标	对这学期的软工实践做一个总结，包括个人总结、团队总结分析、提出建议等
学号	031902202

软工实践总结

一、个人总结

对比软工实践课程开始时对课程的期待，目前确实了解到了软件开发的整个流程。从需求分析、软件设计到合作编程实现、软件部署发布，代码量远超刚开始的估计。如果说哪方面还有遗憾的话大概就是这次大部分的精力几乎都放在后端开发上了，没有在人与人的沟通协调上取得我希望的进步。
这门课程给我带来的提升：
1. 除去生成的日志文件、依赖信息文件、配置文件等等无效的代码行数，总的有效代码行数在 7000 行左右
2. 各次作业花费的时间
3. 第二次结对编程给我的印象最深刻，相比团队编程 alpha 冲刺令人头疼的后端开发强度以及各种协调问题。第二次结对编程才真正让我体会到合作编程的沟通合作精神，我更喜欢这种高效并且是实实在在的与队友共同进步、成长的过程
4. 累计花在软工上的时间为 189 个小时，按六周来算，每周 31.5 小时花在软工上
5. 新的软件：Another Redis Desktop Manager、Navicat Premium、Postman、Goland
6. 新的工具：亿图图示、GitMind、vscode uml图插件、墨刀、微信开发者工具
7. 新的语言及平台：Golang、HTML、CSS、JavaScript、GitHub、微信公众平台、微信云托管平台、微信开发平台
8. 新方法：通过编写脚本快速启动 Redis，给自己编写的代码做单元测试、给服务器做压力测试、编写接口文档
9. 其他方面：了解了前后端交互的模式、锻炼了合作完成任务所必须的沟通交流能力

二、团队总结

根据我对这学期我在软工方面的学习以及我们团队所具备的问题和所具备的优点，总结经验如下：

个人方面：
1. 在个人的学习方面，最好是有一个从易到难的学习过程。提前决定自己学习方向，早点开始学习，不要等到团队合作开始了才匆匆忙忙学起来。否则后面直接上手要么就是都不会，要么学起来磕磕碰碰，各种问题没法解决，加上 DDL 将近可能就选择摆烂了。
2. 自学能力是相当重要的，可以向能力更强的同学请教，但不要期待有任何人能手把手地教。
3. 在合作的时候不要抱怨，如果对哪些方面不满，最好去直接地交流。
4. 对于最终成绩的评定，如果没有取得想要的成果或者名次，也不要抱怨不公平，认真分析为何没有取得预期的成果，为何其他人就行，吸取经验，让自身成长才是最重要的。说其他人不行我行简单，只是一句话，真正做到需要长期的思考总结和努力。
团队方面：
1. 作为团队中的一员，协作交流的能力至关重要，除此之外还要具备责任感。一个团队从来不应该只有几个人发挥作用，或者只有几个人在意最终的开发成果。每个人都对团队负有责任，不要把任务都交给其他人。当发现有任务自己无法完成的时候，要即使的和队友沟通，不要直接就不做了，这是相当不负责任的行为。
2. 对于团队中已经具备相当能力的成员来说，开发的主要压力就在这些人身上。很容易产生“都是我在做，其他人怎么那么轻松”的心理失衡现象，如果产生这种问题应该即时和组长反馈，让其他组员分担一部分压力。千万不要“你们都不做，那我也不做”。
3. 团队的前后端进度很有可能是不同的，这时候需要组长或者一个指定的人负责前后端进度的协调，不要让 (前端/后端) 开发成员还需要自己去催 (后端/前端) 开发人员和自己同步进度。
4. 这次我虽然不是组长，但也是深刻的意识到组长的作用了。结合我们这个小组组长的优缺点，我认为一个组长至少需要做到以下这些：
  1. 首先组长自己要做到把这次团队合作放在心上，也就是说组长应该具备比其他成员更强的团队责任感、行动力以及意志力。
  2. 组长需要具备相当的协调能力和决策能力。不同的成员有不同的长短处，要让每个团队成员都发挥自己的作用，让合适的人在合适的位置，对项目的发展交付要有长远周全的考虑。另外当团队的意见产生分歧的时候要能够做出决断，组长不能举棋不定、唯唯诺诺。组长需要适当听取组员的意见，但不要完全被组员的意见左右。
  3. 组长虽然不需要写代码，但是作为团队最重要的沟通桥梁和团队核心，合理的组织、安排、交流，这些都是团队进度能够正常前进的保证。要成为让每一个团队成员都能够信赖的人，可以说组长基本决定了小组的风格和小组的合作体验。

三、提出建议

如果要保证团队实力的平衡，也许可以考虑前 50% 的同学随机分配而后 50% 的同学自由组队

下面的建议既是对自己的期许，也是对后来人的期许。

不管处于什么阶段，一定需要一个清晰可实践的目标，然后再朝着这个目标努力。如软工实践，专注于自己在这个过程中获得的成长。朝着目标走，这样不管什么成果，只要努力了就是在向目标迈步。
学习不仅是学技术、学知识，也是完善自己的品格。在团队协作中，你的队友的合作体验不止在于你本身能力强大与否，更在于自己的个人品行如何。追求进步，学会担起责任，学会体会他人的感受，学会控制自己的脾气，学会真正去解决问题而不是抱怨，学会在烦躁的时候静下心来，学会听取他人的意见，学会勇敢地去尝试，完善自己的缺陷，也许还要有一些幽默感。这些品质的重要性都不比单纯的知识学习差。

四、团队分析

我想我们的团队在第一次团队协作编程的时候还处于萌芽阶段。第一次的团队合作，虽然不算顺利，但大家的配合度都很高，让我觉得我们的团队是相当有希望的。之后 alpha 冲刺过程，团队进入了磨合期，会有成员对团队，对其他的队员的能力充满了质疑与不信任。之后为了项目的推进，大家还是需要相互配合，完成任务，这就进入了规范阶段。这时如何推进项目向前已经有了一个大体的流程，已经可以创造一些有意义东西了。但由于流程其实还并没有那么完善，分工也还存在一定的缺陷，所以我觉得团队还并没有进入真正的创造阶段。

五、软件要求

项目有项目规划/需求/设计/实现/发布/维护，有定时的进度发布。分为前后端的两个仓库，每个成员都需要负责自己的一部分。

软件有源代码，有 70% 覆盖率的单元测试，能够编译，并且有项目开发至今的全部开发日志和对应的接口文档，保证后续即使有新的成员加入也可以对项目的 bug 和开发过程有一个了解，并通过接口文档迅速进行开发。

六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：

参考论文文献：

[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