欧亚之行——关于学习方法的分享
这次自己准备的一个分享步骤：
# 先看图表->提出问题->讲原因->结合实际
* 大家先看一下这个图
* 大家有什么问题呢
* 在看到这个的时候大家可能会有以下疑问
* 我们为什么要有这个步骤
* 我们这里要重点要思考的是
* 我们应该注意的是
只有知道做什么，你才有做好的可能(需求确认)
小组讨论：
比如：为什么要有这么多问题，我们为什么想不到？
- 因为我们在听了老师布置的任务后我们每个人或者和小组内的其他人的理解可能不一致，这时候我们就要讨论一下都有哪些问题，列出一个问题列表，然后去问老师，问组员，问自己。
- 这个步骤主要是：讨论需求
- 重点就是：为什么要给我们布置这个任务，以及我怎么知道我掌握了。
- 起点是在应用我们的学习方法，锻炼我们的各种软技能
- 终点是一个个输出
-
注意的点是：结合自身全面的列出尽可能多的问题
小组讨论.png
老师回答小组确认：
比如：为什么老师都回答了，为什么还要再确认？
- 确保小组内每个人对老师的回答理解都一致
- 这个步骤主要是：确认需求
-
注意的点是：重点是训练我们的学习方法，而不是做完
确认需求.png
技术需求：
-
这个步骤主要是：明确我们都要用到哪些技术
技术需求.png
图形化是为了更好的交流（功能探索）
原型图
比如：为什么要画原型图，它有什么好处？
- 方便和其他人交流，看大家对功能的探索是否全面一致。好处就是让我们把重点放在功能上而不是美观。
-
这个步骤主要是：站在使用者的角度去探索界面的功能
界面原型图.png
事件列表
- 比如：为什么要有事件列表，它的好处是什么？
- 有了事件列表我们就可以清楚的知道每一个事件发生时都有哪些状态的变化，好处就是不会遗漏哪些点。
-
这个步骤主要是：站在使用者的角度去探索事件的功能
页面事件.png
组件图
比如：组件图是什么，为什么要画组件图，它的好处是什么？
- 组件图这个名词并不是 React 里特有的，所有的技术都可以画出组件图，这里对组件图的理解就是把整个原型图划分成一个一个的块，有了组件图，我们就能清楚的知道每个块里面包含什么，组件间的关系也更清楚，方便开发者进行交流。
-
这个步骤主要是：站在开发者的角度去明确整体的结构划分
组件图.png
数据结构
-
这个步骤主要是：定义存储数据的结构
数据结构.png
问题应该划分的足够小（分解任务）
拆分任务
比如：为什么要拆分任务？怎样拆分才更合适？
- 当一个任务很大的时候我们往往不知道该从哪开始，也不敢开始，如果我们能将任务进行拆分到很小的话，我们不仅有了完成它的决心，也有了开始做的动力。
- 开始拆分的时候很难把握粒度，随着开发的进行我们就可以将里面的一些大卡再拆细。
- 这个步骤主要是：将任务尽可能的拆分、细化。
故事卡
比如：为什么这个故事卡这么大？
- 上面常规的几项是一般卡片都会有的，下面的几项是为了锻炼我们的学习方法，为我们养成良好的学习习惯特意补充的。
- 这个步骤主要是：将要做的任务可视化出来
- 重点就是
自学提问图
概念关系图
ＤＥＭＯ预研
业务实现
结对编程
Showcase
技术博客
反思总结
组内演讲
过程记录文档
注意的点是：
- 姓名：知道是谁领了这张卡
- 卡号：方便查找
-
验收条件：可以明确什么才算是做完了，而不会出现不确定或者多做少做
故事卡.png
看板
比如：这个分别都是什么？有什么作用？
- 第一列就是把要做的卡片按优先级顺序排列都贴在第一栏，当你开始做的时候就把卡移到Ｄｏｉｎｇ，等到按着卡片上的顺序都完成之后就可以移到Ｓｈａｒｉｎｇ，把技术博客分享都做完之后才算是真正的完成，这时候就可以移到Ｄｏｎｅ了。
- 有了这个看板不仅能让我们清楚的了解组内同学的进度，也更能激励我们尽快的做完这张卡片。
-
这个步骤主要是：通过看板展示大家的进度
看板.png
先想清楚再动手写（功能实现）
自学提问图
比如：我不会提问？不知道应该从哪方面进行提问？
- 这里我们推荐常用的５Ｗ１Ｈ来进行提问，即就是ｗｈａｔ、ｗｈｙ、ｗｈｏ、ｗｈｅｎ、ｗｈｅｒｅ、ｈｏｗ，比如它是什么？它为什么会出现？应该怎么使用它？什么时候用它等，再继续从答案里面拓展问题。
- 这个步骤主要是：从广度学习一个新知识
- 重点就是：它要解决什么问题？什么情况下应该用它？
- 起点：从本质上来思考它为什么这样用
- 终点：自己通过这个任务总结出来的一些经验
- 注意的点是：
- 不应该只关注怎么使用它，这样思维会局限在比较低的层面，只知其然，不知其所以然，不会举一反三。
-
不能无限制延伸下去，当出现一个新名词，不是这次学习的主要部分时，就应该停下来，或者当自己回答不了的时候，所以一般最后都会停留在问题上
自学提问图.png
概念关系图
比如：概念关系图和自学提问图的区别是什么？这两个图都要画吗？
- 不是都要画，一般是先画自学提问图，在画了自学提问图之后如果里面的核心概念之间有顺序，有先后逻辑关系就应该画出概念关系图来理清它们之间的关系。
-
这个步骤主要是：从深度学习一个新知识里有关系顺序的概念
概念关系图.png
ＤＥＭＯ预研
比如：
为什么要ｄｅｍｏ预研？
- 当你想实现一个功能但是又不会的时候，ｄｅｍｏ预研可以让你快速的集中精力的解决这一个小问题
怎样预研？
- 首先应该新建一个文件，完成后上传到ｇｉｔｈｕｂ，这样不会搞坏现有的代码，而且方便以后回忆。同时还应该上传一个包含README.md的文件，里面应该包含对项目的基本介绍以及运行命令，这样分享给别人之后，别人就会用了
- 这个步骤主要是：集中精力解决一个小问题。
-
注意的点是：整个时间应该在半小时到一个小时之间。如果不能解决，应该再细分。
demo预研.png
业务实现
-
这个步骤主要是：结对－分解任务－估时－写测试－写实现－重构－反思用时－验收检查
业务逻辑实现.png
针对业务实现又进行进一步讨论：
结对编程
比如：
- 为什么要结对编程？
不仅能促进团队感情，还可以传递知识。特别是老人和新人结对的时候，新人会进步的更快。 - 一定要结对吗？
当你遇到自己搞不定的地方时可以结对，如果自己轻轻松松能搞定就不用结。 - 这个步骤主要是：确定合作的方式。
注意的点是：
- 应该是强强结对或者强弱结对，不能弱弱结对，这样会掉入一个坑里就出不来了
- 结对绝不是一个人写另一个人看，看的那个人应该思考的更快，指引那个写的人，他们应该有同步的思考
- 遇到不懂的及时提问
- 定期交换搭档
分解任务
比如：前面都分解过任务了，这块为什么还要再分？
- 前面是将任务分成小功能 但真正实现的时候，还应该再细化具体到每个功能到底应该输出什么
-
这个步骤主要是：将功能细分
任务分解.png
估时
比如：为什么估时？
- 估时不仅能培养时间观念，也是为了完成后通过对比时间的差异，进行反思总结。
- 强迫自己在写代码前把所有情况想清楚
- 这个步骤主要是：对实现的整个过程预估一个时间
- 注意的点是：估时不应该超过15分钟
写测试
比如：
不会写怎么办？
- 不会写就先demo预研一下吧
为什么要写测试？ - 能清楚的知道这个任务的终点是什么，做的那步就算是完成了，同时，防止在实现中随意扩展功能
一定要先写测试吗？ - 不一定，不同的模式有不同的方法。但是写测试很重要。
这个步骤主要是：写出对功能的测试代码 - 重点就是：为什么要先写测试？
- 会让你在写代码之前做好计划
-
它比直接写代码的效率更高
测试.png
写实现
比如：不会写怎么办？
- 先ｄｅｍｏ预研一下，或者找你的ｐａｉｒｓ结对吧，或者Ｇｏｏｇｌｅ。
- 这个步骤主要是：实现功能让测试通过
- 注意的点是：
只要能让测试通过即可
实现的时候不要重构
要保证所有的测试都能通过。
实现.png
重构
* 比如：怎么重构？
就是对代码进行优化，可以是小层面的重构，包括代码格式，命名，函数；也可以是大层面的重构，换种思路等。
# 这个步骤主要是：对代码进行优化
* 注意的点是：重构是不能破坏已有的测试。
反思用时
* 比如：反思的重点是什么？
找出自己的薄弱环节，以便制定出具体可执行的行动，进行专项训练，让改进更有针对性。
# 这个步骤主要是：通过对比时间差异找出不足的地方
验收检查
* 比如：
验收检查很重要吗？
当然重要，可以让我们确认自己做的是否正确。
检查的方式都有什么？
自己检查
运行所有测试
结合之前的验收条件，逐一检查。
# 这个步骤主要是：进行自我确认
Showcase
* 比如：
为什么要Showcase？
能及时发现问题，看功能是否和需求一致
给谁Showcase？
自己的ｐａｉｒ，组内的同学，或者其他同学
# 这个步骤主要是：给大家展示自己的功能、小组确认
* 注意的点是：
Showcase通常１０分钟左右
没有总结经验就没有进步（总结分享）
技术博客
* 比如：
它的好处是什么？
不仅自己忘记的时候可以看，也可以分享给别人
# 这个步骤主要是：将自己学到的技术写成博客
反思总结
* 比如：
经常忘记写怎么办？
可以让ｐａｉｒ监督，一起养成好习惯
不知道写什么？
即使是一句话也应该写出来，让自己意识到这是个每天都要做的事情，具体可以参照下面的模板
# 这个步骤主要是：进行总结、写出经验
* 注意的点是：
每日总结不要花太长时间，半个小时以内。
#常用模板：
每日总结：
经历 -> 站在上帝视角客观的讲述今天发生了什么
学到 -> 将学到的东西逐条列出
感悟 -> 结合自身实际，写出一些可执行的措施
针对一件事的总结：
事件 -> 简单客观的描述一下事件
我想象中的样子 -> 前期的一个预想
实际的样子 -> 实际发生的情况
对结果进行反思 -> 通过对比进行反思
需要刻意练习的技能 -> 找出自己需要练习、改进的地方
总结下一次怎么做 -> 总结相同的套路
组内演讲
* 比如：我不会演讲？
只有多锻炼，才能提升自己的演讲技能
# 这个步骤主要是：锻炼自己的演讲、分享能力
过程记录文档
# 这个步骤主要是：把所有的产出都用一个文档记录下来，方便回忆
在总理提出要带同学去欧亚做分享的时候，按照以前我肯定是不敢参加的，但是这次决定鼓起勇气试试，反正迟早得走出舒适区，早肯定比晚好，我也不想把第一次演讲留给面试官。。而且万一自己讲的很好呢！？Ｏ（∩＿∩）Ｏ哈哈～
开始准备，总理打算以话剧的方式来展现，再老师讲了第一遍以后觉得自己大致都有了了解，第一次排练的时候也是简单的介绍了这个流程是用来干什么的，以及应该注意的点。但是当这种演绎方式进行不下去的时候，大家都很苦恼，就换了另外一种方式，分组到他们中间去讲，应该会更有意思。
但是这种方式对自身考验很大，特别是老师说要一组抽一个人讲，所以有50％的几率可能是我要自己去讲，对于没有在大家面前讲过东西的我来说真的是压力很大，毕竟要50多页，很怕自己讲不好，或者遗漏什么，或者大家完全没有反应等等……
但是作为小组成员，既然我接受了这个任务，我就必须尽自己最大的努力去做好它，所以我找了小学弟陪我练习，我完整认真的看了一遍教材，但有的地方还是不太理解，还是不知道该怎么说。在给小学弟讲完之后我发现了自己的一些问题，比如很容易被带偏，说话没有说服力等等，
最后一次集体演练，我就挑选了自己比较不熟悉的部分讲，除了声音太小，其他的还可以，不太理解的也都找pair讨论，也让自己适应了一下在大家面前讲东西，
出发前又看了一遍教材之后，和 pair 分了任务。走之前有点小激动，但是也有点紧张，因为不知道现场会是什么样子，对方有没有反应等等，但是到了现场 pair 破冰之后就感觉很好，大家都很活跃，所以破冰很重要。
现场的评价
在现场做的好的地方是，积极互动，传达学习方法；
不好的地方就是声音太小，但是整体还是很愉悦的。
总结：
（１）破冰很重要。
（２）在别人讲东西的时候要积极的互动，或者说积极的暗示，多点头，多鼓励，因为每个站在台上的人都会紧张，如果台下有人给予了肯定的眼神，会给讲的人很大信心。
（３）团队要分工明确互帮互助，一定要先自己看一遍，知道哪里会哪里不会再去讨论，而不是一开始就讨论。
（４）组长和老师都很辛苦，组员要多积极配合。
这几句话不仅贯穿在这次的总结中，也将是自己以后学习的准则
先想清楚再动手写。
问题应该划分的足够小。
只有自己写出来、讲出来的东西才算是自己真正掌握的。
