0.日常开头
| 这个作业属于哪个课程 | 应该是属于系统分析与设计这个课程 |
| 这个作业要求在哪里 | 在这里鸭 |
| 团队名称 | 六扇门编程小组 |
| 这个作业的目标 | 总结、回顾整个课程 |
| GitHub地址 | 地址在这里 |
1.队员列表
| 姓名 | 学号 |
| 曹欢（队长） | 201731031124 |
| 申颖 | 201731062306 |
| 唐金玉 | 201731062405 |
| 彭皓 | 201731062323 |
| 许自欢 | 201731023214 |
| 黄浩 | 201731054221 |
3.正文部分
曹欢 201731031124
第一次博客链接：博客链接
尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的。
1.在教材第三章58和59页，以魔方的例子类比软件工程师的成长，文章中对魔方的技能层次专业的划分的层次，可以让喜欢魔方的人知道自己在哪一个层次，但是作为一本软件工程相关的书，我想知道一个软件工程师的层次划分又是怎样的？以此来判定自己具体是什么水平。
答：通过查看资料，软件工程工程师的划分有着比较明确的划分：初级软件工程师、中级软件工程师，高级软件工程师、资深软件工程师、CTO。其中每一个阶段的划分，都有着比较明确的技能要求，比对着这些技能点，就可以知道自己是什么水平。比如初级软件工程师，就可以在高级工程师的指导下完成模块编程。面对一个编程问题，他们对实现方法了解不多，通常只要实现了就行，不会过多考虑更好的实现。因此，无法保证产品质量。后面的就不一一举例了。
2.在16章的时候，关于IT行业的创新，作者列举了许多的的“迷思”，在这些故事里面，让我了解到了很多有趣的故事，故事内容让我看到了很多与常识不符的一面，比如说创新不一定要是专家，好的想法也不一定会赢，创新的人也不一定会喜欢创新。这些东西与常规理解相反，但是又有着一定的道理，往往打破常规，我在想有没有什么办法可以预见这些非常规方法的成功？而不是为了创新而去创新。
从这些故事和我现在所理解的经验来看，预见这个问题不说是想创新就可以创新，创新是来自一个人对事物的看法，思考角度等等。创新思维需要刻意的去培养，去从不同的角度看待、发现问题。
3.在第四章两人合作里面提到的结对编程，结对编程是一个需要磨合的过程，但有一些人确实不适合结对编程，那么怎样去判断一个人是没有找到合适的结对编程对象还是说真的不适合结对编程？
对于绝大部分的人来说，都是适合结对编程这个活动的，可能刚开始没有接触过结对编程的人对于多了一个小伙伴有点不适应，但是久了之后就会发现自己其中的好处，合适的结对编程对象可以是我们的好朋友、技术较好的人等等。
4.在第11章237页，书中把我们学校所学比作定点投篮，把构建比作实战中的运球，传球。这样让我感觉，学校所学和实际所用有着一定的差别，我们在面对一个项目的时候毫无构建经验，那么有什么办法让我们在学校期间就可以接触到一些构建的事务？
这个东西说实在的，我觉得第一吧，可以去网上找到各种资料，里面应该都是有具体的事务的。然后我通过springboot的大致接触，我发现看源码真的是理解一个东西最透彻的方式，当然这个有点难，可以去看看相关书籍。
5.在第16章的时候，有一个让我记忆深刻的例子，大牛会两手在屁股后面翻魔方，其实我一开始想到的是大牛人正对着同学，屁股在后面，但是例子和我想的刚好相反，我很想知道我的想法会不会稍微改善一下大牛面对小芳时的误会？究竟是屁股对着目标用户，还是正对着目标用户，或者都要做到才会有一个好结果？怎样避免一个技术型的埋没？
这个地方确实我感觉大牛有点死脑筋了，他不应该把拧魔方这件事背对着大家，应该让大家看看他拧魔方的过程，虽然大家都看不懂啊，但这样好了很多啊。在技术上也是这样，要在一定程度上让别人看到你的技术，不懂不重要，总比什么都看不到要好啊。
是否产生新的问题，请提出
自己虽然也算经历了一次次SCRUM的人了，但是我还是比较想知道，在公司里面，正儿八经的团队到底是如何运作的。
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
从技术上来说，通过这次的项目锻炼，我自己写了一部分的ssm后端代码，对ssm框架有了一个更好的理解，对微信小程序也多了不少的接触，了解到了微信小程序最基本的运作方式。同时也学到了一些原型工具、GitHub的使用。然后是这次的合作，作为组长，我学会了如何给大家分配任务，如何保证项目的进度，每日立会的开展等等，对于团队合作也有了一个更深层次的理解。
有什么深刻的体会，对自己一学期学习过程的总结。
我最大的收获就是，我学会了一点，那就是很多时候不是你会了某样东西，你才去接手，你才敢说自己去做这个，而是要学会学习，计算机软件行业有那么多的技术，比起学会这些技术更厉害的一个东西就是学习能力，快速上手一个新事物的能力，这才是最重要的。
我最大的收获就是，我学会了一点，那就是很多时候不是你会了某样东西，你才去接手，你才敢说自己去做这个，而是要学会学习，计算机软件行业有那么多的技术，比起学会这些技术更厉害的一个东西就是学习能力，快速上手一个新事物的能力，这才是最重要的。
个人学习也要讲究方法，个人可以通过各种方式，视频，图书，博客等等。但是我发现一个比较有趣的地方，对我个人而言，我需要在一定外界压力下，才能保持自己高效的学习时间，自己的技术和能力才能快速提升，如果没有压力，让我自己去学习，那么我会相对没那么认真，对待事情也不会那么积极，这点我会谨记，希望自己能够改正。
通过这次的课程同样让我了解到了团队协作的好处，在做一个项目时，有人和你一起思考，一起敲代码，一起查资料，但是配合也需要磨合，在磨合的过程会比较麻烦，因为大家之前都没有在一起干过事，但是不得不说，一个好的团队是很重要的。
同时，一个项目绝对不是编程、敲代码这么简单的事，一个项目的完整是来自最初的需求分析、市场调研等等，在编程完后，测试、修改、跟进也是必不可少，把这些交给一个人实在是有所为难，这个时候才显得团队协作是多么的必须。
申颖 201731062306
尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的。
1.问题一
问题出处：第三章 软件工程师的成长 技能的反面
问题来源：
我更不知道如果在执行过程中走错了几步，随机应变，挽回局面。离开口诀的话，我只能拼出一面。从这点来看，我的魔方技能应该是”能够独立地还原一面，其他看口诀可搞定”。那怎么才是真正的的”技能”呢？
问题：作者原来精通魔方但是因为很多年不玩认为只是找到了一个模式，按照某个口诀才能有以前的技能，作者认为这不呢个算作一项技能，但是这个真的不是作者的一项技能吗？
现在解答：通过完成整个项目，对是否具有某项技能有了一个更深的理解，我认为相较于纠结是否拥有这个技能是要看你是否能够解决需要这个技能的实际问题，也就是能不能实际去解决相应的问题，如果你真的掌握了某项技能的话就能解决实际问题，而不是说理论有多么完善，只有通过实际的动手操作做出来了才能够算是具备了这个技能。
2.问题二
问题出处：第八章 需求分析 竞争性需求分析框架
问题来源：我们要在竞争性的环境中实践软件工程，那就要做实用并且有创新的项目。
问题：在竞争性的环境当中一定要做实用性的项目吗？
现在解答：通过整个项目的流程，写了项目策划书，还有每日立会等等工作，其实有的项目不一定要具有实用性的项目，实用性的项目不一定就能够被人们所使用，我们要做的是能够解决用户痛点的项目，比如我们组做的项目就是宿舍管理系统，当时想做就是因为发现宿舍管理的方式相当不合理，学生和宿舍管理员在这方面都有所忽视，所以也不是说不做具有实用性的项目，而是实用性项目的定义是建立在能够解决痛点的基础之上的。
3.问题三
问题出处：第12章 用户体验
问题来源：大部分软件工程师主要关心的是”使用的效率”，这只是用户体验设计的很小的一部分。那我们要在什么阶段，以什么样的方式来关注其他方面设计呢？
现在解答：我认为首先要提前决定整个界面的设计，因为前端界面的设计可能会影响到后端的书写，有时候后端书写完了又来修改前端的界面会显得很麻烦。这次我们的项目就特别麻烦，就是自己写前端的时候又带上了一点后端的代码，导致真正写后端的人就看不懂我写的代码，他只有修改我的前端界面再来写后端的代码，然后最后在项目总结的时候我又来重新在他的后端代码的基础上再来修改我的前端界面，这样就导致了很多代码的重读增加了每个人的负担。
产生的新问题
在做项目的过程当中真的需要每个人只做自己那部分的内容吗？
经过整个学习的系统分析和设计的课程，通过个人作业和团队作业，加起来也有很多的内容，包括最后的一些答辩还有PPT以及项目计划书的内容，我们也算是走过了整个项目的流程，通过敏捷开发的方式算是圆满完成了整个学期的课程内容。通过最开始的阅读邹欣老师的《构建之法》，在项目就开始之前总结了很多的有关于各个方面的问题，在做项目的过程当中，因为自己主要是负责微信小程序这个端的所以对于微信小程序的整个构架以及前端界面的一些书写还有后端怎么去传递数据以及如何和服务器进行交接都有了一个新的认识。原来开始学微信小程序的时候都是写的一些前端的界面而已，还没有涉及到后端数据的处理，所以这次通过项目学到了很多的新知识。因为整个微信小程序的所有的界面多是自己书写的还是有一些累。并且在设计界面的时候也是很头疼的。由于后面我直接修改后端写好的代码的界面，导致自己必须要先去看懂后端的代码，而且还不能影响到后端代码的传输，因为服务器那边的代码已经写死了，如果直接修改的话会导致数据不能传输，因为修改一个上传照片的功能我就修改了一个下午，也是很难受了。所以可以看出在项目的过程当中前后端的衔接是很重要的。掌握的方法就是先看后端地代码，然后按照自己地理解先去尝试修改代码，实在不懂地时候就会去查一些资料。在最后还我们组还经过了七次冲刺，通过这七个项目冲刺的任务，感觉到了安排任务的重要性，所以首先要在这里谢谢组长大大的安排能让我们每个人都能够按照自己的进度来完成这七个冲刺任务。在这次的冲刺任务当中，我不仅仅完成了前端的界面的书写，因为这个是基于后端成员修改完毕的第一版本的和基础上来进行修改的所以说只有在后端代码上的基础上来进行界面的修改，刚开始修改界面的时候，很有可能会因为前端界面的修改导致数据不能上传到后端或者不能从服务器上面取到数据下来，所以说者不仅仅是对我前端的内容的锻炼，更是要看懂后端的js是怎么去传递数据的，有一个照片上传的界面改了一下午都能没有改出结果因为涉及到了很多后端的代码，如果前端界面大改的话可能就会导致到需要更改后端的代码才能够运行完成，所以说中间经历了很多的曲折，但是同样耶让我学习到了一点点的后端的内容，虽说不能完全掌握，但是到了后面还是大致能够看懂代码的逻辑，但是还有其他方面的不足，比如界面的逻辑跳转还是有问题。总得来说，收获很多，踩坑也很多。
查找资料地网址：
（1）https://www.jianshu.com/p/5753a0e1754f
（2）https://www.wandouip.com/t5i128161/
（3）https://blog.csdn.net/zhou_hao_yan/article/details/79854681
（4）https://www.w3cschool.cn/weixinapp/rmcw1q8t.html
（5）https://www.jb51.net/article/156350.htm
（6）https://blog.csdn.net/qq_37336198/article/details/81369293
唐金玉 201731062405
第一次提问博客：https://www.cnblogs.com/sparrowchengyu/p/11486973.html
尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的
问题1：第三章：3.4节“技能的反面”
原文： 那什么才是“技能”呢？技能的反面是什么？技能的反面是“problem solving”—“解决问题”
疑问： 真的可以完全将解决问题定义为技能的反面吗？这样的说法是否太过绝对？
我的解答：在经过此门课程的学习之后，再看这个问题，我最初的理解是解决问题的过程也算是一种技能，在解决问题的过程中，我们需要分析、比较、贯通，所以我认为并不能绝对认为它是技能的反面。现在再看这个问题，通过在每一次的作业以及实践中，我认识到作者此处想要强调的技能的反面是解决问题，主要是想说明我们在实际的项目过程中，在完成了基本的解决问题的基础上还需要再更进一步的，更优化地解决问题，就是要达到我们所说的要做出更好的软件。
问题2：第五章：5.2节“软件团队的模式”
原文： 一窝蜂模式可能是一个欢乐而随意的模式，但这是一个好的团队形式么？当然不是。
疑问： 一窝蜂模式也会经历成长，就此否定是否太苛刻？
我的解答：我以前的理解是“一窝蜂模式”可能是很多团队最初的模样，不可能有哪一个团队大家聚在一起就不必契合，都需要经历一个互相磨合的过程，所以我认为并不能就此否定它。一窝蜂模式往积极的方向发展，最终也能成为分工明确、积极合作的团队形式。经过了整个课程的学习以及项目过程，参与了本小组的团队形式，也见证了其他小组的团队形式，我现在的感受是：最好的团队形式没有绝对的标准，并没有天生契合的团队成员，在团队的合作过程中，分歧甚至争吵的存在都是合理的，那是团结一点点成长，大家努力契合的过程。
问题3：第八章：8.3节“获取用户需求-用户调研”
原文： 这一调研方式要求用户记录自己日常工作生活中与所用软件相关的行为，供软件团队分析。
疑问： 此处所提到的“用户日志研究”这种方式是否不太实际。
我的解答：我查询了一些与日志研究相关的资料：“日志研究是一种收集用户行为、活动和体验的定性研究方法。日志研究需要研究的参与者在一段很长的时间段内（几天、一个月甚至更长）进行自我报告。在这段时间内，研究参与者被要求保留日记并记录有关正在研究的活动的具体信息。为了帮助参与者能记得去写他们的日记，有时会定期提示他们（例如，通过每天定时的通知或在白天一些的特定时间通知他们）。”可以看到，虽说日志研究可以很好记录用户行为活动，但是需要投入大量的时间精力和人力，而且按照如今的现状来看，繁忙的工作生活下，应该没有太多人愿意花费来填表记录，在我看来，普通用户对于某种软件产品的态度就是不好用换一款就好了，所以此方法并不实际。当然，也不排除对此产品热爱喜欢的受众，他们愿意记录自己的使用报告，这对软件产品的开发者来说就十分有益了。
问题4：第九章：9.4节 “领导力—高效的团队讨论”
原文： 很多人认为“创意”是一种天生的才能，或者需要大智慧才可有创意，其实不然。创意是一种可以后天获得并不断提高的技能。
疑问： 要通过怎样的后天努力才能获得此技能呢？
我的解答：通过查询相关资料，对创意的解释是“创意是创造意识或创新意识的简称，亦作“剙意”。它是指对现实存在事物的理解以及认知，所衍生出的一种新的抽象思维和行为潜能。”在我的认知里，好的创意需要有好奇心以及善于发现与思考的能力，还需要能提出新的有想法的点子，如今科技的迅速发展使得新的思想能够快速传播，感觉后天获得还能不断提高真的很难。在与团队成员合作的过程中，我发现很多时候创意也是团队成员相互激发的一个过程，一个人的想法可能稍显平淡，没有特色，经过队员的点拨提醒可能就会变成很有特色的创意。
问题5：第十六章：16.1节“创新的迷思”
原文： 谁不喜欢创新呢？然而细细想来，创新就是做和以前不一样的事，并不是所有的人都喜欢“不一样”。不但大众不喜欢创新，甚至连创新者自己都不例外，有些创新者甚至恨创新。
疑问： 大众不喜欢创新或者创新有反对的声音，是否并不是创新本身的问题，而是创新的事物还存在瑕疵？
我的解答：在查阅了相关资料之后，我承认大众对创新的接受度需要一定的时期，但是我认为不是创新本身的问题。马云的电商最初也是一种创新，很多反对、质疑的声音，但是当它发展成熟，真的给人们带来了便利，我们还会坚持最初的否定吗？我认为不会，只是人们会关注自己的利益是否受损，创新的事物对原有的事物冲击太大，也就出现了反对、怨怼。我更加深刻地认识到，创新事物本身足够有价值，更多的还是被肯定和接受的。
是否产生了新的问题？请提出。
在实际的过程中，在一些文档的编写方面，需要大家合作完成，怎样才能更有效地保证一份文档中大家的风格差异不要太大呢？
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
1.在阅读专业书籍时，带着思考和疑问去解读。由于本人觉得自己专业能力不强，所以在面对专业的书籍，总有一种莫名的敬畏感，总感觉书里的知识就是权威。但经过第一次的阅读《构建之法》之后并提问，我发现其实在面对自己不擅长的方面，在阅读学习时更要有敢于提问与质疑的精神，这样更加能促进这个学习的过程。
2.通过查阅相关资料，一些大佬的博客，学习了如何使用github这个工具来管理源代码。
3.在文档的编写方面，详细设计的过程中，更加深入地学习了使用用例图以及流程图来描述某个功能及过程。以前只是浅显了解，这次通过上课老师的讲解以及在网上查阅相关资料将其运用至实践中。
有什么深刻的体会，对自己一学期学习过程的总结。
经历了漫长的过程，这门课已接近尾声了，现在回望这门课程，其间自己有“痛苦”、有“挣扎”，但也不乏喜悦与感动。现在看来，我认为每一次作业都是一次学习与成长的过程，也经历了很多的第一次：第一次阅读在阅读专业书后提问并思考；第一次自己上手来画原型；第一次结对编程；第一次在测试同伴项目后提出自己的感受。在阅读专业书并提出问题后，我学会了在阅读这个过程中，自己需要有思考与探索的精神，这样才能更好阅读与理解；在画了原型之后，发现很多事情要去尝试、去经历（以前也想试着学习原型设计，但总是因为各种原因被搁置）；在结对编程之后，明白了1+1>2是什么感受；在测试同伴项目并提出建议时，更加清楚自己在这个过程中同样可能忽略的一些问题。而在团队协作时，大家需要沟通交流，互相表明自己的真实想法，有困难大家一起讨论解决，会发现有那么几个人总是与你同在的感动。除此之外，从最初的慌乱不会分配时间，到后面渐渐合理调整，都是学习与成长的过程。总之，很感激这门课程，它让我学习了一些新的东西，接触了一些新的领域，也收获了满满的感动与真诚的友谊。
彭皓 201731062323
第一次作业博客链接：https://www.cnblogs.com/slothph/p/11503162.html
问题一：
前期的准备更加完善（需求分析的全面等），还是实践经验的丰富加速了代码的编写？
答：两者皆有，但经过这一学期课程的学习，让我更加注重前期需求分析的全面性，并不是说一定要前期把需求定死，毕竟需求永远在变化，而是说考虑需求时要更为全面，对各项功能难点进行评估并整理出各功能的优先级，在遇上技术难点时，如何妥善处理，前后端对接时的格式要求等。这些在需求分析阶段明确定义并严格执行的话，即使出现需求变更的情况，也能减少部分时间损失，加速代码编写。
问题二：
如何判定舒适区、学习区、恐慌区，如何选择适合自己的学习区
答：当初是我有点钻牛角尖了，从学习时，自身的感受来划分这三个区域即可，界限因人而异。以我为例，我的学习区就是不能看天书，有新的需要学习的内容，看过之后能够思考为什么，动手操作几下，记录下笔记防止以后遗忘的一系列知识都在我的学习区内。
问题三：
代码复审和软件测试的异同。
答：复审发生在测试之前，代码复审后能一定程度上减少测试时间。代码复审是程序员在编写完代码后，看代码是否在代码规范的框架内正确的解决了问题。其中最重要的两个字是——规范。每个人有每个人的习惯，也许这个功能实现很成功，但是别人难以读懂，这对合作开发来说是一个障碍。另一方面，代码复审可以在初期就发现一些缺陷并进行改正、优化，还能起到教育作用。软件测试也能检测错误并督促改正，但教育、传授经验方面作用就比不上了。
问题四：
项目经理（PM）的作用，管理出身，还是计算机出身更为合适呢？
答：原先以为PM不编代码、测试、设计，只是动动嘴而已，这学期看着组长掉的头发才知道那是真的辛苦。项目开始时就需要以全局的眼光看透整个流程，然后进行安排，要对项目的内容极为熟悉，组内成员遇到问题还需要自己撸起袖子往上顶，各方面进行协调，是小组内的核心之一。PM的存在，使得项目的成本、耗时、质量在一定范围内达到最好。在我看来，软件项目的PM还是懂点计算机相关知识的更好，不然沟通协调难度太高，容易产生矛盾。
问题五：
小作坊、大公司之间的创意差别，团队中的人数多少合适，越多越好么？
答：书上说，IT历史上，许多的成功产品都是小作坊开始的；不得不承认，在创意还是点子，还没有被发现其闪光点的时候，小作坊能将其孵化出来，让人眼前一新，但更多是由于技术、经济等原因胎死腹中。不能说大公司没创意，只不过求稳让某些方面看起来平庸了，创意并不是小作坊所独有的，大公司会逐渐形成自己的特色并加以创新。团队人数在软件方面并不是越多越好，人多了反而增添交流成本，适中即可，重点是全面，要各个方面都有人能撑场子即可。
是否产生了新的问题？请提出。
暂时没有。
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
真的是学了很多，博客的编写，giithub的使用，原型工具的涉猎，vs的各种功能体验，敏捷开发的实施等等。掌握的方法嘛，做中学。看着高大上的一些东西，操作起来，也确实是高大上，但操作过后才会不断地遇到问题，并尝试解决，加深脑海中的印象。
有什么深刻的体会，对自己一学期学习过程的总结。
多元且丰富，让我神器感受到了软件工程不止是写代码的，而是需要“十八般武艺”样样精通，软件和工程一样重要，感谢这次课程让我体会到了软件工程中的艰辛，也确确实实学到了许多的知识，了解了软件开发中的各项流程，受益匪浅。
许自欢 201731023214
尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的
是否产生了新的问题？请提出。
第一次博客地址：https://www.cnblogs.com/xnch/p/11497593.html
回答：对于计算机专业来说，编码能力是第一要务，考级什么的若在自己的基本课程以及编码能力充足的情况下，可以作为自己的升华，而不应该盲目的跟着去考证。同时，一定要考含金量较高的证书，否则不如把准备考证的时间拿来提升自己的编码能力。
回答：在专与精的关系中，我觉得精更加重要，自己需要有一个自己精的方向，并持之以恒的坚持下去，才能走得更远，但是也不能就不了解其他技术了，对于其他方面可大致了解了解。术业有专攻，精通某项技术了后，在计算机这个行业，可以很快上手其他技术，无疑是对自己更大的提升。
回答：在学完这门课程，对这个问题有了新的认识，用户需求不是一成不变的，我们所用的软件来分析用户需求只是得到大致的一个方向。需求之用户需求要利用各种规律，商量得出更为科学的，理论可靠的判断，达到解决问题的能力。
回答：在本次课程中学到了各种测试方法，并都将其用到了自己实际的项目中，对其什么时候使用什么方法有了更深的认识，各种方法分工不同，好好利用的话会提高效率。没有完美的软件，只有更好的软件，合格的软件。科学的，规律的测试将会达到更好的软件。
回答：在本次课程学习结束，这个问题我觉得我还是不能很好的回答，还是存在很多疑问之处。虽然软件工程就变成了前面提到人们不谈了的“作坊”，但是软件必定是各行业的基础，基础不牢，地动山摇。至于软件工程的下一个变革方向我还是未知。
是否产生了新的问题？请提出：
在学习完本次课程，虽然在软件工程理论方面流程走了很多，但是总感觉和企业的差距还是很大，没有系统的时间来搞项目的各种步骤。整个过程中感觉似乎博客大于了文档的书写，还有对文档也没有进行审查评判，相反是对博客进行打分，以后去企业应当是文档更重要吧。
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的：
经过了这学期的学习，还是学习到了很多知识，对软件是什么，程序时什么，软件工程是什么，有了更深刻的认识，对于开发流程更加熟悉，结对编程是之前没有接触过的，学到了不少，团队与流程，敏捷流程的学习使我感觉到其真实的用处与魅力。至于技术方面，微信小程序的编写，使我接触了新的东西，以及Github，虽然之前接触过，但是没有实际的用起来，在这次作业后真正的用起来后才觉得迭代开发真的会减少很多事。总之，多百度多读书多看文档。
有什么深刻的体会，对自己一学期学习过程的总结：
虽然这个课程花费了很多的时间，而且各种问题浮现，但不得不说学到了很多东西。多次想着放弃，要不随便写写就算了，要不随便做做就算了，反正又不可能挂科。后来在内心的挣扎下，骂骂咧咧的终于来到了课程结束。
收获：
坚持，一个错误会花很长时间去解决，一个工具配置问题（如git），发现众里寻他千百度，那人却在灯火阑珊处。坚持下去，一定可以解决。
克服了心理因素，在做作业的过程中，曾想过等别人写完问问，或是随便完成就好，克服了与你打架的那个自己，那便是柳暗花明。
不停的学习，在本门课程中，很多未知不可预料的问题浮现，又或是新的东西，不停的学习才能激发最深的潜力。
温故而知新。比如之前学过的数据结构，栈、树、图等等，在这次实验中我深深的意识到已经差不多还给老师了，在学习的过程中应该留一些时间来回顾以前的知识。
软件工程难的不仅仅是代码，还有较多的工具及文档。善于利用工具。
多实践，开阔视野，掌握新技术。应当多去了解新技术并且自己来实践它。真的收获了很多东西。
黄浩 201731054221
（1）请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。
要求：请回望第一次个人作业，你对于软件工程课程的想象和提出的问题。
链接到以前提问题的博客
尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的
是否产生了新的问题？请提出。
对于曾经提的问题的回答
现在的回答：曾经自己认为书中提到的“大作业”无新意。在结束本门课程后，自己也感受到了，本门课程更加注重的是软件过程，其次才是创意和技术。本门课程也应该是旨在让学生感受团队的工作流程。
这个问题提出于自己实际结对编程之前。在结对编程后自己有了更加深刻的体验。首先，结对编程的两人应该是技术相近或者有一定的差距，但是这个差距也应该是在可以接受的范围内的。否则一个技术很强的人和一个刚入门的进行结对编程也毫无意义。因此结对编程的应该是有一定的前提的。
这个问题，其实没有什么意义。无论程序员个人的性格是如何。团队总是要大于个人的，因此团队对于个人指出的问题应该是需要及时的听取和改正的。
对于这个问题，当时老师进行了一个回答和举例。我认为一个产品的是否让人感觉值的推广，不仅有初期的市场还有未来的发展前景和盈利。因此，初期市场和未来的前景都决定了产品是否能够被推向市场、是否值得推向市场。
新问题：
在整个课程的过程中，我们进行了很多的尝试。团队的协作，项目的编码和管理。但是感觉和实际期望中的还是有很大的差距，和多时间都是碎片的，没有时时刻刻都在进行项目的推进和管理。所以感觉整个过程很复杂和难时时刻刻的关注。
（2）经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
在本次的课程中，学习最有体会的应该是GitHub的使用和项目版本的管理。虽然以前也会使用GitHub，但大多是停留在clone and download。很少会将一个项目放上去，多个人协作开发，一步步的更新迭代。在这个过程中也体会到了GitHub的好处和方便。
第二个便是学习了很多软件工程中项目的图，流程图，数据流图等。作为软件工程的学生，学习了这些对于自己观看软件工程的书籍和论文有种很明显的帮助。
（3）课后感受
通过这门课程的学习，最明显的感受便是使用GitHub对项目的版本管理和协调以及团队的协作和相互的学习。以前都是各自为政，自己干自己的模块，最后发给一个同学进行整合协调。这种方式十分的低效和不方便，不同的同学编码规范和习惯不同，导致了很多问题。在本次课程项目的开发中，我们提前开始进行规范的制定，大家使用同一个编码规范，然后将代码上传到GitHub进行管理和整合，使得我们在整合管理代码时变得更加的便捷和高效。
4.团队资料留存
（在进行搭建环境时，需要注意网盘里面的参数资料）
其他资料留存（百度网盘二维码）：
