一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
- 回顾第一次作业，那时候我很纠结的，因为实验班的软工实践是必修课，然后自己学业任务和学生工作任务都很重，但是，我还是都报名了。以至那阶段真的是忙到想吐血。对软工的印象也一直下降，甚至还会吐槽说怎么又是写文档，太可怕了。
- 现在对软工的印象，或者说反思吧，我自己得到了什么，好像不仅仅是学分这么简单的事情，但是我又说不出所以然。代码量因为自己的没有参与编程，并没有得到多大的训练，立下的flag要看完《Java编程思想》也没有实现，寒假有时间要把这个flag补回来。
- 我对软件开发的过程有了具体的了解，不仅仅是实践课，理论课也学到了很多。我在我们小组的任务是扮演PM的角色，以前我觉得项目领导者也不过如此，但是自己亲身经历才会发觉压力很大，因为自己没有任何经验。这段经历然我想起了大一那时候刚刚进来大学，没有任何经验，还去勇敢地竞选班长，最后成功，并且把班级带得不错的历史。哈哈哈哈哈哈
- 不足的话，就是我的代码能力吧，还是很菜。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
- 1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
- 上GitHub看了看：752行代码
- 此次的软工项目，我并没有参与编程，除了个人和结队还有那时候的课堂小开发（校友录）这些我有参与编程之外，其他方面我的参与度并没有那么高。
- 2、软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 时间（分钟） |
|---|---|
| 第一次作业--准备篇 | 120 |
| 第二次作业——个人项目实战 | 750 |
| 原型设计（结对第一次） | 350 |
| 结对第2次作业——WordCount进阶需求 | 1025 |
| 团队展示（团队） | 300 |
| 项目选题报告（团队） | 1800 |
| 项目需求分析（团队） | 600 |
| 团队作业,随堂小测——校友录 | 600 |
| 个人作业——软件产品案例分析 | 300 |
| 合计 | 5845 |
alpha冲刺和beta冲刺不知道怎么统计，就不填进去了。虽然没有参与代码开发，但是其他方面的任务，我自认为还是不错的。
- 3、哪一次作业让你印象最深刻？为什么？
- 非要说印象最深刻的是什么的话，就是选题了，那时候确定了选题，然后以为选题报告，答辩什么都是队长做的，然后那时候我通宵了两个晚上，做选题报告和PPT。以至那时候第二天答辩差点晕倒（虽然没人知道），后来修改报告和ppt是和队友一起修改的。
- 第二深刻的是需求分析，这回的分析报告是大家平均分配的，然后到了前一天要整合的时候，有人因为不可逆原因，没办法写好，提交的过于简陋，然后自己又在那里熬夜修改，突发情况的处理真的很伤身体。
- 还有那次校友录，我负责最后的整合，然后在最后那里我上传自己的代码的时候，一直失败，一气之下，-f强制push，结果把队友的代码全部弄丢了。很是懊悔。
- 4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 认真去估算了一下，总共花费的时间141.4小时，按照课表是03-14周有课，大概每周是花费11.8个小时。
- 5、学习和使用的新软件；
- 墨刀，eclipse（特别是那时候校友录我整合代码的时候，崩溃），VS。
- 6、学习和使用的新工具；
- Java语言，eclipse，GitHub
- 7、学习和掌握的新语言、新平台；
- Java
- 8、学习和掌握的新方法；
- VS的调试，单元测试，利用vs来进行性能分析，还有Java的自动补全我一直没搞好。
- 9、其他方面的提升。
- 和别人的合作能力，以及照顾团队人员的情绪吧。还有百度很有用，Google我还不是很清楚。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
-
个人作业的经验教训
自己不懂的地方可以去百度，或者翻找博客，然后找到解决办法，但是如果解决办法没用的话可以找同学寻找帮助，比较不会浪费时间，但是一定先自己尝试解决问题。还有助教和老师其实也是一种很好的资源，但是我没意识到。
实例：那是个人第一次的作业是统计单词数。最坑的就是一开始理解错了题意，写错了代码。然后和同学交流后发现自己的错误后，再进行改正。后来因为自己代码不熟练，一个多层嵌套循环自己判断错了，导致了自己代码运行结果不对，就那一次是两个同学帮我找到的bug，我们先是交流问题的思路，然后那次我学会了调试。 -
结对的经验教训
结对的作业就是代码会分开，然后千万要保证两个人用的环境是否一样，否者有可能会报错...惨痛。 -
团队的经验教训
- 团队的话，最好是一开始就加入编程，这样子既可以帮助整个团队，后续也知道什么代码表示什么，在哪个位置。我一开始没有参与，再beta阶段想参与，但是很难融入。
- 注释很重要，就是因为没有注释的原因，所以很难融入项目的开发。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
- 选题不要太自信，我们团队就是选题工程量过大，然后有一些技术上的问题一直无法实现，比如地图路线的缩略图生成。
- 在自己选完这门课后，最好暑假就学习一些开发工具和语言，安卓Java之类的，会让后面事半功倍。
- 一定要找一个能理解所有人的话的人来当队长，不然有时候两个人沟通会很费劲。
- 写文档的任务是很烦人，但是大家一起配合的话，就简单多了。
- 要不要中途换队员：我觉得是可以换，但是中间的缓冲时间可以多给一些，或者说想想可以发什么任务给团队磨合一下。不然，真的很难帮到项目什么忙。（主要还是太菜了hhhhh）
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
分为四个阶段
- 萌芽阶段
这是最开始刚刚组队的时候，大家就一腔热血，说着自己喜欢什么想要做什么。一起吃顿饭，交流很多，但是很多不是关于项目的交流。 - 磨合阶段
在alpha阶段就是我们团队的磨合阶段，那时候项目开始，大家很有精力，努力学习新的工具和语言。但是就是因为对工具的不熟悉，导致我们团队在alpha冲刺的最后一天整合代码的时候，只能手工熬夜整合。 - 规范阶段
在beta阶段应该可以说稍微有点规范阶段的意思了，每个人的分工明确了，统一用协同这开发的模式，然后每天push和pull，到最后代码注释的添加。我们一直在路上。 - 创造阶段
创造阶段我们团队目前还有一定的距离。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
请在随笔中用数据证明上述内容或侧重选择之一。
- 侧重第二点
- 我们的团队通过GitHub编程，再alpha冲刺阶段确实做得比较不好，是通过熬夜人工整合代码，规划做的不好。以至GitHub提交记录很乱，在beta阶段我们进行了改进，这就是我们的进步。
- 我们有通过问卷调查，确定选题，需求分析，类图的运用，alpha/beta冲刺等阶段来完成我们的项目
- 有明确的分工（三人负责前端，二人负责后端，一人负责其他事务）
- 没有临时熬夜，是几乎每天熬夜。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
参考论文文献：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87
七、个性发挥，包括图文、照片和创意等
嗯，谈谈自己的感想吧，作为队长，自己的专业技术确实没有处于领先地位，能给的帮助会比较少。但是我觉得我做得最好的一点就是，我们做到每天组织大家开会，大家谈谈自己的问题，然后他们在交流过程中对方相互不理解，我能作为“翻译官”来解释，帮助他们。然后我有认识隔壁K班的一个PM，他做得比我好的地方是他有参与软件的编程，他属于代码能力比较强的一个人，那天我和他交流，他们团队也有不负责编程的人员，但是他属于那种哪里编程出问题，他就到哪里帮忙，哪里来不及了，就去打下手。我觉得他做得很不错，对比一下，我可能就比较low了。