一、请回望第一次作业，你对于软件工程课程的想象
对比开篇博客你对课程目标和期待，达到了你的哪些期待和目标。
我当时的期待更倾向于学习一些更为专业的团队开发策略和了解究竟优势是什么，而不只是将以前自己实践过的，耗费过大量时间做过的再重复一遍。要说这也是增加竞争力的一种吧，倒是这次软工做下来，真的是心累。前面废话很多，想看轻松的跳最后。
总结这门课程的实践总结和给你带来的提升
统计一下，你在这门软件工程实践中，完成了多少行的代码
10K左右
软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 耗时 |
|---|---|
| 第一次博客作业 | 0.75h |
| 第一次个人编程 | 16h |
| 第一次团队展示 | 0.5h |
| 第一次结对编程作业 | 13h |
| 团队项目-选题报告 | 5h |
| 第二次结对编程作业 | 50h |
| 团队项目-需求分析报告 | 4h |
| 团队git现场编程实战 | 4h |
| Alpha | 40h |
| Beta | 60h |
| 最终展示 | 90h |
| 总计 | 283.25 |
哪一次作业让你印象最深刻？为什么？
最深刻的有两次，结对编程和现场编程，前者让我做了一件以前基本不会去做的事情，做设计写前端，后者则是3小时做个东西出来，体验较差。
累计花了多少个小时在软工实践上？平均每周花多少个小时？
有一说一，整个学期行程紧张，严格统计时间这件事情就不是一件合理的诉求，时间一点一滴的去挤压，再去摆个时钟做个番茄时钟？每周多少时间？差不多只要有空应该都在软工吧，12-14小时？
学习和使用的新软件
基本没有，原型设计工具可能算吧，不过感觉直接用以前惯用的adobe全家桶做设计工具也没啥不可，不过考虑效率还是可以做点有意义的尝试。
学习和掌握的新语言，新平台
新语言的话，kotlin（都是永福的选择，多学点也挺好的），Android算是新学的？其实以前也有简单接触过。
学习和掌握的新方法
- 吹牛逼，画大饼
- 画uml图
- 做前端做美工（报警了，也许算不上新方法）
其他方面的提升
增进了友谊，丰富了全栈的技术，多了一些经验，但是花了这么多时间，却感觉不如做一个外包工程或者比赛项目提升的多，心里又有点过意不去，这种纠结也挺难受的。又不想花时间，又不忍心放下。
写下属于自己的人月神话
1.开发前做好功课，对于想要实现的内容和计划采用的工具，要搜集好文档以及相关合适的实例，避免使用过时的内容或者过期的文档，造成一些不必要的麻烦和强迫症问题。
2.了解基础才能强化纠错和解决问题的能力，这点和软工没啥关系，很多时候常常遇到编译乃至安装的问题，看那些奇怪的黑框框的error就容易去瞎找解决方法，然而有时候学会读这些信息，也是应该具备的能力。
3.尽量保存可重复利用的代码，做好解耦，避免各种相同模块复制黏贴这种操作。
最想感谢的人
要说感谢，还是感谢永福吧，毕竟在他的带领下，有时候不自觉的想要当个咸鱼。
个性发挥
思考与吐槽
累了，不想动了，还要考试呢。
首先，我只是一个菜鸟，以下是作为一个经历完课程的人的思考与吐槽。
很早就听说过软工实践这门课的麻烦，虽然说貌似是一个提升自己时间能力，学习新知识的好途径，但是这门课作为必修真的适合所有人吗。首先，这门课开放在大三，那些希望通过实践来提升自己能力的，在大一大二的阶段已经花了不少时间在提升自我，进行额外学习上了。对于这些人，这门实践课的性价比可能就比较低了，而且常常为了团队也不能针对自己真正想要补全或者尝试的方面进行工作与学习。而对于那些想学想实践却不知如何下手的有选择的意义，不过对于这方面同学的指引又显得非常的薄弱。而对于那些混的，不想做的，再怎么逼也是无用的。不过这些不想学并不一定是能力问题，也有可能是时间问题乃至需求问题，虽然技多不压身是个理，身边就有因为觉得自己不需要而且时间不充裕而选择不学的同学。所以像是这样自由度如此之高的团队实践课，必修真的是明智的吗？
再说课程本身时间安排的问题，众所周知，学生在上这门课的同时还有许多其他的课程需要兼顾，所以作为一个团队，很多时候大家的时间并不能重合，并且不能够模仿那些职业团队去执行计划，对于其中的很多过程是能省略就省略，想想也是无奈。反而没有闲暇去思考为什么这么做，为什么不这么做。反而做这些的时候自己显得是那么滑稽，看似条理清晰，往往都是空壳。而且如果希望有所谓大佬来带，来指导学习，但碍于时间往往大佬们更希望自己动手解决。更多的时候还是更考验自己的自学能力。而且我们k班延长了实践时间，依然很多诸如测试之类的工作无法有效的完成，甚是可惜。
这也引申出了组队的问题，我是比较赞成永福对于这方面的吐槽的，在时间紧张的环境下，团队的作用往往只是1+1=2而难以做到1+1>2，而且任务分布的越散，有时候反而完成的效率会越低。不仅在于队长的管理调度，也在于对团队成员的能力和所擅长方面的评估是未知的。而这个往往很致命，也很消磨热情。
我也看到很多人吐槽助教的作用，其实作为实验班的学生，在之前的某些课程上体验过其他类型的助教方式，这门课确实在淡化助教，使得助教的作用只是发布作业，收集作业，收集数据统计数据。而选择让评分的工作落在大家的身上，这也造就的大家的分数不再那么客观，毕竟大家也都利益相关，也难以针对每次作业而查找自己的不足和缺陷，都是那么的敷衍。我们既充当开发者又充当客户，使得在评判的时候显得专业又业余，是那么不伦不类，又难以有说服力。因为班级人数的问题，老师可能无法全部顾及，那么就更需要助教来帮助做出评判，而不是大家一起瞎捞鱼。
当然，这门课的初衷肯定是好的，但是在实行的过程中也有不少有趣的经历，但是上完之后还是满满的疲惫。其实对于永福所提到To C or To B的问题，也有思考过，就相当于一些技术比赛的创新选题和企业选题一样，而我个人在选择创新选题，所花在选题上的时间常常是以月为单位，并且常常是以往的一些自己已经研究或者尝试过的成果进行二次创新，我赞成永福对于这门课增加To B选题的建议，作为新手，去阅读思考别人的需求并且将其转化为产品，并非易事。目标明确，更可以在有限的时间内，更多的尝试软工实践的内容。
不过长时间的码代码还是有点庆幸的，至少自己抑制住了想划水的想法，一点一点的和队长构筑长城还是值得回忆的。期望未来这门课能够成为一门牌面。
有意思的内容
其实整个软工做下来，其实最有意思的反而是结对作业，选择的题目非常有心意，而选择的测试形式也是非常有意思，对抗就是最直接的竞争，让人有种想要参与，迫切参与的快感，不知道快感这个词用的合不合适，而且选择在作业中加入那些工程知识的实践，还是有所获益的。
不过最后打牌输了，倒是蛮难受的，四个人蹲在门口吹冷风打完的，没留下一些照片倒是真的可惜。
不过结对编程这个形式我以往没有尝试过，不是个人单干，就是团队合作，但是只要自己的另一半（误会性说法），你熟悉且了解，有时候真的是一件很奇妙的事情，无论是两人敲代码还是一人敲一人骂，都是一件蛮有效率的事情。两人互相不对眼，换换工作内容照样可以运转，不得不说，合情合理，自学三天写前端，要不是对另一半的美术水平不放心，真没这爆肝的能力，倒是自己牌没打赢，ai打牌也跪了，让另一半想想咋办，咋回事啊，这纯粹人工智障啊，“我也没法啊”，“就这样啦”，“我再训一训”。这不就整活嘛。不过把我两的工作换一换可能结果会更加刺激吧，感谢感谢，谢谢不演之恩。