如何学习？如何KT？抓住核心概念 --- 特斯拉软件开发实习小结

记于2022/7/3，那时还在北京特斯拉做软件开发实习生，转眼一年都过去了，how time flies

入职特斯拉也快两周了，写一下期间的所思所学吧。

我认为如何学习，如何做KT，关键的一点就是抓住核心概念。

BTW，KT(Knowledge Transfer)是我入职后学到的一个词，知识传输说人话就是教别人，把你的知识传输给别人。

Background

从第一周交接上一个实习生任务时的手忙脚乱，到现在慢慢的对工作内容的熟悉也有时间空闲下来思考总结了。实习工作内容和入职前说的不一样，入职之前原本和我说的是使用c#开发，搞得我还提前一周学习了一下c#。结果入职之后的开发工作是使用公司现有的平台，将业务逻辑写成JSON格式的数据上传给平台来生成对应的系统，基本上用不上任何c#，最多可能内嵌点JS代码（这个底层平台系统听说叫元模型系统？感觉还挺有意思的，有待进一步了解。）虽说和我的预期差别还是挺大的，但就这两周熟悉这个之前完全没搞过的、非严格意义上的软件开发工作的过程中我还是有一些关于如何学一个新事物的方法的想法要记录下。故这一次就写写关于如何学习的想法，技术相关的以后会单独另写的(?)。

Objective

我入职第一周的任务就是接替上一个实习生(A)做的门店索赔系统开发与用户支持工作(support)。我现在回想起来觉得这个任务又可以分解成三个小方面：

1. 熟悉系统的业务场景与功能
2. 熟悉系统的开发流程以及每个人(尤其是你的)扮演的角色的责任范围
3. 了解如何进行开发工作

系统业务场景与功能

现在梳理下来看，该系统的业务场景不复杂，就是在特斯拉门店发现零件异常(比如损坏呀，少发呀，发错呀等)情况时，门店(SC)会填一个工单向零件来源也就是区域分发中心(RDC)发起索赔，之后由区域分发中心根据情况做出判断该并做出相应的处理。这个系统的功能也很简单，就是生成工单来控制整个业务流程。另外还有一个系统负责区域分发中心向更上一级的分发中心(PDC)发起索赔的，其业务场景和功能几乎一样，只是中间的业务流程可能会略有区别。

这样总结下来整个业务场景和系统功能都十分清晰的，但当时A在给我做交接工作的时候却把我整的云里雾里的，始终get不到这个十分简单的流程，直到我的mentor给我看了一张整个SC->RDC->PDC的层级关系图，我才豁然开朗。现在回想起来我觉得的原因是：A在介绍时没有抓住核心概念。回看上一段中，整个业务场景中的核心概念有哪些？我会选<门店>，<分发中心>，<流程>。首先<门店>，<分发中心>是业务流程的主角也是系统的使用者，而<流程>是系统的目的–对索赔流程控制。我认为只要抓住了这几个概念，整个业务场景就十分清晰了。业务场景的其余部分都是可以被这几个核心概念描述的细节：比如分发中心审批就是<流程>中<分发中心>的一个动作。

而A的介绍之所以让我不能理解，我认为原因是在还没有介绍清楚这个几个核心之前就过于深入细节了，没有核心概念的支撑，细节好像就是孤儿节点无法与现有的知识体系图连接起来。

写到这，我就感觉到应该给“核心概念”这一个概念做出一个定义。

我认为核心概念应该是与场景/域中其他细节概念紧密联系的概念，一组核心概念可以衍生出该域中其余所有（或至少是大多数）的细节概念。

我的理论是：一个知识域就好比一个图，一个概念就是一个节点，而一组核心概念则与该图中任意一个节点是可达的。如果一个概念要被人所接受，则概念所链接的核心概念组一定也被人的知识域覆盖（必要而非充分条件）。

是否已经存在过类似的模型？待调研，可能方向之一：知识图谱。

角色职责