个人作业——软件工程实践总结
软工实践总结作业
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
对这门课的期待也是能通过学习，能丰富自己的知识。希望能够通过和队友的合作，做出一个好的项目。
- 通过这门课的学习，项目开发能力得到了提升，在没上这门课之前，没有什么项目经历，但是通过这门课，从选题，到需求分析···经历了项目开发的基本过程
- 通过这门课的学习，自己的代码能力得到了提升，在之前会一些语言，但是都比较粗浅，通过这次的课程，巩固了自己Java的基础
- 通过这门课的学习，懂得了一点项目管理
- 查找资料更快了
- 但是自己的代码冗余度有点高，时间利用率太低，测试能力还比较低
- 就业竞争力还是比较弱
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
统计一下，你在这门软件工程实践中，完成了多少行的代码；
| 语言 | 代码行 |
|---|---|
| java | 6680 |
| xml | 720 |
| html | 840 |
| css | 500 |
-
软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 花费时间（h） |
|---|---|
| 第一次作业——准备篇 | 2 |
| 第二次作业——个人项目实战 | 18 |
| 原型设计（结对第一次） | 14 |
| 结对第2次作业——WordCount进阶需求 | 16 |
| 团队展示 | 2 |
| 项目选题报告 | 15 |
| 项目需求分析 | 23 |
| 团队作业——校友录 | 6 |
| 项目Alpha冲刺 | 53 |
| 个人作业——软件产品案例分析 | 8 |
| 事后诸葛亮 | 2 |
| 项目beta冲刺 | 21 |
| 个人作业——软件工程实践总结 | 2 |
| 总结 | 182 |
-
哪一次作业让你印象最深刻？为什么？
第二次结对作业让我印象深刻，那是第一次和别人一起写一个东西，在第二次结对作业当中遇到最大的问题就是github的使用，两个人的代码签入后发生了冲突，还有就是两个人的代码风格不挑，在刚开始写代码的事后没有统一，导致写了差不多之后还要修改。 -
累计花了多少个小时在软工实践上？平均每周花多少个小时？
完成作业的时间和学习的时间合起来花费了近200个小时在软工实践上，按17周计算，平均每周花在软工实践上的时间有12个小时左右 -
学习和使用的新软件和工具
- 原型设计——Axure RP
- 画活动图、用例图等——starUML
- 思维导图——ProcessOn
- 团队项目管理——GitHub
-
学习和掌握的新语言、新平台
语言没有新学习什么，但是更加深入的学习了Java，学习了servlet和service -
学习和掌握的新方法
- 单元测试
- 性能分析
-
其他方面的提升
- 和大家的团队协作能力
- 抗压能力
- 提高了查资料和自学的能力
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
在团队项目实践中，大家都基本属于0基础，有的可能只是知道Java的语法，没有真正的实践过。在大家合作开发网站的时候，大家分工发现都没有会后端，最后只能硬着头皮边学边做，我自己先学，然后大家统一按照一定的框架做，这样在后期的代码整合的时候会方便很多。因为是边学边做，我们在alpha的时候遇到很多问题，service和servlet那边都遇到很多问题，我们遇到问题主要先百度解决，但是百度的答案有的时候不一定正确，就需要一遍一遍的尝试。有的时候还是解决不了就去请教会的同学。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？
- 对下一届的建议：选实践一定要慎重（但是好像从下一届开始就要必修了），选题要量力而行，组队要综合考虑每个人会的东西，组队要是比较多都是什么都不会的就不太好。
- 对于开学的自己：要好好安排时间，不要积累大量的工作量放在deadline之前
- 对大一的我：大一时间充裕，好好学习知识，积极参加竞赛
- 至于要不要中途换队员，这个要视情况而定，我觉得可以让团队成员自己选择要不要更换，如果真的不适合这个团队就需要更换。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 萌芽阶段
团队刚成立的时候，大家热情都特别高，一起讨论选什么题目，要先学些什么技术 - 磨合阶段
在合作过程中会发现大家的习惯，代码风格都不一样，就需要磨合，在alpha阶段体现的最为明显 - 规范阶段
经过了alpha阶段，在bata阶段开始之前，大家就对自己代码的规范化，命名都采用驼峰命名，采用一个框架，都添加注释 - 创造阶段
可能还有一点距离，但是快了
五、怎样证明你学会了软件工程？请在随笔中用数据证明下面内容或侧重选择之一。
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
在beta冲刺结束之后，我们进行了用户调查测试，大部分用户都认为我们的网站符合他们的需求
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
通过github管理代码，在软件开始前有选题、需求分析，原型设计，代码实现，部署到服务器等阶段，大家一起协作开发。每个人负责不同的模块，每天都有规划进度，第二天的安排。熬夜经常存在，但是不是临时，基本属于明天12节没课，大家就会熬夜争取多写一点东西
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
- 代码放在GitHub上（github地址）
- 代码有接口文档、有注释
六*（选做）、阅读软件工程中关于代码质量的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
默认情况下，该工具使用测量值测量每个组件并根据四个基本标准（即可测试性，简单性，可读性和自描述性）对其进行评估。该标准取自关于软件质量子特性的国际标准（国际标准组织（ISO），1991）。该标准被软件行业的许多公司使用（Fenton 等，1995并且，尽管有批评，但它被认为是软件质量测量发展的一个重要里程碑。此外，上述标准充分反映了开源代码所需的质量特性，如引言中所述。开源代码应该是可测试的，以允许快速演进并且足够简单以允许频繁修改和扩展。显然，它应该是可读的和自我描述的，以促进这些活动。
——引用自《Code quality analysis in open source software development》
通过阅读论文知道，可以通过可测试性，简单性，可读性和可描述性四个方面衡量自己代码的质量
目前我自己的代码做到了基本的可读性、可测试性。
- 可读性：代码变量的命名采用驼峰式命名，使用看的懂的单词命名。添加适当的注释。
- 可测试性：代码大多数采用接口形式调用
但是自己的代码冗余性太高了，很多重复的代码，不够精简
有三种不同的关键实践可能有助于实现高质量的代码：
1、可以要求程序员在干预代码时考虑结构代码质量。
2、项目协调员可以根据预定义的标准评估程序员返回的代码的质量。这意味着某些不符合标准的组件可能会被拒绝，即使它们提供了正确的错误修复或新功能。
3、当项目似乎遇到严重问题时，项目协调员可以采取适当的代码重新设计决策。——引用自《Code quality analysis in open source software development》
通过规范代码，可以减少后期不必要的修改。可以学习一下怎么提高代码的质量。
参考论文文献：
[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.
七、个性发挥，包括图文、照片和创意等
感慨一下，软工时间终于结束了，这学期的代码量可能和掉了的头发成正比，可以不用在熬夜了，接下来就是好多好多的考试。
