福大软工 · 最终作业 - 软件工程实践总结（个人）

最新推荐文章于 2024-10-01 05:04:32 发布

dkit23086

最新推荐文章于 2024-10-01 05:04:32 发布

阅读量298

点赞数

文章标签： python 面试 ui

原文链接：http://www.cnblogs.com/-JAM/p/10246291.html

版权

软件工程实践总结

一、回望第一次作业中对软件工程实践的想象

1.对比开篇博客你对课程目标和期待，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

开篇博客的期待(第一次博客链接)

希望能通过这门课程锻炼自己的项目开发能力，帮助自己较为熟练地掌握一些开发工具以及思维。
每周平均拿出六个小时左右吧，之后可以根据实际情况调整。

达到期待的部分

经过了这次软工实践自己的项目开发经历可以算是从无到有了（~~如果不考虑之前的数据库实践~~），学习了python的相关语法知识以及运用，接触了相应的IDE——pycharm。同时跟着组内的几位大佬进行学习也提高了自己的编程思维，学习了一些编码过程中debug以及优化的小技巧。

~~至于每周的学习时间简直是完全超出期待啊~~，这门课有着和它2学分完全不对等的学习时间，当然也许是我自己太菜了。
存在不足的部分

其实整个产品的开发还是靠着组内的几位大佬，自己有能力参与编码的部分还是较为有限的，这方面来说还是比较可惜吧，也辛苦组内的各位大佬不嫌弃我这样的小菜鸟。

2.总结这门课程的实践总结和给你带来的提升

软件工程中完成的代码数
- 总代码数
  
  第N周累计代码（行）
  15 1380
  
  参考个人的学习进度条可以了解到总共的代码行数是1380
- 最终可用代码数
  
  这里使用了张扬在群里提供的代码统计工具，可以得到最终可用的代码约有543行

第N周	累计代码（行）
15	1380

软件工程各次作业的用时

作业	投入时间（小时）
第一次作业 - 准备	12
第二次作业 - 个人项目	21
第三次作业 - 结对项目1	22
第四次作业 - 团队展示	2
第五次作业 - 结对作业2	41
第六次作业 - 团队选题报告	2
第七次作业 - 需求分析报告	20
第八次作业（课堂实战）- 项目UML设计（团队）	6
Alpha 冲刺（包括总结和答辩）	60
团队现场编程实战（抽奖系统）	6
第十次作业 - 项目测评（团队）	10
Beta 冲刺（包括计划和总结以及答辩）	12
总计	214

以上统计是结合学习进度条和其他博客进行统计的，可能有一些误差，时间太长真的回忆不清楚了

印象深刻的一次作业

必须是Alpha冲刺了，现在回忆起来还是觉得荡气回肠。组内的小伙伴们在Alpha冲刺的时候常常一起约在活动室进行集体编程，我们一起踩坑一起爬出坑，互相帮助解决编码过程中遇到的各种问题，这是以前从来没有过的经历，给我留下了非常深的印象。一群伙伴为了共同的目标一起熬夜一起编码是非常有趣的，这是极其珍贵的经历。
累计花了多少小时，平均每周多少，贴出开篇博客打算平均每周拿出多少小时用在这门课上的回答

根据学习进度条来看累计花了351个小时，平均下来每周花了21小时，具体的表格可以参考之前博客的学习进度条。

开篇博客的估计如下：
- 每周平均拿出六个小时左右吧，之后可以根据实际情况调整。
现在只能说还是太年轻，之前根本想不到这门课需要话这么多时间。
学习和使用的新软件
- PyCharm
- Qt Designer
- 墨刀
- TeamViewer
学习和使用的新工具
- 墨刀
- TeamViewer
- Qt Designer
- 图床
- islide
- Leangoo
- ProcessOn
学习和掌握的新语言、新平台
- python
学习和掌握的新方法
- vs自带的性能分析测试
- 调用高大上的库（人生苦短我选python）
- debug时在关键位输出临时变量
- 风骚的调试功能（其实还不是很会）
其他方面的提升

学会了和团队成员进行沟通，提高了团队协作能力。提高了抗挫能力......

二、属于自己的人月神话

解决问题的方法要灵活变通

这方面在第二次结对作业真的是吃了不少亏，当时自己用结构体链表来构建字典树保存词组和单词。其实在编码的过程中就感觉到这样比较麻烦而且容易出错，但是因为个人习惯没有改变方法继续死磕下去。结果最后代码运行出现问题，而且反复找了很久都找不出问题到底出在哪里。一直到最后时间来不及了才改用map来解决问题，结果出乎意料的顺利...
团队交流要积极

