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

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

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

在开头先给出第一次作业链接及提出的期待：

1. 提高自己的代码能力
2. 弥补自己理论方面的空缺
3. 脱离小菜鸟的level

貌似自己开学时提出的期待并不多，下面分点进行讲述。

满足的期待

1. 提高自己的代码能力
   不得不说，这个学期的代码打得真的多。仔细想了想，我认为主要的提升是在代码的规范和模块化开发方面，以及在团队项目中所学习的Android知识。
2. 弥补自己的理论方面的空缺
   虽然上文刚刚提到代码能力有很大的提升，但我认为这门课最大的提升还是理论方面的提升。
   理论是实践的基础，代码规范化和模块化开发都是由理论知识的充实为基础实现的。规范的代码和文档总是能让人体会到代码的优雅，很多项目（例如uml图，团队项目评测）我之前都没有接触过，虽然仅仅一两次的实践并不能说对这些理论知识有多么熟悉，但这些实践经历无疑拓宽了我的知识面，是从零到一的突破。

未达到期待和目标

1. 脱离小菜鸟的level
   学得越多发现自己越菜
   一个学期下来感觉确实蛮累的，也确实学到了很多东西。每次解决一个知识盲区，但稍微深入探究就会发现更多的知识盲区；虽然说团队项目和个人项目都算是完成了，但自己却很清楚的知道还有无数可优化可改进的空间，可是由于自己的知识储备并不足以及时间不够充裕，没能够进一步的优化。
   只能希望自己能够一直坚持学习，坚持进步，早日脱离小菜鸟这一阶层了。

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

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

在此贴出这学期的学习进度条：

第N周	新增代码	累计代码	本周学习耗时	累计学习耗时	重要成长
1	235	235	6	6	C++STL容器的使用
2	0	235	5	11	学习Axure的基础操作
3	672	907	4	15	安卓开发基础
4	238	1405	6	21	Java正则表达式
5	30	1435	12	33	继续学习了Java正则表达式，学习Android组件
6	147	1583	8	42	学习Android的Internet相关知识
7	662	2245	13	55	学习了线性同余法和Count-Min sketch算法
8	1194	3439	19	74	了解Android的app运行方式，学习Service和Android数据库，第一次参与了软件项目的对接
9	645	4094	18	94	学习项目的微服务构架，再次学习Android相关知识

参照学习进度条， 这学期的代码行数应在4094行，可能会有细微的出入，但整体上应该是正确的。（中间有几周放假和没有代码进展的周数被我之前略去了，是不是有些不对。。。）

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

作业	花费时间（分钟）	博客链接
作业1：自我介绍	30	博客链接；
作业2：个人项目	980	博客链接；
作业3：结对项目1	300	博客链接
作业4：团队展示	10	博客链接；
作业5：结对作业2	700	博客链接；
作业6：团队选题报告	430（估计）	博客链接；
作业7：团队课堂UML设计	450	博客链接；
作业8：团队需求分析报告	845	博客链接；
Alpha版本冲刺	4510	博客链接1；博客链接2；博客链接3；博客链接4；博客链接5；博客链接6；博客链接7；博客链接8；博客链接9；博客链接10；博客链接11；
作业9：团队现场编程	805	博客链接；
作业10：团队项目测评（福大助手）	480（估计）	博客链接；
Beta版本冲刺	1100	博客链接1；博客链接2；博客链接3；博客链接4；博客链接5；博客链接6；博客链接7；博客链接8；博客链接9；

1.2.3 哪一次作业让你印象最深刻？为什么？

最让我印象深刻的是团队选题报告。

那算是我们团队第一次开会认真的讨论团队的项目，我还记得那时候在宿舍楼下奶茶店待到接近十二点（但之后发现十二点在软工实践作业过程中不算迟）。明明不是最累的作业，也没有什么特别新的知识，但那次开会第一次给了我“oh，这是一个团队项目，大家要一起努力”的感觉，嗯，可以说是第一次体会到团队的存在给了我最深的印象。

1.2.4 累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

累计花费：10640分钟=174.3...（小时）
平均每周：截止beta答辩总结（第16周），花费=174.3/16=10.25（小时）
开篇博客计划：

只有想不到，没有做不到。一门10学时的课竟然只有2学分。

1.2.5 学习和使用的新软件；

• 第一次结对设计学习使用了Axure
• UML设计使用了StarUML和ProcessOn
• 团队项目使用了Android Studio

1.2.6 学习和使用的新工具；

• 个人项目学习使用了性能探查器和单元测试工具

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

• 学习使用了Android开发

1.2.8 学习和掌握的新方法；

• 个人项目：学习了代码性能分析和单元测试，学习git使用
• 结对项目：学习了原型设计
• 团队项目：学习了前后端对接、uml图
• 贯穿整个软工实践：博客撰写

