Coursera 上经典课程Learning how to learn 第一周。

第一周的内容总体框架总结了一下，见思维导图。另外有几个点想要着重的记录一下。

重复/练习

课程中提到了大脑有两种主要的记忆系统，一种是工作记忆，一种是长期记忆。工作记忆存在的时间非常短，并且容量很小。当我们解决思考一些问题的时候，我们一般会在工作记忆中进行操作，有可能在这个过程中从长期记忆中载入一些以前学会的知识或模式。

跟工作记忆相比，长期记忆的有巨大的容量，能够存储非常多的内容。当我们尝试把一个短期记忆转化成长期记忆的时候，一开始记忆在长期记忆中行程的模式是比较弱的。我们需要重复的去访问长期记忆来加深这个模式，来提高这个模式以后被记住的概率。这个就是我们所谓的熟能生巧。

长期记忆的行程有点像肌肉的形成，需要的不是短时间内的大量训练。而是训练一次，然后休息一段时间，在训练，在休息。这个叫做Spaced Repetition。

从某个角度来说，长期记忆基本上就是一个人所掌握的知识和技巧所存储的区域。当我们学习一件事情的时候，如果说不能够做到把这些技能和知识存储到长期记忆里，那么就意味着以后需要用的时候你很有可能会想不起来，可能会重新经历一遍短期学习的过程。这个不就完全浪费了之前的时间了么？

所以我认为，当我们决定去学习一样东西的时候，就要做出把这个东西学透，让它成为自己大脑的一部分。否则就不要学了，反正学了也忘记了。另外一种方法，我觉得可以通过学习以后多次作总结来帮助把自己的记忆通过文字的形式持久化下来，从而加速下次回忆的过程。

<!– more —>

锻炼/休息

课程中提到，当我们做一些创造性或学习新事物的时候，大脑处于发散状况会更加的有助于我们的学习。而让大脑切换到发散状况的方法主要是放松、锻炼等方式达到的。同时锻炼还能够帮助我们的大脑产生新的神经元，这也会帮助我们保持一个清醒的大脑。

今天读到了一篇文章《Gitflow有害论》， 虽然文章的标题有点极端，但是其中的观点还是很有价值的。结合工作中使用git的一些感想，谈一谈我对于使用git的workflow的一些想法。

Gitflow

在这篇文章之前并没有认真的看过Gitflow的整个流程，一开始使用git的时候看到过这个流程，但是由于过于复杂而且大家对git都不大熟悉，所以没有采用这个流程。

从我个人的经验来看这个Gitflow，有下面几个很明显的坑。

1. 某一些feature分支的时间跨度太大，这会导致一个很严重的问题就是当这个feature分支回到develop的时候可能会产生很多冲突。而且这些冲突可能涉及到业务逻辑层面，需要额外的工作量去fix。而且这个过程往往很纠结且容易出错。2.
2. feature时间跨度太大的另一个坏处就是pull request会变得很大，一个很大的pull request往往会让review的人很头疼。很容易让代码review的人忽略其中隐藏的一些问题。

除了这两个比较大的坑以外，关于release branch和master branch的分工，我觉得添加了很多工作量和复杂度，但并没有带来明显的好处。

Github 的flow

github的flow其实非常的简单，详见：Understanding the GitHub Flow，GitHub Flow。

从文中可以看出，这个workflow里只有两种分支。一种是master 分支，这个分支是高质量可以随时部署的分支。另一种则是feature分支，即功能开发的分支。开发完以后直接通过Pull Request的形式回到master。

可以看出github的flow非常的简洁明了。但是我觉得采用这种flow有两个大前提：

1. CI能够在Pull Request阶段覆盖大部分的测试案例。

2. 项目必须是类似于github这种web的项目，可以进行频繁的产品部署。并且能够迅速的修复发现的问题。

我认为理想的git workflow

我认为没有一种放之四海而皆准的workflow，一个项目所采用的workflow其实主要取决于组织的文化和产品的特点。

我认为一个好的workflow应该满足一下几个条件：

1. 只有一个master分支，不需要develop分支。
2. 有一个良好的持续集成环境，能够对每一个pull request进行验证，确保其通过所有的测试。
3. feature分支要尽可能的小，如果没办法确实需要做很多改动的话。那么就当完成一部分可以work的代码的时候，发出Pull Request。将这一部分先回到master。这个主要是为了让Pull Request更精简，让代码冲突更早的暴露并解决。
4. 对于客户端的应用，release分支不可避免。拉出release分支的时候如果有一些不需要的功能或未完成的功能通过一些技术（Feature Toggle，Branch by Abstraction）来将其屏蔽。
5. 当release分支中有bug的时候，在master上做修复，并cherry pick到release分支。如果无法cherry pick，则手动修改。
6. release版本后在release分支上打上tag以便日后的hotfix。

我这里提到的这些点跟《Gitflow有害论》文中提到的Trunk Based Development工作流其实有点像。但是我对于这个Trunk Based Development还没有研究透，不敢妄下结论。

文中还提到了一下技术：Feature Toggle，Branch by Abstraction。看了给出的链接，有点粗浅的认识，改天深入的去仔细阅读一些这些技术。

离上次写博客已经是很久的事情了，记得很早以前就看过关于写博客的好处，也自己写过文章阐述过写作的各种好处。但是最终还是没有坚持下来，其实回头想想但是也并没有说想要坚持写作，只是觉得写文章确实是一个帮助整理思路的好办法。

这个时代是信息泛滥的一个时代，很多道理我没会在各种各样不一样的场合看到，但是并没有卵用，为什么？因为道理往往很简单，你其实做不到。这个跟旅游很像，当你还没去一个地方的时候看过很多照片，看过很多游记，你可能觉得你已经很了解这个地方了，但是当你真正去到那个地方的时候你会你自己的感受。这种感受不是你看再多照片，读再多游记能够感受到的。这就跟你看再多别人总结出来的道理和经验都是没用的，因为你没有自己亲身实践过那些道理和经验就不是你自己的。

废话不多说，也不做无用的计划，just do it。接下来我会坚持写一些技术上的学习心得，翻译一些有趣的外文文章，读书笔记，生活上的一些想法等等。通过输出的方式倒逼自己做更多的输入，做更多的思考，把一些无序的思考转化成有效的思考，让自己的思考更加的有深度。