一、回望过去，反思当下
1.1 对比现在的你和开学初博客开篇的课程目标和期待
当初的目标是希望能够掌握系统的软件开发流程，并且找到整个流程中自己的定位。而现在基本上算是了解了基本的开发流程，但是自己的定位还是不清晰。
1.2 总结这门课程的实践总结和给你带来的提升
1.2.1 在这门软件工程实践中，完成了多少行的代码
这个不太好数，~~因为大部分的代码都是学习过程中产生的 垃圾 代码。从学习进度表以及GitHub来看的话总和应该是在3000行左右，真正有用的行数应该是1500行作业。
1.2.2 软工实践的各次作业分别花了多少时间
| Task | Time |
|---|---|
| 2018软工实践第一次作业 | 50 |
| 2018软工实践第二次作业 | 835 |
| 软工之 NABCD 模型分析及 Web of Paper 原型设计结对作业 | 2310 |
| 福大软工1816 · 第四次作业 -火箭少男100 团队展示 | 100 |
| 软工之词频统计2.0-结对作业二 | 3785 |
| 2018软工实践——团队答辩 | 120 |
| 福大软工 · 第八次作业（课堂实战）- 项目UML设计（团队） | 240 |
| 福大软工 · 第七次作业 - 需求分析报告 | 840 |
| 福大软工1816 · 团队现场编程实战（抽奖系统） | 200 |
| Alpha冲刺系列 | 1135 |
| Beta冲刺系列 | 835 |
| Alpha现场答辩 | 120 |
| 福大软工 · 第十次作业 - 项目测评（团队） | 220 |
| Beta现场答辩 | 100 |
| 共计(/min) | 10890 |
1.2.3 让我印象最深刻的作业？为什么？
应该是第二次结对作业。从上面可以看到这是投入时间最多的一次作业，当然也是我个人认为做得最好的一次，也成为了我唯一的一次优秀作业。
1.2.4 累计花了多少个小时在软工实践上？平均每周花多少个小时？和开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答对比
累计181.5小时（有偏差，仅为粗略计算）。按18周来算，平均每周10.1个小时。开篇博客中我打算每周拿出10个小时。基本上符合持平。（对于一门2学分的课来说过于恐怖...）
1.2.5 学习和使用的新软件、新工具、新语言、新平台、新方法
VS2017、墨刀、GitHub、MarkDown、Photoshop、iSlide、Python、敏捷开发、Chrome插件 —— 新浪微博图床（强推！非常方便）...太多太多了
1.2.6 其他方面的提升
（1）学会了如何在多个优先级高且deadline都接近的任务之中发挥自己的潜力。
（2）还有就是柯老板理论课上的几张课件，记忆犹深，在这里也贴出来。(不知道柯老板介不介意，如果有所不妥，请联系我删除)
二、写下属于自己的人月神话
2.1 个人作业的经验总结
- 好的代码规范之于项目相当于地基之于房子，没有好的代码规范基本不可能对代码进行修改和维护，除非你的代码简单到可以一次性打完不出任何问题。
- 专业技术论坛是个好东西，例如StackOverflow，有些问题直接用搜索引擎未必能找到好的答案，但是在技术论坛上找到的答案的概率以及答案的质量都高一些。
- 为了更好的分数，写博客之前建议认真阅读作业要求，看不懂的地方积极问助教 （助教大大都很热心的~），而不是自己猜测。换个角度理解，相当于开发项目前要看清需求说明书，看不懂的地方积极与客户沟通。
- 多给自己正面的反馈，否则在重压之下你很快就崩溃了。
2.2 实例/例证的分析
- 在一开始写的时候，我还是凭兴趣爱咋写咋写，写完一运行，果然错了。这时开始改代码，看着我的代码我就陷入了沉思，我完全不知道我写的是什么东西..后来看了一些相关资料，有意识进行代码的规范，后来达到了别人看我的代码不用我介绍也可以理解。
三、悟已往之不谏，知来者之可追
3.1 给下一届的建议
下一届是必修课，逃不过的。既然不能反抗就尽情享受吧~~相信我，你要你有投入一定能有所收获！
3.2 要不要中途换队员？
我觉得这一届的这种形式挺好的，这种交换出去的队员不需要太过特别的技能，基本上每个人都掌握了，在技术上能够很好的融入其他组。但是将队员完全交换的形式我是不支持的，因为技术上不一定兼容。虽说软工讲究 learn by doing 但是学到一半再放弃去学习其他的技能会令人崩溃的。
3.3 一个组的人数应当在多少比较合适
我认为这个不是一个固定的数字能够回答的，还是要看具体小组选择开发什么项目。并且要设置一个和团队人数、项目难度挂钩的公平的分数算法。
3.4 个人/结对/团队作业应该控制在怎样的规模
我不知道规模该用什么来衡量，但是我觉得这次现场编程任务是有些过重了。如果一定要衡量的话我希望是一种投入时间有上限的类型的作业，而不是现在这种无论你投入多少都达不到完美的作业。
3.5 你最感谢的人是谁？有什么话想要对TA说呢？
最感谢董钧昊同学吧。每次感谢环节我总是要感谢他，因为他确实帮了我很多。
四、团队进化
4.1 萌芽
萌芽阶段可能是我们最自信的阶段了，不论从选题到分工，我们都快速决定了。可以说有些草率吧，后来也付出一些代价。另外这个阶段拍的视频非常的有意思，过程十分有意思。
4.2 磨合
这一阶段我们基本上能够按照分工各司其职，其乐融融。
4.3 规范
磨合之后本该进入规范阶段的我们遇到了一些问题，团队成员被其他事情压得喘不过气，进度一下慢了。
4.4 创造
我们最有创造的时刻应该就是每一次冲刺前的晚上了 :)
五、怎样证明你学会了软件工程？
5.1 研发出符合用户需求的软件
这一点蛮尴尬，限于服务器，我们的程序只能在测试机上运行...但是在我们团队三次在真实场景（永嘉天地）测试发现，效果挺好的（评价来自5位同行的非团队成员）
5.2 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
这一点还算好，按照作业的进度，我们每次展示总能发布拿得出手的产品。实地（永嘉天地）识别店铺招牌成功率可以达到80%，本地测试时能够 100% 识别成功，现场展示时也能识别出柯老板和同学们提供的刁钻的照片中的 50%。
5.3 通过数据展现软件是可以维护和继续发展的
我们有较为完善的技术文档，相信接下来不论是维护或者迭代新的功能都可以在这个基础上继续完善。
六、经典论文阅读
《Quantitative evaluation of software quality》阅读有感
附上文章地址（这篇文章看起来满满的怀旧风...）
简单的翻译一下摘要:
质量保证、软件质量、软件测量和评估质量指标、质量特性按目标管理软件标准、软件可靠性测试，本文报告的研究建立了一个概念框架和一些关键的初步结果在软件质量的特性分析。其主要结果和结论是：明确关注软件质量特性可以大大节省软件生命周期成本。当前的软件状态对我们自动和定量评估软件质量的能力施加了特定的限制。开发了明确定义的，良好分化的软件质量特性的确定层次。其高级结构反映了软件质量评估的实际用途;其较低级特性与可以执行的实际软件度量评估密切相关。已经针对其潜在益处，可量化性和易于自动化而定义，分类和评估了大量软件质量评价度量。已经确定特定的软件生命周期活动对软件质量具有显着的影响。最重要的是，我们认为本文中报告的研究首次提供了一个清晰，明确的框架，用于通过一致的和相互支持的定义
就像论文中所说的，软件的质量特性可以大大节省软件生命周期的成本，而软件质量的高低很大程度上取决于代码质量的高低，我们在进行Alpha 版本开发前，团队没有做详细的编码规范，后来我们意识到了这个问题，做出来改进。但是即使按照编码规范来进行开发，难免还是会有一些出入，代码质量不仅仅取决于编程人员的素质，也取决于团队合作中是否能够很好的制定编码规范以及是否能够很好的遵循规范进行开发。
一个好的接口具备稳定性、可扩展性，使用起来要简单方便效率高，所以对代码质量的要求其实是很高的，在 Beta 版本的开发中我们也有注意到这个问题，遇到一个问题就写一个接口的方式极大的增加来数据库的负担，而且接口也不够优雅，所以在接口的设计上需要细细琢磨，比如在设计上传照片接口的时候，可以设计成一个接口，通过请求的参数来判断照片的格式来进行不同的处理，返回不同的信息，这样的接口才更佳灵活，而不是写成两个接口。也就是软工理论课上提到的 ISP(接口分离原则）。
七、个性发挥
- 那就再贴一下我和我大哥的合照吧，感谢大哥，感谢柯老板，感谢助教，感谢一学期软工课上的每一个队友。 Learning By Doing ! Build To Win !
