福大软工 · 最终作业 - 软件工程实践总结（个人）
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
软工实践对我而言是一项全新的挑战，因为我在编码方面有许多薄弱的地方，从前又没有过如此正经的团队合作的经历，更不用提开发一个项目了。回想我当时在开篇博客上所写的“我想学点厉害的东西，加强自己的实践经验，要用一些有挑战性的东西来逼迫自己去学习。因为还有任务没完成，时间又紧迫，我自然就会想着学习。”，现在看来，厉害的东西学到了不少，各种开发工具；实践经验也有了，一起做团队项目。我想，唯一的遗憾就是最后团队项目没有成功完成吧。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
据目测估计法，在2000行到3000行左右吧。
2、软工实践的各次作业分别花了多少时间？（做一个列表）
我并没有刻意地去统计时间，以下是我根据过去的作业博客加上自己的猜测与感觉估算出的大概时间：
| 作业 | 耗时（h） |
|---|---|
| 准备 | 3 |
| 个人项目 | 30 |
| 结对项目1 | 17 |
| 团队展示 | 2 |
| 结对作业2 | 23 |
| 团队选题报告 | 2 |
| 需求分析报告 | 6 |
| 课堂实战- 项目UML设计（团队） | 6 |
| 团队现场编程实战（抽奖系统） | 7 |
| Alpha 冲刺 | 70 |
| 项目测评（团队） | 3 |
| Alpha 事后诸葛亮（团队） | 3 |
| BETA 版冲刺前准备（团队） | 1 |
| Beta 冲刺 | 70 |
| Beta答辩总结 | 2 |
3、哪一次作业让你印象最深刻？为什么？
Beta冲刺的印象最为深刻。因为Alpha冲刺时想着一些东西放在Beta冲刺里去完成吧，结果越积东西就越多，导致Beta冲刺差不多就是日常熬夜的状态，熬夜到2点与接近5点不等，还好第二天早上翘课没有被老师抓到，尽管Beta冲刺时间上比Alpha冲刺短，但实际做的东西似乎并不少于Alpha冲刺，这同时又大大加强了我的夜间学习能力（笑着活下去.jpg）。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
根据学习进度条显示，是总共花了353小时在软工实践上，平均每周花了22小时。
然而，我在开篇博客里是这么写的：
我对时间把握的不好，我想为了这门课平均每天一两个小时还是可以的吧。不过具体如何还得看实际情况，只能说这门课的优先级应该会靠前。
当时的我以为每周只要10小时左右，现在看来，当时的我未免过于年轻。
5、学习和使用的新软件；
- Axure up
- StarUML
- eclipse
- Android Studio
- Visual Studio
- 八爪鱼采集器
6、学习和使用的新工具；
- Axure up
- ProcessOn
- StarUML
- eclipse
- Android Studio
- Visual Studio
- github
- 八爪鱼采集器
7、学习和掌握的新语言、新平台；
- Java
- Android Studio
- Visual Studio
- eclipse
8、学习和掌握的新方法；
- Android Studio各种奇怪的配置
- 单元测试
- 前后端大致对接
- UML的设计
- 原型设计
欺骗之法
9、其他方面的提升。
- 软件开发的艺术
- 团队配合的艺术
- 熬夜的艺术
- 在痛苦中苟延残喘的艺术
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
团队方面，正所谓“一个和尚挑水喝,两个和尚抬水喝,三个和尚没水喝”，一个团队一定要在一开始便明确这个项目要做什么，有哪些工作要做，要对工作进行细分，一开始便分工明确，然后每个人各自有负责的部分，这才能有效避免浑水摸鱼情况的出现，也避免了到后期才又要再分配新的任务使得大家节奏混乱。比如我们团队的一些工作没有实在地分配到某一个人，导致了类似A与B都觉得这些工作是对方做的，结果大家都没做，只能重新分配任务，间接导致了项目的不能及时交付；其次，团队开发的过程要落到实处，每个人的当前进度要及时如实汇报，不可一直不报进度，更不要因为自己的进度较别人慢而虚报进度，要知道一个团队重在配合，一定要做好沟通。由于我们团队相对而言缺乏沟通，前后端各自都做的很辛苦，但并不知道对方的进度如何，不知道对方做了什么，导致了后期对接产生了不少困难，甚至推翻一些东西重做，直接导致了项目的不能及时完成。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：
1）你有什么想建议、告知和期许想要告诉他们呢？
首先一定一定一定要强调的是，软工实践看似2学分，其实要做的事情甚至超过了10学分，除非你已经做好了面对暴风雨的准备，是真真正正地想要学一点东西，否则你千万不要报这门课。当你报了这门课，你便会发现你的娱乐时间、其他科目的学习时间，有很多时间都会被这门软工实践夺走。这门课就是这么可怕，不过它确实可以学到很多东西，学到很多其他课上没有机会学到的东西。不要简单地以为只是可以学到不少软件开发的知识，其实还可以学到不少的编写文档、展示作品、与人沟通、推广宣传、答辩质疑的艺术。最后是针对团队项目的建议，一定要第一时间抱紧大腿，一个团队最好不要每个人都是新手菜鸟，如果这样的话那么很难做出一个成功的好的项目。
2）特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？假设依旧是一个90+人数的大班
我觉得不要强制换队员，但可以自己选择换到其他队。因为一个团队能够成为一个团队，一般来说这些人是比较熟的，比较能配合地起来的，如果一个人强制换到另一个陌生的团队未免过于残忍，可能到了新的环境由于不熟悉新的项目，跟其他人也一下子沟通不来，这个人什么忙都帮不上，或者是总是被分配到一些无关紧要的任务而评分很低，甚至被当成外来者受到排挤，体验未免太差。但是自己主动换队则另当别论，这可以很好地模拟实际工作中的跳槽行为。
3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？
考虑到大班，我觉得还是维持现状最合适，保持在10个组左右，毕竟每次答辩每个组都是需要时间的，而根据这学期我们的情况，差不多都是答辩到饭点恰好结束，如果队伍太多则答辩不完，或者答辩的质量难以保证；队伍太少则每组人数过多，显然不妥。
4）个人/结对/团队作业应该控制在怎样的规模？
我觉得当前的作业量是偏多的，毕竟仅仅只是2学分的课程。不过既然是一门不一般的课程，这个作业量却又是合适的，整套作业做下来真的可以让人领悟到软件工程的精髓，学到很多东西。
5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？
感谢一下自己吧。遇到许许多多困难无数次想要退选，想要逃避，比如因为某个技术难题卡死一直得不到解决而感到绝望，亦或是在软工实践开发过程中恰逢其他某个科目的期末考试而难以在两者之间作出权衡，每每感到头痛却又总是奇迹般的坚持下来，最终收获颇丰。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
我们的团队应该尚还处于磨合阶段，因为沟通还做的不够，也并没有使用github等工具那样那么规范，没有规范的文档，基本是各做各的，最后口头汇报成果进行交流。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
4）对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。
请在随笔中用数据证明上述内容或侧重选择之一。
我选择第4点进行回答。
有很多问题真的是一下子还答不出好的答案，甚至有的问题因为啥都不会而愧于回答，我要学习的东西还有很多，我会对照表格里的问题去学习更多的知识与技术。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
参考论文文献：
[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
七、个性发挥，包括图文、照片和创意等
