过去一年，莫名其妙成了全职的编程培训师。大概是天注定，唉。最常遇到的新手问题就是，请问如何入门 XXX 技术。当然，对我来说，写 Rails 都快十年了。这这个领域东西还真难不倒我，抄了家伙就干已经是我这几年的风格。

不过我一向蛮有实验精神的。为了要能够回答这个问题，我特地去重学了新的编程语言（ Ruby Motion ），来近距离观察重新拆解我十年以来的学习反射性动作到底是什么，来写一份给新手的参考指南。

Step 1 : 建造时光机

我在学习新技术时，会用到两个东西。第一个是 Git，第二个是 Redmine。

Git

git 是新手的时光机。我认为如果一般人学习任何编程语言，甚至写任何笔记，都应该上个 git 版本控制。起码看你上一次写了什么东西。其实 git 一开始也不用学太多指令，练习以下几个就够：

git init （初始一个 Repo）

git add [档案名称] （将某某档案加入版本控制）

git commit -m “储存讯息” （将这次要加入版本控制的档案，写入历史纪录）

git checkout -b “新分支名称” （ 如果要实作一个蛮巨大的实验性功能，我通常会开一个 branch）

git checkout “分支名称” ( 切换不同分支 ）

git push （推送变更到远端做一次备份，通常是 Github）

git pull 拉下远端的变更

主要是将做过的东西，“每一个 interaction 都做一次备份”，让自己知道当初为什么做了这些变动。

Redmine

Redmine 是一套专案管理系统。不过在这里我是利用它的“树状 ticket 系统”去规划我的练习。

我运用的方法如下：

大致切出第一层，我觉得我想要练习的主题

然后中间要是有遇到难题，大概 30 分钟解不开，我就会“放弃”，然后开另外一张票，隔天心情比较好再回来学

中间我要是觉得“有个功能实在太棒了”，我应该可以来做。忍住，开出另外一张票，下周再来做。

每一张 Ticket 我拿来记几个东西：

我这次找到了哪些 link（几乎是一 google 到一个疑似可以用的资源，就 copy 一份）

这次这个功能写了哪些 code。（是的，我不止 git 记了一份，redmine 上还复制了一份）

这次我做了哪些改动

我之前的“错误做法”，为什么错了。bug 的原因是？

为了解 bug 所找到的 * 资源

我的 redmine ticket 记这些东西，每张非常的详尽。（不是指笔记做得好，而是指这当中的过程，我把每一步几乎都录下来）

这样做的好处是：

我不会分心，专注在我当初想练的主题上

我不会被鬼打墙的 bug 打击到自信心全无

我不会被自己一时的成就产生的“傲慢感”牵走

把每一步包括 bug 都录下来。bug 的产生以及解法，其实是“重要的知识”。因为 git “往往只会保留正确的结果”，而不会保留你 debug 的结果。然后下次自己还是会掉进同样的坑里面。

Step 2：挑选合适的主题，熟悉基本工具

在无数篇自我的学习部落格我都曾经提到过，在自学过程中保持一定的“成就感”是很重要的。最近，我把我多年来练习题目做了一个总结，找到了一个模式。

超级新手：

一个“单一功能”，CRUD 的练习。

先做 R 再做 C 再做 D 再做 U。

完整做完一轮，搞懂怎么样让这个专案会动的基本因素与语法。

（注意，这个系统内只有“自己”这个用户）

新手：

以下按照顺序

除了 CRUD 外的三个功能

这个系统内只能有 1 个角色，通称“使用者”。

登入系统

套版

加上一个外挂功能

部署

（这个最实际的例子就是 TODO + 使用者注册 + 套版 + deploy）。这一系列做出来，起码可以让一个人至少可以熟练这个系统的最基本工具，而不太容易绊倒。

中手：

第 2 个角色

开发者认为的 10 个重要核心功能

至少加入 3 个外挂

权限

介接一个第三方 （学会读文件）

之所以会建议这样做的原因。是我发现每当建议新手自己找题目练习后，他们自己想的题目反而变成了灾难。

说灾难的原因是因为他们挑选的题目带给了他们浓厚的挫折感。而这当中最核心的原因在于失控的 scope。

而 scope 的最主要的控制变因在于“这个系统里面有几个？操作角色”。很多人会忽略掉一个重要的事实，开发系统里面多“引入一个使用者角色”，这个系统的复杂度就会成“等比级数上升”。

举个例子来说好了：

一个匿名论坛，大家可以上去发表文章。

一个实名论坛，大家必须要登入才能发表文章。

一个实名论坛，大家必须要登入才能发表文章，“并且针对它人的文章留言”。

一个有管理员的实名论坛，管理者可以任意删除大家的文章以及留言。发文者也可以砍掉自己文章底下的留言。

这四个例子的功能数量是“等比级数的上升”。而一旦新手挑的题目，系统内角色多于 1 人，基本上就注定“打挑战级难度被王打死”。

而我一向的学习方式，都是会尽量让难度可以控制在自己“开开心心学习”的程度上（每次逐步加重，而不是一开始就被灭好玩）。我知道唯有己有成就感地学习，学一门技术才不容易中途而废。

Step 3：将 Redmine 的笔记整理成技术文章

在学完这整套技术后，我会在适当时机，把过去的笔记写成一篇技术文件。视情节发布给同事或给部落格读者。

比如说这个专案如果是跟同事协作的，我会在拉 pull request 时，附上快速的一篇 getting started 。

如果是这个技术难度比较高，用一篇 getting started 的方式很难让对方快速掌握，我会至少做一份 newbie guide ，让想学的人，透过 guide 带练至少一次快速冲到新手等级。

因为 redmine 上当初的笔记非常得详细，在看这些笔记与 git 的时候，我当时的记忆就会被唤醒。甚至上面有现成的 code example 可以直接拿来改编。

而把这些笔记整理成技术文件与指南非常有帮助，因为“写作”这件事可以帮助我从此把这门新技术“想通”，而且烙印到大脑里面。

总结

以上的步骤，最后可以总结成三个重点：

建造时光机，与录下自己学习的过程

做有成就感的题目，透过控制“角色”去控制复杂度，在头两个循环就掌握到基本工具，而且做出有成就感的东西。

重新复习，写成文章，内化成自己的架构。

分享给大家。

文章转载自 开源中国社区[http://www.oschina.net]