一、回望与总结
回望
Q ：对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足？
A ：收获：体验了一把写android后端的感觉，虽然偶尔还会因为没理解后端需要做的事务而对组长的需求感到困惑，渐渐明晰了后端的模式。
不足：在写总结写说明书写博客的时候，每次都觉得很辛苦想拖着啊（编码一小时博客两小时。没有点亮展示、作报告这方面的技能（一次好的报告真的很加分。
总结
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
Sudoku : 150
结对编程 ：800
XMatch : 1300
2、软工实践的各次作业分别花了多少时间？
| 任务 | 耗时 |
|---|---|
| 课前畅想 | 2 |
| 数独 | 21 |
| 结对作业 - 原型设计 | 3 |
| 结对作业 编程 | 20 |
| 团队前期工作 | 5 |
| Alpha冲刺阶段 | 30 |
| Beta冲刺阶段 | 15 |
| 软件云评测 | 8 |
| 课程总结 | 4 |
| 总计 | 108h |
3、哪一次作业让你印象最深刻？为什么？
结对编程。结对编程作业完成时期为国庆小长假，然鹅恰逢集训，分身乏术。加上我一开始低估了这次作业的难度，认为留下一天对付妥妥的（哈哈。与对友确认好前期的设计工作，编码确实挺迅速完成了，嗯，我觉得理论AC，然鹅因为对类的传参等不熟悉，造成我想象中应该发生的动作都没完成。当时已经离截止时间仅仅几小时了，急速冲锋，多亏了对友有这方面的经验，最后算是有惊无险勉强过河吧，跑出了结果而且我粗略一看对的上（太天真了。当我几天后想起这次作业未测试结果，写test代码对跑出的结果进行验证时，我受到了惊吓，运行结果显然是有问题的，似乎修改了一两行代码后改善完成，真怕被对友打死啊（TAT。
算是今年软工中遇到的比较惊险的情况，事后反思，做事一定要留有余地不要让自己陷入手忙脚乱被催催催的地步（但是我的总结博客还是拖到了现在啊。项目不像做题可以有明确的判断结果返还，应该好好做测试工作。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
120+h。前期几次小作业的话基本是一两天内完成，后期团队项目进行冲刺时每晚至少保证两小时团队齐聚工作室共同编码，平均每周12h。
5、学习和使用的新软件/工具
作业部落 目前最常用的markdown编辑器，简洁方便强大。
墨刀 原型设计工具，网页版也可使用。
IDEA 全称IntelliJ IDEA，java开发工具，我觉得很棒棒啊。
apizza 只使用了其中的测试接口部分。
6、学习和掌握的新语言、新平台
在java语言的基础上体验了一些框架的使用如springboot。
7、其他方面的提升。
经历了一个小项目的流程，经历了需求探讨、设计、说明书编写、原型设计、编码等过程，对开发有了更具体的了解。以及被深深嫌弃的美工
二、属于我们的人月神话
个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
XMatch团队中有两位灵魂人物，组长CoderQiang以及PM xiangChen 。CoderQiang首先奠定了编码的格调，把控团队项目进度以及每日工作发布，大大提高了组员的效率，少做无用功。团队冲刺期间队内有多位同学陆续外出比赛，正是因为团队的工作是落实到当天完成的，减少了因成员外出而发生的项目进展受到阻碍、因依赖于某位成员的工作未完成而打乱后期工作安排。
PM 关注、协调项目的进展，按要求完成博客的编写，实时总结与预期，带动了团队的发展。
事实告诉我们，团队中最重要的并不是那几颗勤勤恳恳的螺丝钉，而是把控全局的人。一个好的leader能更好发挥组员的力量，指导团队走得更稳更好。
三、一些建议
对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
对学弟学妹们：虽然你可能会体验到舍友因为没有软工实践而每天幸福的呼呼大睡！你在写软工实践而舍友在浪！软工实践还是可是体验一下的，只上理论课是体会不到开发的有意思的。
对开学初的我：你知道后来的你拔了几颗智齿吗
对大一的我：别熬夜别熬夜别熬夜，护发护发护发。
至于中途换队员：因为软工实践碰上了各种各样的考试啊等等问题忙的焦头烂额，我们一开始对换队员挺反对的，因为在本来就很少的时间里还要付出额外的代价，如果更换前后所处的位置差别很大，那代价就更大，要配环境、教导入门，然后需要修改团队工作安排，想一想就觉得麻烦很多。这次的换队员似乎还在比较可以接受、代价小的范围内更换（没什么怨言，希望学弟学妹们可以加大challenge，好好玩，比如PM出走啊，前端后端交换啊（看热闹脸。换换换，必须得换。
四、分析团队
软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
| 阶段 | 完成度 |
|---|---|
| 萌芽阶段 | √ |
| 磨合阶段 | √ |
| 规范阶段 | √ |
| 创造阶段 | √ |
整个团队算是走的平平稳稳，磨合地较好，前期组长就早早制定下规范，中途并没有因为规范产生过分歧。
五、怎样证明你学会了软件工程？
研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
目前软件已经发布测试，主要用户群体是福州大学广播台的一个小支队，用户数目在15人左右。
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
我们团队的需求较为明确，最终交付的版本基本实现前期需求规格书中提到的功能。团队持续平稳运作，多人github稳定提交代码。
总体commits
个人commit情况
