团队总结
| 这个作业属于哪个课程 | http://edu.cnblogs.com/campus/xnsy/GeographicInformationScience |
|---|---|
| 这个作业的要求在哪里 | https://www.cnblogs.com/harry240/p/11524252.html |
| 团队名称 | 超越队 |
| 这个作业的目标 | 对整个课程学习过程进行总结 |
| GitHub地址 | https://github.com/caiyulan/ChaoYueTeam |
一、成员列表
| 学号 | 姓名 |
|---|---|
| 201731024205 | 蔡玉蓝 |
| 201731024207 | 郑雪 |
| 201731024209 | 何玉姣 |
| 201731024211 | 王春兰 |
二、个人总结
-201731024205
| 姓名 | 蔡玉蓝 |
|---|---|
| 学号 | 201731024205 |
| 博客地址 | http://home.cnblogs.com/u/caiyulan9013/ |
| 第一篇作业博客 | https://www.cnblogs.com/caiyulan9013/p/11506365.html |
1.尝试解答自己提出的问题
Q1：如果用户期望方向与软件优化方向不一致应当如何抉择？
应该在二者之间找取平衡点，毕竟没有用户，软件做出来也不会有人用，可采用问卷调查，软件测评等方式征集用户期望再与软件优化方向之间选取一个最优之策。
Q2：怎么判定该不该优化？优化应该在什么时候进行？
经过此次学习过程，我觉得如果软件某个功能与预计的期望并不一致或者占用了过多的资源就应该考虑是否优化了，但在什么时候进行觉得还是一个经验之谈，太早的优化可能会造成没有全局观而对之后的工作造成不良影响。
Q3：自己用自己开发的产品会发现很多问题，但也如下文所说这样的方式在用户体验方面过于单一，如何解决？
自己使用发现的问题很有限，可以有个内测版之类的先让一批用户抢先体验再收集用户的意愿，用户测评与问卷调查等也是可以考虑地方式。
Q4：既然QA包含测试工作，那QA和Test的角色可不可以合二为一？
我觉得还是不可以，团队之间应该有明确分工，不能因为节省预算就让两份工作让一个人做。
Q5：断言是什么？什么时候用断言，什么时候用异常？
断言和异常都是检查程序错误的工具，检查先条件用断言，即开始执行的时候需要满足的一些条件，检查后条件（执行以后的条件）使用异常。也有说法是断言检查程序写错了的错误，异常检查外界环境、用户操作产生的错误。自我感觉是在测试时大多用断言，程序代码内的错误用异常。
2.掌握的技能
- 了解了一个软件从提出到最终完成的整个过程
- 学会了使用Markdown编译器编辑文本
- 了解了一些软件开发过程的规范
- 一定程度上提升了些编码能力
- 了解了一些GitHub的简单使用
3.体会与总结
这门课的学习过程虽然着实漫长了些，但也确确实实使自己通过实践学会了很多东西。软件工程真的是一门工程，每一步都是有严格的标准把控的，不单单只是写代码而已。在本次的团队协作中，也深刻意识到了团队的重要性，分工合理的团队协作才能使任务变得事半功倍。总之还是受益匪浅
-201731024207
| 姓名 | 郑雪 |
|---|---|
| 学号 | 201731024207 |
| 博客地址 | https://home.cnblogs.com/u/zhengxue666/ |
| 第一篇作业博客 | https://www.cnblogs.com/zhengxue666/p/11508450.html |
1.尝试解答自己提出的问题
Q1：为什么大家非要站着开会呢？我觉得工作了一天会很累啊而且坐着更亲近一些吧，站着有什么好处呢？
站着使人更清醒更专注于对方说的话。不过会议进行的方式也多种多样
Q2：很低级的错误为什么要记录下来呢？这样不会很占内存吗？而且让数据显得很冗余。
细节决定成败，往往很小的错误会引发大的故障。不可忽视小错误的力量
Q3：现在大量决定的提出伴随着很多很多数据的支撑，究竟是好是坏呢？
这个是相对的。有更多的数据支持会精细化判断，而又怕过于依赖数据。
Q4：为什么几乎不能实现"又多又快又省"呢？是什么问题导致的呢？这又是否是我们以后努力的方向呢？
这是一个定律而已。
Q5：在用户体验上，功能性和情感性应该如何取舍呢？或者说应该分配多少比重？
我觉得各占百分之五十吧。毕竟软件是做出来给人用的。
2.掌握的技能
- 强化了做PPT的技能
- 了解了很多新的名词，比如用例图，软件结构图等
- 对软件的开发过程有了基本的认识
3.体会与总结
软件开发很不容易，团队的合作尤其重要，毕竟人无完人大家要优势互补嘛。也给自己警示软件开发需要坚持，需要不畏艰难，不能被眼前的困境吓住。
-201731024209
| 姓名 | 何玉姣 |
|---|---|
| 学号 | 201731024209 |
| 博客地址 | https://www.cnblogs.com/jiao54/ |
| 第一篇作业博客 | https://www.cnblogs.com/jiao54/p/11507539.html |
1、对自己的提问进行解答
Q１：两人合作中应该怎么选择合作对象并且高效地完成工作？
答：根据自己的亲身体会，我认为首先应该找准自己的定位，然后选择一个与自己互补的伙伴，在合作过程中，多沟通交流，相互督促，共同完成工作。
Q2：在团队中，怎么知道自己是属于团队中的哪一个部分？
答：我觉得这主要是看自己在团队中能够做什么，只要能够为团队做出贡献，纠结自己属于团队中的哪一部分已经不重要了。
Q3：我们应该在什么时候进行代码重构呢？
答：在编写完代码之后，我们要根据设计文档和代码指南对代码进行复查，然后再进行代码的修改，以防代码的错误和冗余等，这就是代码重构。
Q4：如果用户的需求与后续完成的软件有一定的冲突，我们是否一定要根据需求来做更改？
答：要根据需求来做更改，因为我们做软件的目的，就是为了有更多的人去使用它，如果不能满足用户的需求，这个软件的开发也没有了意义。
Q5：在重复做某样东西之后，我们应该怎样改变自己的思维方式，进行创新？
答：在软件开发过程中，重复做某项工作是不可避免的，想要进行创新，我认为就要丰富自己的知识库，才能更好地认识自己所做的工作，并进行总结，最后升华，进行创新。
2.掌握的技能
（1）学习到了github源代码管理工具的具体用法，并熟练掌握用github克隆项目以及提交代码的全过程。
（2）熟悉了软件开发过程中，各种文档的编写，并制作用例图。
（3）熟练使用CSDN写文章，并在博客园中发表自己的博客。
3.深刻体会与学习总结
通过这门课程的学习，我明白了团队合作的重要性，学习到了代码测试，画用例图、编写文档等技能，在软件项目的团队合作中，通过亲身经验体会到了团队合作并非想象的简单，同时也深刻的体会到了软件的开发并不是我们想象中的编写代码来实现这么简单。相反代码只占了开发过程的一小部分，最多的还是前期的需求分析等工作。对于软件的开发我学习到了许多重要的知识，受益匪浅。
-201731024211
| 姓名 | 王春兰 |
|---|---|
| 学号 | 201731024211 |
| 博客地址 | 王春兰博客 |
| 第一次作业地址 | 第一次作业地址 |
1.尝试解答自己提出的问题
Q１：是不是绝大多数人在自己的拿手领域内都做不到创新？这是因为很多人都会自然忽略很多自己领域内的细节吗？
答：说实话，这个问题确实是当时问的比较***钻，又没有什么用处，为问问题而问的，所以，我也不知道答案。不过，这也让我明白，你现在的敷衍很大可能都会在后来造成一些不太好的结果。
Q２：在Bug的修改与否的选择中应遵循怎样的原则呢？
答：完整的一次软件设计下来，我对BUG的看法就是首先应该以主要需求为主，优先修改实现主要需求过程中出现的错误，然后先修改简单的错误，再修改难的。
Q３：有没有一种简便的程序可以实现代码的自动规范呢？如果没有，那是什么限制了这种程序的实现呢？
答：这个助教有说过，tab键之类的代码规范，很多编程软件都可以自动规范格式。至于其他的比如命名风格一类的话，除开必要的一些规则，比如驼峰命名等外，就没有必要进行太多的规范，而且，这个其实也不影响代码的实现，只是在进行团队编程的时候，其他人看不懂的你的命名的话，编程进度会被拖慢很多。所以，在项目开发前，一个团队就应该给出自己团队风格的代码规范规则。
Q４：在实现需求前会有很多的前期准备，如果一昧的追求时间快，会不会反而使效率变慢？
答：这个问题其实也比较没有意义，因为在一个项目中，前期的需求分析这些是十分重要的，如果前期准备不到位，那你就算做出来成果了，也是客户不需要的，磨刀不误砍柴工。当然，前期准备也必须在一定期限内完成，否则项目完成不了，前期准备的再好也没有用。
Q5：如何提高问卷的准确性，从而更好的把握用户需求呢？如果不能，那是不是这种方法就不是很实用呢？
2.掌握的技能
- 学会了如何写博客。
- 学会了github的一些使用基础。
- 学会了一个软件的完整开发流程。
- 学会了在一个如何在一个团队中发挥自己的作用。
3.心得体会
- 这门课可以说是我上大学以来最独特的一门课，其他的课，都是老师讲然后布置作业，我们不会，他再手把手地教。但这门课，主体部分变成了我们自己设计软件，从选择团队到最终答辩，所有的一切基本都是我们自己完成，这在以前是我没有想过的。但在这样一门课中，我又学会了很多，我知道了一个好的团队有多么重要，很多团队在后面时间越来越紧时开始爆发矛盾，选择一个适合自己的团队真的很重要，我们团队由于都是一个寝室的，大家沟通到位，最后磨合的还挺好。还有我也算发现了一个学习很好的方法吧，很多编程有关的问题都可以在网上找到解决方案，我本身是一个不爱麻烦别人的人，这样还挺方便的。
