软工网络15个人作业5——软件工程总结
一、请回望开学时的第一次作业，你对于软件工程课程的想象
1.对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
刚开始学习这门课程并不知道这门课到底是什么，书中对软件工程的定义是：“软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护的过程”
看了之后反而更让我迷茫。想了想决定不在理论上锱铢必较了，还是在实践中慢慢领悟吧。
-
达到的目标：
①学习技能上熟悉了一门新的语言——python。Python是当下非常热门的一种编程语言，未学习之前并不了解它的优势，我们组后端开发用的是python，让我明显感受到了python的开发效率高等性能优势。现在流行的AI人工智能技术大部分都是用Python语言编写的，这大大促进了的Python语言的发展。总之，学习python是很有用的。
②对团队合作有了更深层的认识，以前以为团队合作就仅仅是大家取长补短共同协作。经过一学期的团队合作我才发现之前对它认识远远不够。（我会在后面团队合作的领悟中详细说明）
-
不足：
①团队合作中会出现很多的问题，大家的理想是构建一栋“豪宅”，但是时间的有限外加bug的频频出现真的让我们头疼，如何在有限的时间如何划分功能实现的优先级，合理安排，这是值得思考的。
②没有合理的预估时间，总是理想很丰满，现实很骨感，开发人员写出了看似完美的代码，但是实际真正测试起来却错误连连，原本以为的流程是“完成代码->顺利完成测试->发布”，实际上是“完成代码-测试代码->出现问题->修改->测试->出现问题……”。导致后来多花费了几天时间来调整。
2.总结这门课程的实践总结和给你带来的提升，包括以下内容：
1）统计一下，你在这门课程中，完成了多少行的代码；
没有计算过，我是做测试部分的，一开始是写各种单元测试、效能测试。后来觉得这种测试开发人员来做会比较好。所以后来我就做功能性和非功能性测试，比如压力测试、负载测试、安全性测试等等。
2）软工的各次作业分别花了多少时间？（做一个列表）
| 各次作业 | 所花时间 |
|---|---|
| 个人阅读作业1 | 3h |
| 结对编程练习 | 7.8h |
| 个人阅读作业——提问题 | 5h |
| 团队作业1——团队组队&展示 | 2h |
| 个人作业3——案例分析 | 4h |
| 团队作业2——团队计划 | 3h |
| 团队作业3——需求分析与设计 | 3h |
| 软工网络15Alpha阶段敏捷冲刺 | 60h |
| 团队作业5——测试与发布 | 4h |
| 团队作业6——展示博客 | 4h |
| alpha阶段项目复审 | 1.5h |
| 团队作业7——alpha阶段之事后诸葛亮分析 | 2h |
| 个人作业4——alpha阶段个人总结 | 4h |
| 团队作业8——敏捷冲刺（Beta阶段） | 50h |
| 团队作业9——项目验收与总结 | 3h |
| beta版验收互评 | 2h |
| 个人作业5——软工个人总结 | 4h |
3）哪一次作业让你印象最深刻？为什么？
我觉得有两次。
第一次是在第二次个人作业，作业要求我们去提问题。中国学生最擅长的就是总结归纳，最不擅长的就是提问质疑，所以让人很头疼。所以只能在书中找自认为理论的“漏洞”下手。
第二次就是beta版验收互评。我觉得我在验收的时候拉了很多仇恨，我很仔细的测试了每个小组的成果，找出了很多问题（虽然大家已经很不错了），有些小组在Alpha阶段未完成的东西在beta阶段全部改善，甚至做的几乎完美。通过互评，可以学习其他小组的长处同时小心会发生和他们相同的错误
4）累计花了多少个小时在软工上？平均每周花多少个小时？
根据表格统计是162.3h，平均每周11.6小时
5）学习和使用的新软件；
python用vs（不算新软件……），单元测试也在VS上做，测试性能用coolaf1.2.2接口在线压力测试。
6）学习和使用的新工具；
- 代码仓库管理工具：GitHub
- coolaf1.2.2
- 微信自带的性能测试、压力测试工具
7）学习和掌握的新语言、新平台；
微信小程序平台
8）学习和掌握的新方法；
功能型的、非功能型的各种测试方法（单元测试、效能测试、压力测试、负载测试、安全性测试、可用性测试）
9）其他方面的提升。
对团队合作有一些领悟。不恰当的团队合作会比个人还浪费时间，好的合作能够让每个人发挥适当的作用，会大大提高效率。在团队里要相互协作、按时交付等等
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
何为“人月”。我们所有的进度都是以 人月 代码产量来衡量的. 而增加"人"并不能缩短"月"的量.
-
首先, 不要低估任何一个产品的难度,我们一开始在Alpha阶段计划一天完成一个点, 但是后来还是出现了很多问题拖慢了进度。
-
在按时交付的基础上多做一些。可很能在任意时刻发生问题, 为什么不提前多干点呢? 虽然很少有人愿意这样. 但是我们的经验是一定要提前多干。我们团队的冲刺阶段早早就开始了，就是怕最后会出现问题，但是不幸的是最后还是出现超级多问题。所以我们不得不停下来想要增加的项目，去修复错误。
-
有着好的程序员可能效率比糟糕程序员高10倍的可能性.大家都懂……
-
交流是很重要的，遇到解决不了的难题大家一起讨论，从他们的言论中获取不同的观点，可以换一种思维思考。经常一个开发人员遇到了不可解决的问题，大家讨论之后会商量出另一个对策。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。对于换人机制，有什么样的建议？
-
老学姐对大一新人的建议：你总以为有时间，这就是问题所在。当我们说“我好想要这个”的时候，我们通常少讲了几个字，我们的意思是“我好想要什么都不做，就得到了这个”对此，我对学习的建议是：
跟同伴一起学习，讨论能减少偏差
一开始可能觉得编程很难，可以把大事化成小步骤完成（但是可能会有分心的危险）
自学是有必要的
反拖延技巧——做什么都需要一个理由 -
对于换人机制：
理想的目的是激发队员的动力，但是并未达到预期的效果。大家都是把最差的那一位成员丢掉，最后结果就是，各队最差的成员互相换，无论怎么交换都对团队没有影响。老师所提到的“跳槽”是绝对不存在的，一个团队的主力怎么会走呢？去了别的组又要接替主力工作是很麻烦的。所以换人机制意义不大。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
团队合作的几个阶段：
-
萌芽阶段：有些队友是新认识的。所以不怎么交流。交流都是通过第三个人。
-
磨合阶段：每一次开会都是经历磨合阶段.大家肩负起各自的责任。
-
规范阶段：到了冲刺阶段就是真正的规范了。大家每天都有大量的交互。每天讨论今天完成了什么，遇到的问题，如何解决，以及确认是否调整计划。
-
创造阶段：未实现
五、怎样证明你学会了软件工程？
-
研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件用户访问量
小程序的二维码：
公众号的二维码：
-
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
需求分析：https://www.cnblogs.com/Team-Blog/p/8783845.html
Alpha阶段博客：https://www.cnblogs.com/Team-Blog/p/8869481.html
-
并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
