软件工程实践总结（个人）
痛并快乐着——软件工程实践总结（个人）
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
一学期走来，感觉还是学了很多东西的。从刚开始听到打代码就头疼，到现在能够独立地完成一些有挑战性的个人作业，成就感还是满满的。虽然到现在我还是希望将来能够少写代码，但通过一学年的学习，我也知道，能少打代码意味着已经有了一定的代码基础。而且从事这一行业，不可能不打代码。因此，软工实践以来的苦逼和痛，或许会在将来成为意想不到的助力。
学到现在也有很多不足，比如当时希望能做出一个很耐看的界面，后面也只是草草了事。理想和现实的差距，往往体现在能力的不足和人的惰性身上，也希望以后能够精益求精，对任何事情都能交出完美的答卷。还有很不足的地方，就是到现在都没能习惯使用github，以及代码规范。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
| 作业序号 | 代码量 | 备注 |
|---|---|---|
| 1 | 300 | 个人作业-词频统计 |
| 2 | 200 | 第二次结对作业 |
| 3 | 1500 | Alpha冲刺阶段 |
| 4 | 100 | 团队作业-项目测评 |
| 5 | 300 | 团队现场编程-抽奖系统 |
| 6 | 1000 | Beta冲刺 |
| 总计 | 3400 |
2、软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业名称 | 耗时(h) | 做了啥 |
|---|---|---|
| 软工实践第一次作业 | 2 | 学了makedown格式，看看博客，写写博客 |
| 个人作业-词频统计 | 20.5 | 学习单元测试等新知识，复习c++，问同学， |
| 第三次作业-结对作业（原型设计） | 8 | 学习并使用Axure RP 8 |
| 第四次作业 - 团队展示 | 1 | 交博客，增加个人部分 |
| 第五次作业 - 结对作业2 | 16 | 用python爬数据，实现一些附加功能 |
| 第六次作业 - 团队答辩 | 0.5 | 交博客，增加个人部分 |
| 项目UML设计 | 5 | 学习ProcessOn、UML设计，绘制用例图 |
| 需求分析报告 | 10 | 用墨刀设计原型 |
| Alpha 冲刺 | 80 | 原型的重新设计，前端界面的设计，AR技术的研究，拍摄数据集，标数据集，做PPT，研究特效，详见各次冲刺学习进度条，写博客 |
| 团队现场编程实战（抽奖系统） | 7 | python学习和熟悉，聊天记录的分析和挖掘 |
| 项目测评（团队） | 6 | 上台答辩，做ppt，采访和测试部分工作 |
| Beta 冲刺 | 10 | 对前端界面进行优化，标数据集，拍数据集，参与PPT的制作 |
| 个人总结 | 4 | 写博客 |
| 总计 | 190 |
3、哪一次作业让你印象最深刻？为什么？
应该是第一次个人作业吧。那是我第一次接触到这么庞大的代码量，以及要学这么多的的新东西，单元测试，github的使用等等。这些都让我感觉头疼和不适应。而且不同于结队作业，我要一个人完成整个作业，其中不乏我非常不擅长的部分。虽然最后得分不高，但是我从中也收获了很多宝贵的经验，算是痛并快乐着吧。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 如果算上站立会议时间和课程答辩时间的话，大概在210小时吧
- 软工从开学第一周到十七周基本结束，共17周，平均210/17=12.3个小时
5、学习和使用的新软件；
- visual studio 2017 ：开发c++控制台程序，第一次个人作业使用
- Android studio 3.0.0 ：andoid开发基本工具，用来做界面
- Axure RP 8：原型设计
- Sublime Text 3：使用python爬网站数据
- PowerPoint：做ppt
- Typora：群里老哥推荐，用来makedown的工具
6、学习和使用的新工具；
- github：学了，但是并没有习惯运用
7、学习和掌握的新语言、新平台；
- java：从0开始，还好可以向身边同学学习
- python：爬爬数据，画画图，需要什么功能学什么
- github：download代码，用来学习
- Process On：一个在线画流程图/uml图等的平台，在需求分析阶段尤其好用
8、学习和掌握的新方法；
- 用例图：基于场景来考虑分析问题，更有助于我们了解需求
- 思维导图：用思维发散的理论，基本覆盖了要做的所有任务集，用图来表示清楚美观
9、其他方面的提升。
- 除了技术硬能力方面，和同学的团队合作也提高了我的团队协作能力和交际能力；
- 每次在deadline前肝博客提高了我的熬夜能力；
- 答辩和博客提高了我的沟通能力和瞎编能力；
- 碰到不会的部分提高了我的学习能力和抗打击能力......
- 学习这门课真是好处多多，学弟学妹们一定要选柯老师（划重点！）
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 第一次个人作业的时候，只有痛苦，没有快乐。那种直到deadline，却始终交不出东西的感觉，是很难受的。现在想来，失败的原因除了代码经验过少之外，对软工不够重视（其实很重视了，但是没想到还不够重视）是更主要的原因。没有付出足够的努力和时间，自然不能保证得到满意的结果。
- 结对作业的完成还是比较流畅的。因为我c打的不好，所以主体功能还是由队友完成的。我负责用爬虫爬数据，也学到了一些有用的技能。比较可惜的是最后程序似乎有点小bug，得分点并没有全部得满，还是有点可惜的。
- 团队作业过程中真的学到了很多，算是把软件工程理论课所学到的东西几乎都能付诸实践。不止是技术上的，还有答辩能力和团队协作能力。因此，假如你经得起软工实践的挑战的话，还是能从中受益颇多的。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
（1）对下一届学弟学妹们（和开学初的我）的建议和告知：**
我希望他们能学会合理分配自己的时间。软工实践的确是一门可以学到很多东西的课，但是同时也意味着占据了很多课余时间，如果不能妥善处理，那么很可能一事无成。我也希望他们能够做到我们这届做不到的东西，能够做出真正能面向市场的软件。
（2）特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？ 假设依旧是一个90+人数的大班
我认为可以有中途换队员的操作，但是没必要强制。因为有的人可能并不能适应这种被迫换队的操作，虽然在社会中可能会出现这样的情况，也的确有锻炼的效果。但倘若因为这种原因而完成不了软工实践（下学期他们还是必修）的话，这就是一件很尴尬的事情了。
（3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？
8-10人吧，我觉得按这学期的人数划分就很合理了。真的想完成一个比较完善的软件，4-5人是远远不够的。
（4）个人/结对/团队作业应该控制在怎样的规模？
软工真是个神奇的存在。在做作业的过程渴望作业少点，但到了现在又觉得这些作业量是合理的，也的确能够锻炼人。但还是希望能够尽量给学生足够的自主性，不要过分影响大学的其它精彩的组成部分。
（5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？
喜源同学，我的结队队友和团队队友。到了计算机以来，很多实践基本都是和他组队，而且说实话，他带我飞的次数会比我带他要多很多。最想对他说一句由衷的谢谢。还有说过请他吃饭的事情一定会兑现诺言的。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 萌芽：团队的起源源于队友暑假打的一个比赛，既然比赛有一个成功的算法雏形，我们当然愿意参与其中。知道这个团队的组成还是很开心的，因为很多都是以前听说的学霸，自然而然地就以为可以在里面舒舒服服地被带飞。可惜在软工实践中，这是不可能的，想要得到好成绩，就要付出努力。
- 磨合：刚开始的团队磨合还是会有一些小问题的。开始的几次会议简单确定了接下来的方向，在一次决定分工的群投票中，由于选择的太晚。最后迫于无奈被分入的开发组。但想到大家基本都是0基础，都得从头开始学，也没什么怨言。后来的合作基本流畅，当然也出现过因为贡献度分配的问题而产生争执的情况。我觉得这是很合理的，并不是一件坏事，理越辩越明，这会让我们团队合作更加紧密。
- 规范：这大概是我们团队目前的现况吧。分工明确，责任和协作人清晰可查。组长的统筹也很合理，并且具有执行力。当然，在代码上的规范还是远远不够的。
- 创造：现在团队还没有到创造的阶段。每个人做的基本都是自己的工作，很少有个人能够在各个模块都有一定贡献，并提出创造性的想法。整个团队虽然有创造力，但是远远称不上一个创造阶段的团队，我们也没有能力去执行我们的创造性想法。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
我们团队开发的产品是面向大学生使用的，现在暂未投入市场，但经过我们小组内部使用和前期投放的问卷调查，这一产品还是比较受市场欢迎的。
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
我们队用燃尽图等手段，定时查看每个队员的“生产进度”。采用原型设计模型，拥有良好的团队协作，足够保证能在预计的时间内发布“足够好”的软件。
3）并且通过数据展现软件是可以维护和继续发展的。
我们团队有足够详细的文档说明和源码，易于维护和继续发展。
补充一下图片：
4）对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。
大部分都不能回答，看来我的专业水平离一个程序员的标准还是远远不够啊。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
论文名：Open source software development should strive for even greater code maintainability
引用：（百度翻译后的）
随着年龄的增长，预计OSS项目会有类似的行为是很有道理的：OSS方法将以与CSS相同的方式产生遗留系统。因此，OSS系统也需要适当的重新设计操作。换句话说，预防性维护可能是OSS支持者必须考虑的第三种维护类型。需要更多的实证分析来巩固这项研究的发现。我们将继续监控这些项目的质量，并将我们的分析扩展到其他OSS项目，这些项目预先发送了有趣的特性，并允许与CSS开发进行比较。但是，从OSS系统用户感知质量的角度来整合OSS质量的结构视图是非常重要的。
虽然简单地浏览了一遍，但是并没有很透彻地理解文章的意思。本文着力于oss与传统css的比较，多次提到了可维护性的概念。软件工程中也反复提到可维护性的概念。从可维护性的角度来看，不止是能更容易地发现bug，更是为今后扩充功能打好基础。这不仅需要严格的代码规范和注释，也需要有效的配置管理，这方面我们团队做的还是比较粗糙的。同时我也发现，现在百度翻译做的真的不错，翻译出来的效果基本和原意差的不是很多。当然，对一个程序员来说，学会看英文论文也是必须的，这个还需要加强学习。
七、个性发挥，包括图文、照片和创意等
团队的第一次合影，希望我们团队能保持初心，始终如一。
不知道说些啥，那就新年快乐（期望考试高分）吧>_<
