网页版：
https://github.com/qrtt1/Notes/blob/master/20190127_OnJobTraining.md
看标题是写
> [心得] 带新人的感想
本来期待的是讲述关与引导技巧与心路历程的文件，
但选了几篇看大部分在讨论新人合不合适的心得。
我会把这个主题重新订为 On Job Training，
而越初级的工程师得需越多的介入，
接下来提到的具体方法都是可以调整的，
因为每个引导者都得自己面对自家的新人，
实际状况如何我并不知道，得在现场自行调整。
回想起第一次带新人的情境，那时写的是标准的 Java Web，
使用着当时流行的 Framework 东西虽然不算太复杂，
但回想起来要新人在一个下午听完内容，又不打瞌睡实在有一点难度。
当时的架构可以参考这篇：
https://www.ptt.cc/bbs/Soft_Job/M.1419871653.A.224.html
那时大致就是从无到有加 1 个新的功能的解说：
1. 怎么建出后端相关的 Service 与 Dao
2. 数据库与 Entity 的属性对应
3. 怎么开始实作 View 那一层的事情 (再对到 jsp)
4. 怎么写 test case
时间挺赶的，这是因为当时我的角色是离职后，
回去打工协助新同事熟悉专案开发。
虽然后来的同事都天生神力，花一个下午吸收了部分，
再透过网络上几回问答与跟其他同事互相讨论后就上手。
老实说，这要运气很好，遇到程度不错的同事才有办法这么做了。
不过，日子在走，我们不能光怀念那些有血轮眼的新人们，
只要涯职够长，总是会遇到些需要给些等待的新人。
面对需要如养植物般照料的新人，得有较高的介入，
至少得出手干扰他们进入迷航的时间。
## 开启对话
我相信大部分的引导者都有与新人保持若干程度的对话，
而不是多数文章中只写了给了新人哪些指令或回应
（这只是写文章时，忽略了对话的部分，并非对话不存在）。
在这里特别提出是因为针对引导新人的部分，这是极为重要的一环，
因为我们无法知道别人怎么思考，除非他愿意跟我们说他怎么思考某一件事的。
尽可能和善点，不然很多东西你是听不到的。
像我这们些随着 Extreme Programming (XP) 年代起步的开发者，
很习惯地会自言自语写程式 (Thinking out loud)，
是个极好的开启对话的方式。
一般实作、示范著，一边把眼中看到的事物报导出来给你的同伴听到。
虽然，新人一开始不太习惯这么做，或是觉得害羞而不这么做，
但多做几次就会习惯了。多数情况是不知道该讲什么，这也没有问题。
通常我会采用边示范边录影，让新人回头自己找时间模仿我录一次，
我回头再找时间看一下，并给出 feedback。
让学习者录影是我这二三年最喜欢的方式了
(背后的心理学意义就不太是本篇的重点就略过它呗，
如果你需要 keyword：后设认知)，
它有许多面向可以 feedback：
1. 同步术语(term)，因为新人来自不同的地方，
过去的学习材料可能会有不同的术语在描述同样的事，
透过回顾我们可以要求他使用团队习惯的术语
2. 练习带入情境的描述。基本的要求就是避免使用‘代名词’，
当我在重播录影时，只要听到这个、那个、这段 code，
但又没有进一步说明时都会要求在下一版剔除。
这是在练习怎么陈述事情时，不容易被人误解，
消除容易有歧义的表达方法。
同时，我会比较容易知道，
新人自己有没有概念在哪一个元件或组模下工作。
3. 观察未被提起的部分。有时我们会下意识逃避不熟悉的东西，
这就是个简单的讯号，会试着要求补充或当面讨论一下特别的概念
是否需要补强。
对我而言开启对话基本上就是观察与养成新人必要的流程，
有的人能接受，有的人无法。那无法接受的人，
我只好把他转给其他人去接手呗。虽然，这个互动型式介入性高，
引导者也会比较疲劳，但效果我个人觉得挺好的。
## 具体的项目
我用对话模式贯穿大部分的训练，只是随着新人的成长，
渐渐把介入性高的部分抽离。
除非，我们又要开始学一个还没有人熟悉的东西才会再加回来。
例如：我们很熟了某个东西后，就不会再特别用录影与模仿的方式来做
training，它可能会变成单方面要求新人录影，
再给文字回馈或小小的调整一下。
其实在思考模式与术语同步后，大致上面对面沟通都会理解了。
到这个阶段新人几乎不再会收到需要录制成果的功课。
谈完了互动方式后，我们可以开始来看具体上有哪些建议先做的部分。
首先是由资料流开始理解，若团队刚好有准备 sequence diagram
那会相当方便。假设是 web 服务，我们可以对照着资料流，
透过 debugger 去 trace 资料怎么进来的，途中经过哪些地方，
最后怎么组出 view 再到前端去显示出来。
上述的步骤可能就会遇到些引导者觉得没想过的事：
1. 新人没用过 debugger
2. 新人不知道 sequence diagram (团队先前可能也没有，那就先画一个吧)
3. 新人不知道 http request 到 http response 中间发生的事情
(我们用 web framework 做的那些事)
这大概是在资料流走访过程中会有的典型问题，
都是适合用‘对话模式’来处理的，‘解说、录影、反馈’
一直修到理解的品质可用，理解力不要太差的话，
应该修个二三个版本就会上手了。
有时我们遇到的新人，未曾使用过 debugger，
那他可能无法理解 step into 或 step over 是什么意思，
这时要追加一点补充材料，可以单独要求他录制 debugger 功能示范。
像先前我就找到一个有趣 call stack 介绍影片：
https://www.youtube.com/watch?v=5xUDoKkmuyw
而 sequence diagram 的部分，尽可能以‘元件’或‘模组’
为单位去展示资料流，新手工程师来说，太细节的内容容易迷路。
这东西的意义大致上是游乐园入口那个比较粗略展示里面有哪些设施可以玩的
导览图就行了，未来有得是时间去看细节的内容。
在一站一站展示的过程中，得点出我们的 code 是加在哪边。
## 设计概念
这里设计是指架构层次的，尽管多数的团队都有用现成的 framework，
但还是有些得自行实作的部分。或是由规格需要而产生的设计，
这部分是需要特别介绍的。
虽然‘资料流’会经过它，
但资料流的过程是在导览，而非深入某个特定的设计。
这个部分比较多是在辅助新人理解 design pattern 的部分。
这里提的 design pattern 并不单纯指的是书上列的那些，
而是我们怎么演化成目前的实作，
主要在让新人习惯 open-closed principle 的概念。
有些经典用来刻 framework 的 pattern 当然是必备的，
如 template method pattern。我们会试着把目前的‘实作’展开成不用
pattern 的型式，那挺容易的呦，就只要一直 copy & paste 就行了。
接着，我们挖出程式的 extension point，让 hook 成型之类的。
因为书上的内容，大多比较静态，真的体验过一次后，
新人内心的敏感度会提升不少，也比较能养出看既有程式码的品味。
只有极少数的情况会单独讲 design pattern，
多半会搭著 issue 与规格的定义，来看某些 module 或 class
是如何用上哪些 pattern 的。有时不只是 pattern 也会搭上语言的特性，
而形成了目前这样的实作。
## 实战
如果想单纯知道新人的 coding 能力，那只要排 utility 给他写就行了，
但这样子的参与感与成就感会比较小一点，
因为他的贡献没有直接与团队产出有关。
一开始可以这么排，但最终还是要面对真实的 issue 才行。
真实的 issue 又可能压力太大，那我在真正给实际 issue 前，
会试着用影子 issue 来指派。
所谓的影子 issue 就是，让新人与我平行解同 1 个 issue。
但我会事先说明这 issue 大致怎么解，需要加哪些 code，
而它的 test case 是哪只程式。
因为我比较熟悉一点，无疑问地，当然我会先完成实作。
这时新人可以选择继续埋头苦干，或是看一下我的 branch 里写的内容。
通常落后 1 天之后，我会鼓励来看一下我的实作，
他若理解了那就能完成他的那一份，若不理解了，我们再来讨论盲点。
经验上影子 issue 只要一二回就能上手了，
只要下一个正式的 issue 是同性质的，新人应该可以没有障碍地完成工作。
渡过了影子 issue 时期，接下来又是另一个漫长的 tuning，
特别是 branch 的习惯，与 commit 的习惯。
新手常可能弄成一大包才 commit，这样我也很难 review，
这个得一直沟通才会变得比较好。
后续就如同一般工程师的 code review 往来而已，
没有太特别是针对新人的事了。(因为，他已经 qaulified 囉)
## 结语
除了‘对话模式’之外，其它的选项没有特定的顺序，
看情况来决定要用什么。当然，这是针对真正比较‘新手级’的工程师才需要。
如果是比较资深的，那直接来 code review 搞定会比较快
（其实也不会直接到 code review，而是先由实作 planning 开始，
请他透露一下计划是什么）。
也许这些东西看起来很花时间，但这是个值得的投资。
因为我对于 Programmer 的基本观点：
> Programmer 是个稀缺资源，会在各个公司之间流通。
> 不管会在目前的公司待多久，
> 目前是好的是坏的都会影响着未来自己就业环境是否舒适。
大家都喜欢跟专业的人一起工作，如果在带新人时细致一些，
我们就能让未来更光明些。同时，我们也有责任去剔除不合格的人。
training 不起来的人，当然得跟他说实作他真的不适合做这行。
快想点别的出路吧。