不能被动地等待PM下达任务或者等待和你结对的同学来找你一起打代码。在参与到项目的过程中一定要是积极的态度，被动接受任务对于自己和团队都是不好的。在第二次结对作业中因为我和结对的同学交流不够导致最后实际的完成时间被压缩了不少，而在团队项目开发中其实团队也存在因为过于依赖PM分配任务而出现的开发停摆。
多看多学多做

你可以菜，但是你一定不能因此不去尝试。在团队项目的开发中，我在开发经验以及python的使用上都是一片空白，开发过程中其他的一些工具也都是之前从未接触过的。为了弥补这样的天然缺陷我试着在学习文档的同时跟着大佬观摩编码过程，同时请教问题，之后回到宿舍再模仿大佬的代码和解决思路进行编码，在这样的过程中我学到了许多新的知识。（在这里非常感谢张扬大佬提供的帮助）。在看的过程中学习到的东西要在脑中消化，之后付诸实践。只有这样看到和学到的东西才能真正化为自己所掌握的。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：

1.你有什么想建议、告知和期许想要告诉他们呢？

在进行正式的开发之前一定要认真考虑开发中要使用的工具和语言，因为一旦开始开发之后很多东西就难以更改了，如果在开发过程中更改工具或者平台是非常痛苦的。
~~如果可以的话不要选这个课？因为真的对菜鸟非常不友好~~。不过正经说的话这节课还是可以让人学到很多东西的，不单单是开发产品的能力，还有演示、营销、人际沟通等很多东西。
希望学弟学妹们可以坚持下来吧。

2.特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？假设依旧是一个90+人数的大班

换队员进行少数几次现场设计是可以接受的，但如果指的是永久地强制更换到另一队，那么我认为是不合适的，这对于在有限时间内开发一个产品是不利的（虽然可以帮助模拟真实工作场景中跳槽或者更换项目组的情况）。

3.身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？

5个左右的话也许是不错的人数安排，人数多的时候会面临一些分工以及结果合并的困难。不如让组多一些，百花齐放。

4.个人/结对/团队作业应该控制在怎样的规模？

作业规模的话按照当前的规模其实还是有点点偏大（参考2学分的话），不过整套流程走下来的话还是对于理解软件工程有很大帮助的。

5.这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

张扬吧。在开发过程中整个后端几乎都是张扬在领头。因为是第一次接触产品开发还有python，所以在过程中碰到了不少问题，但是每次问张扬他都很耐心地解答。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？

萌芽阶段

经历过，团队刚刚组成的时候其实大家对于项目都有各自的想法。真正谈下来之后发现大家对于最终开发产品的看法居然是有出入的，现在想想还是挺有意思的。

磨合阶段

经历过，在这个阶段里面大家对于最终产品的定位产生了一些矛盾，这当然不是指队员间的矛盾，指的是想法之间的不同，不过在组长还有其他各位大佬的协调下最后都确定了下来。

规范阶段

经历过，确定了开发目标和定位之后大家就在组长的安排之下开展各项工作，整体流程还是比较清晰有序的。

创造阶段

不太确定有没有经历过，就个人感受的话团队还是比较依赖组长的分配，不能够做到书中说的自治，还是不够灵活。

五、怎样证明你学会了软件工程？

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

我们团队开发出来的产品托管在github平台上，但是暂时还没有打包成具体的产品，用户量暂时也有点不理想。但是从产品功能上还是具有相当完整性的，基本符合了需求分析时所提出的需求，只谈功能使用的话可以满足用户的需求。
2.通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

我们团队使用leangoo平台进行任务的发布和进度统计，同时在github上托管代码。在时间把控上面虽然还是存在一点熬夜加班的问题，不过我觉得整体上已经很不错了。最后开发出来的产品个人来说也觉得挺满意的，虽然暂时还未打包不过已经具有完整的ui界面以及功能模块，交互也还算友好。
3.通过数据展现软件是可以维护和继续发展的

开发中的源码有按照文件夹分类托管在github平台上，对于维护性和发展性还是有保障的。
4.对着检查表检查自己如果去企业面试，这些常见的问题是否都能回答，并在此总结

对于很多技术上的问题可能会回答不好甚至是回答不上来，同时也感叹本科期间可以学到的东西太少了，而且就这样量级的知识自己居然没能学的牢固，非常惭愧。在各方面的知识上自己还需要多加学习和实践的。

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

参考论文文献：

[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

最近考试真的特别多可能就暂时没法补上此处以及其他地方缺省的东西了