1.2.9 其他方面的提升。

• 成为了团队开发的一份子，提升了自己的合作能力和沟通能力

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

经验总结

在项目开发过程中，难免遇到之前接触过的知识，对于没接触的知识应该系统、认真的学习，单纯为了一时的解决困难往往导致之后翻倍难度的代码重构或是debug。

实例分析

在软工实践的团队合作中，我们主要遇到两种未知的知识：Android开发和团队协作编码。
起初团队成员划分任务后都只是为了贪图效率，只针对自己负责的部分进行学习，跳过了git等团队协作的利器进行单独编码。在alpha冲刺中期的时候弊端开始体现了：众人之间代码规范程度差，在各自部分完成后仍然耗费大量的时间却bug不断；加上因为对Android没有系统的认识，在对接时bug调试大家只能大眼瞪小眼，临时从头学习Android的大致框架。

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

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

建议：

1. 这门课很有趣，一定要选啊（貌似学弟学妹们的软工实践是必修了）
2. 认真对待这门课，真的有很多收获的
3. 写博客真的很耗时间
4. 有空就多学学项目相关技术，熬夜学习/赶进度还是很痛苦的
5. 感觉自己很累的时候就要多反思，是不是方法不对还是因为自己之前太划水

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

从个人体验来说，不要，不要，不要。

我觉得强制的换人是对大家都很不友好的做法。每个团队之间都是大家相互选择磨合的，且一个学期的开发周期也不长，在中途的时候，大家都已经过了最初的磨合期，开始熟悉自己团队的项目和合作方式，突然换人可能会打断大家的进度，让之前的努力某种意义上白费。或许对于能力特别强的团队或个人并不介意这种行为，但对大多数团队来说这都不会是一个好消息；同时，我不清楚强制性换人对软工来说意义何在，大家在原先团队能够一起用心的做出一个项目，我觉得已经很赞了。

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

个人决定8-9人是比较合适的，过少可能工作量过多，再多比较难避免个别人的划水现象。

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

我个人不是很确定此处规模指的是三者比例还是三者所占的工作量。
就这学期体验而言，我觉得目前的分配都蛮合适的。个人想法如下：

1. 三者中我觉得对个人能力提升最多的是个人项目（可能是我之前太菜了，STL都不会用），但团队项目确实需要现在这些时间才能够完成（也可能是因为大三上计算机课太多了，下学期听说课改了？）
2. 在个人作业后我其实还是很期待结对作业的，但实际效果感觉不是很理想。我认为这学期所布置的结对项目两人间任务分配比较困难，没有特别体会到特别好的合作感，但是两次双人合作的体验我觉得还是必要的

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

其实和合作过的同学都满感谢的，毕竟在软工实践都抬了我一手。硬要选一个的话应该是我的pm胡绪佩小同学吧。毕竟pm真的蛮累的，需要每次需要认真的分工（和充当催促干活的工头），特别是他还参与了前端开发。

对绪佩同学说的话：
你qq中特别爱发的那个草泥马走走走的表情总是让我脑补到它“嚼嚼嚼”的脸部特写画面。（我也不知道为什么会脑补出这个）

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）

我认为我所在团队经历了萌芽阶段、磨合阶段，当前正处于规范阶段。
看一下《构建之法》中关于规范阶段的定义：

1. 团队的工作流程和工作的方式得到大家的认可。成员之间互相更加了解，欣赏各自能力和经验，工作中相互支持。-- 没错就是我们团队
2. 领导主要扮演促成者和鼓励者的角色，有能力的成员也分担了一定的领导职责，并自然的获得大家的尊重。 --我想在目前班上绝大多数团队都能做到，我们团队也不例外
3. 随着项目的开展，一些成文的或不成文的规则逐步建立起来了。 -- 定时开会、详细会议记录，我们团队已经开始逐步建立规则了
4. 作为一个整体，团队要做什么、不做什么，都更加明确。团队的信心更足，和其他团队打交道更有底气。 -- 每次答辩成绩都在前列，我们有自信

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

在此主要侧重通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件这一点。
以下分为两点进行证明。

1. 我们团队对任务有明确的分工和良好的团队合作，且在预期时间内发布

此处贴出节选自我们团队Beta 冲刺（5/7）这一博客的燃尽图及Github签入记录进行证明：
燃尽图：


Github签入记录：

显然，我们团队对任务有明确的分工和良好的团队合作，且能够保证在预期时间内发布 。

2. 我们团队足够优秀，能够发布足够好的软件

此处贴出目前所有已有的评分条形统计图图进行证明，我们团队评分均为第一：

以上叙述均可说明，我以及我的团队，已对软件工程实践这一门课交出一份优秀的答卷。

转载于:https://www.cnblogs.com/Bylight/p/10227318.html