2.8 其他快速入门必要知识

完成入职后，大家首当其冲的就是开始开始接触各种真实产品。真实产品一般都跨越多个学科，需要大家快速补充各学科基础知识。而且新人入职后，还需要尽快补足各种基本职场技能，如写作、演讲、交流、出差、安全等。因此，在新人刚入职后的一段时间内，快速入门成为新人的主要任务，更是负责人的职责所在。

职场，没有无缘无故的“速成”，所有的能力都需要水滴石穿的积累，但却可以 “快速入门”。本节和大家简要分享一些我们团队常用的快速入门课程。

2.8.1 快速产品学习

快速熟悉产品，我们习惯采取三板斧策略：说明书——产品测试——工程现场调试。

说明书需要面对客户，在大多数公司都算是一份比较正式严谨的文档，因此，以阅读说明书开始了解熟悉产品，是比较好的策略。实际情况下，大多数人即使读了几遍说明书，可能也不熟悉产品，甚至根本就读不进去。因此，这个阶段，不要过于急于就成，只要保证大家通读一遍说明书就可以了。

为了让新人快速熟悉产品，我们祭出了第二板斧：产品测试。该处的产品测试是指对内测试，又称集成测试，对应文档基本上是测试用例合集，用于指导产品交测试组前对功能覆盖测试。

让新人一开始就对产品进行完整功能覆盖测试是不现实的。为了减少测试工作量，我们团队仅在大版本定版后，进行完整功能覆盖测试，如果仅修改一些现场反馈bug，仅对产品的基本功能进行快速测试。这份快速用例测试清单，可以帮助新人快速熟悉产品。

我喜欢给新人安排一些测试类工作，这样做有如下几方面的好处：

1. 老人大多不喜欢做测试工作，经常因态度不端正而产生各种纰漏，新人态度比较好，工作容易调度。
2. 新人因不熟悉产品，测试时不会受限于各种固化假设，反而容易测出一些边界问题。
3. 结合测试用例和代码审核，可以帮助新人快速熟悉代码。

闭门学习比较枯燥，但一次真实现场的工程调试就会唤起大家的激情。工程现场调试不同于在家慢慢折腾，一堆人围着，你不能快速定位并解决问题，立马能体会到压力。

工程现场非常考验一个人的定位和解决问题的能力。为了具备这样的能力，需要新人熟悉产品内部的工作机制，熟悉各环节检测点，熟悉各类问题的发生概率等。如我们团队的微机保护产品投运时，要对设定值进行动作测试，但加电气量后设备不正常动作出口该怎么办呢？

保护产品出口动作内部流程如下图，内部整个工作流程为：电气量输入——基础过流元件判断——脚本——驱动出口回路。

熟悉内部流程，我们就可以通过各检测点快速定位问题，如通过电气量检测定检测输入问题，通过元件检测点判断元件定值和闭锁条件，通过脚本输出模块检测出口回路等。

扫描二维码关注公众号，回复： 9003704 查看本文章

一些产品工作机制比较复杂，流程冗长，逐一的确认各检测点几乎不可能，此时就需要依据概率快速定位。如该类实验中，采样和出口接线最容易出问题，我们是否可以先验证这两个监测点呢？甚至，如果你工作经验丰富到一定程度，在投运实验之前，先期进行采样和出口回路测试，就能大幅度加快现场调试进度，将关键节点从自己移到别人身上，我们去围观他人去。

我们习惯将工程现场最常见的各种问题整理到“说明书——调试说明”一章中，此时，在指导新人重读这一章，大家不仅积极性提高了，也会有新的体悟。

三板斧用完了，大家也都熟悉产品了。

2.8.2 C++快速入门

在嵌入式领域，最常用的语言是C语言和C++语言。比起C语言，C++语言的语义丰富了许多，还有boost、stl等各种优秀库加持，便于构建大型应用。而且，很多嵌入式产品都需要一些外围软件，用于维护、配置、调试等，此时C++也有一席之地。

相比于C语言，C++语法扩展了很多倍，知识点繁杂，学习困难。新人一般可以在较短时间内掌握C语言，但大多人学习C++时都比较痛苦。为了缓解这一现象，我们团队将最常用的C++语法提炼出来，构建成C++入门课程，主要包括三部分内容：

1. C++是更好的C

从C++的角度重新思考C，是学习C++语言很好的契合点。不仅可以认识到C语言的缺点，也能探索到C++语言的发展脉络。

在该过程中，最典型的莫过于布尔变量的演化史了。早期C语言，没有明确的布尔类型，因此用整数类型int代替，并约定0为假，其他都为真。这样的约定可能带来程序隐患，如一个简单的++操作，就完成真假转化。

在C++中，为了规避这个问题，定义了bool类型，并增加了两个内建的常量：true（转化为整数1）和false（转化为整数0）。如果将其他非零值赋值给bool类型时，会自动转化为true和false。

借鉴了C++中的成功经验，在后期C语言的发展中，如C99规范，增加了_Bool关键字，定义了该变量仅可以为0和1两个值，如果存储的类型为非0值，则会自动的优化为1。为何定义_Bool这样诡异的关键字呢，主要是因为大量的程序中已经有了bool的typedef定义，需要考虑兼容性。

当然，为了书写方便，在C99规范中，也增加了stdbool.h头文件，该头文件包含如下内容：

#define bool		_Bool
#define false		0
#define true		1

此时，C语言中布尔变量的用法就几乎完全等价于C++语言了。类同于布尔类型，以C++的视野重新审视一遍C语言，或许不仅C++入门了，C语言也更上一层楼了。

2. 类的基本概念

相比于C语言，C++中最大的变化莫过于引入了类的概念。在新人培训中，我发现大家单纯理解类的概念并不困难，但常常会因为一些思维模式未转变过来而犯错。这个过程中最典型的莫过于this指针了。

传统C语言是流程化代码，我们写一个函数，可以被另一个函数直接调用。C++不同于此，你写一个类函数，首先应该思考的是这是该类的一个方法，而不是这个函数会被另外哪个函数调用。这是一种思维模式的转变，需要反复思考才能蹚过去，而深入理解this指针有助于突破这一障碍。

另外，引用、友元、运算符重载、构造和析构函数等概念会经常用到，但也是新人容易翻船的地方，尤其是复制构造函数更是重灾区。关于复制构造函数，C++中对象复制默认是逐字节拷贝的，那么，只要逐字节拷贝有问题的地方都需要复制构造函数特殊处理，如指针，如静态变量等。

还有友元，很多新人也容易犯糊涂。大家理解不了为何还需要友元这个东东，实际上理解了如下示例代码，也就真正理解了友元。

int n = …;
float f = …;
char *sz = ……;
cout << n << f << sz;

如果使用运算符重载，需要在对ostream类增加一些列运算符重载函数，而且不具备扩展性。通过友元，就可以将差异化部分下放到具体类中，ostream类也清爽很多，不失为一种架构程序技巧。

void operator << (ostream & os, const Time & t)
{
    os << t.hours << “hours, ” << t.minutes << “minutes, ”<< t.seconds << “seconds.”
}

为了帮助新人快速掌握这些零碎且必要的C++类技巧，我找到了一个很好的例程：《C++Primer Plus》中第12章的string例程。每个人只要认真的重写一遍该例程，就能快速的学完上面提及的诸多知识点。

3. 类继承和虚函数

不同于C语言中的函数指针，在C++中构建框架程序，主要是通过类派生和虚函数机制完成的。如下图：

这是一个典型的程序架构图，由框架程序提供应用程序和主窗口的基类，以及应用程序和主窗口之间的调用关系，如初始化过程中的窗口创建过程。用户程序仅需要构建特定的子类，甚至不需要关心它们之间的调用关系，因为已经被框架程序通过虚函数完成了。

这种架构将可变和不可变分离，让用户仅聚焦特定功能，但也给新人带来理解困局，尤其是刚刚从C语言流程代码中走出来的人。如果能通过类派生和虚函数工作机制，让新人理解其背后工作原理，学习各类C++框架程序会更容易一些。

除了上述这三类基本语义，还有很多零散的用法也会经常用到，如类stl模板库程序。模板算是C++中一个高级且复杂的概念，新人不容易学习。幸好，我们发现真实产品代码中，stl模板库的使用大多是标准化代码，那么将这类代码变成标准代码参考片段不就更好了吗？

至此，虽然我们仅学习了很少一部分C++语法，但大部分程序已经看得懂了，剩下的，边用边学呗。

2.8.3 Qt快速入门

我们团队的所有外围软件，包括配置软件、维护软件等都是用Qt编写的。当初选择Qt，主要有如下几方面的考虑：

1. 大家都比较熟悉C++语言，尤其是一些老员工，有VC++工作经验。
2. Qt功能丰富，尤其是在做一些自动化软件时，有很多模块可直接复用。
3. 工控领域经常有linux环境程序运行的需求。

虽然我们团队最终选择了Qt界面库，但放在整个编程世界来看，Qt依然是一个小众模块，大部分新人都没有学习过Qt。外围软件和设备代码经常是一体两面，如规约最为典型，在小公司，不可能做产品时还给你额外配置一个人写外围软件，而且效率也低，因此我会要求我们团队的每个成员必须熟悉Qt编程。

Qt入门相对比较简单，我们依然是三板斧策略：Qt扩展语法、spreadsheet示例和项目组通用界面程序。

◇◇◇

Qt对C++语法做了一定的扩展，即使熟悉C++语言，初次碰到Qt中的信号和槽机制也会蒙圈的。因此第一板斧就是砍掉这些不熟悉。

信号和槽机制语法比较简单，但很多新人在学习的过程中容易忽视这种机制背后的巨大价值。为了让大家更容易理解，我喜欢让大家仔细比对一个VC界面和Qt界面的区别。就拿最基本的输入对话框为例：

在传统的VC实现版本中，为了实现上面这个输入对话框，需要构建一个类，更关键的是ok函数一定位于这个类内部。如果需要一些特定处理，该类就会成为了一个定制类，毫无复用价值。Qt实现不同，可以将OK函数的实现拉到自己身边（也即调用类内部），界面本身变得非常单纯可复用了。总之，信号槽机制是一种非常好的框架解耦程序技巧，需要在使用过程中细细体悟，而不是仅明白其语法。

大家记得我以前提及的mfc那条陡峭的学习曲线吗？Qt是否也会有类似的问题呢？在培训实践中，我发现这个问题并不绝对。信号和槽机制需要简要理解其背后工作原理，知道生成的一堆moc文件是干嘛的。当然这儿并不推荐大家需逐行阅读Qt内部实现代码，具体实现中包含很多细节，如多线程等问题，容易将大家带偏了，但从整体上简要理解其背后工作原理并不难。

真正理解了信号和槽机制后，拜托其强大的解耦能力，Qt中的其他模块反而比较容易学习，都很单纯，不像MFC中各模块混杂在一起让人无从下手。这也是我不让新人再接触MFC的原因了，哪怕因此毁掉大量已成熟的代码也在所不惜。

◇◇◇

做完基础准备后，快速动手是最佳选择。Qt领域的优秀书籍不多，《C++ GUI Qt4编程》是难得的一本好书。该书的第一部分，详细讲解了一个例程：spreadsheet。该例程采取了step-by-step模式，而且包含基本的界面元素，如窗口、菜单、工具栏、对话框等，非常适合新人自学。

总之，大部分新人学完该例程，已经一脚迈入了qt世界。

◇◇◇

spreadsheet例程虽然很好，但毕竟是教学例程。新人学完，经常会有一种看着别人写程序很容易，但自己却无从下手的感觉。第三板斧我们会让新人直接接触真实的项目代码，以破解这种困局。

为了简化工作量，我们团队在设计维护软件、配置软件或其他软件时，都采取一种通用的界面模板，如下图所示：

整个界面分为三部分，左侧为项目树，右侧分为上下两部分，上半截为工作区，不同功能对应不同的界面；下半截为全局输出界面，用于日志等信息提示。为了便于程序内聚，系统菜单和工具栏中仅包含基本的功能，大部分的功能按钮都位于具体工作区顶部，便于以按钮或工具栏的方式组织。一个典型界面示意如下：

第三板斧就是要求新人快速掌握这种界面风格，这样在后期接触具体程序时，就可以将精力聚焦到具体功能代码，而不再被界面代码所累。额外，在这个阶段，因为缺乏参考资料，新人会被迫开始使用Qt帮助系统，也有助于新人快速提升。

Qt比较容易学习，简简单单的三板斧，很多新人仅仅用两到三个星期，就会完成Qt的快速入门学习。

2.8.4 芯片调试快速入门

搞嵌入式软件开发的，必然要同芯片打交道。目前各学校都会构建实验室，而且还有各种实践活动，学生们直接参与芯片调试的机会比较多。按理说这种现象会让新人更容易入门，遗憾的是理想和现实总是脱节。

在新人身上，我容易体会到两种截然对立的观点。一种观点是认为芯片很复杂，这类绝大部分是道听途说驱动程序员工资很高驱动很难写后，得出的结论。另一类观点是驱动程序很简单，我仅仅是调用了几个ST公司的默认库函数，硬件竟然好用了，驱动好简单。

遗憾的是，这两种观点都是错的。驱动程序不是独立存在的，经常需要放在整个体系架构中反复权衡，不是简单调用ST库就能满足需求的。当然，驱动程序也有其特定的学习方法，只要掌握了正确策略，也没有网络上吹嘘的那么难。

我们团队的芯片调试快速入门课程，就是在尝试帮助新人掌握正确的驱动学习策略。芯片调试采取同C语言快速入门相似的策略：以任务驱动，按需求迭代，靠终总结提升。在驱动调试入门课程中，我们经常采用IIC或UART作为入门示例，难度适中。本小节限于篇幅，仅以uart进行展示。

起始任务：写一个uart程序，使设备和PC之间可通过uart执行echo收啥发啥协议。

如果还记得我以前C语言，就应该明白这个例程中一定有许多陷阱。实际上大部分新人写的程序，或者频繁发送或者大块数据发送，立马就崩了。通过该例子，希望大家意识到驱动程序同常规的程序还是存在很多不同的，如：

1. 缓冲策略是驱动程序中的基本设计理念，常用于匹配不同硬件之间速度差异。
2. 硬件异常了，需要有恢复机制，不能异常后就不管不顾了。
3. uart是数据流，如何封装出上层应用（echo协议）需要的帧概念嗯，有哪些策略呢？
4. 所有的设计都是有边界的，如最大允许帧长，最短帧间隔，接受发送之间的最短间隔等，如何设定。
5. ……

总之，当头一棒，一些列写驱动程序时经常面对的问题，立马会让新人意识到自己是在写一个驱动程序，而不是在写传统pc程序。

◇◇◇

因为查询模式简单，或因为程序比较小巧，第一个版本，大多数新人都会采用查询模式来实现，可惜这种模式没法用到真实产品中。因此，第二个版本一般对应中断方式改造：修改为中断版本时。

中断版本程序中有两点需要特别注意，也是需要新人努力克服学习的。第一点是核对寄存器设置。中断模式相比查询模式，寄存器设置会更加繁杂，出错的概率更高。简单调用函数库快速写代码容易，麻烦的是一旦出现问题根本不知道如何下手去查。此时，需要祭出硬件调试中最高效率的一环：核对所有关联寄存器设置。

目前的芯片越来越复杂，寄存器也越来越多，很多人会怀疑这种策略。但实际上，因为驱动程序内部缺乏强逻辑，设置繁多，其代码很难仔细审核，传统策略反而不好用。大家试想一大堆缩写，你如何审核。实在还不甘心，不妨体会一段我随便截出来的驱动代码，uart中dma接受通道的设置：

/* DMA6通道初始化,用于UART2 receive */
DMAMUX_CHCFG6 = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(6);	/* 6:UART2_RECEIVE */
DMA_TCD6_SADDR = (uint32_t)&(UART2_D); 				/* 源地址 */
DMA_TCD6_SOFF = 0;									/* 源地址调节 */
DMA_TCD6_SLAST = 0; 								/* 源地址最终恢复调节 */
DMA_TCD6_DADDR = (uint32_t)s_rs232Inf.pRxdBuf[s_rs232Inf.wRxWriter].pBuf;		/* 目的地址 */
DMA_TCD6_DOFF = 1;									/* 目的地址调节 */
DMA_TCD6_DLASTSGA = 0;								/* 目的地址最终恢复调节,不调节 */
DMA_TCD6_ATTR = DMA_ATTR_SSIZE(0) | DMA_ATTR_DSIZE(0);	/* byte传输 */
DMA_TCD6_NBYTES_MLNO = 1;							/* 每次触发传输个数 */
DMA_TCD6_CITER_ELINKNO = (uint32_t)BUF_SIZE;		/* 总传输次数,最大缓冲区设定 */
DMA_TCD6_BITER_ELINKNO = (uint32_t)BUF_SIZE;
DMA_TCD6_CSR = DMA_CSR_DREQ_MASK;					/* 传输完毕自动关闭 */

因此，与其反复审核代码，不如直接审核关联寄存器设置，这是一种看似慢，实则快的策略。而且，通过查看寄存器设置，有助于让新人理解嵌入式开发环境，以及同PC编程的诸多差异之处等。

中断程序的第二个要点是需要开始考虑同步互斥问题。中断程序和主程序在不同的执行空间执行，他们中间经常会存在读写冲突。同步互斥问题比较讨厌，如不妥善处理会让程序时而好时而坏，给人一种设备不稳定的感觉，又很难通过测试用例定位bug，只能通过审核逐项分析，费时费力。

唯一幸运的是，中断和主程序之间的互斥比较简单，或者采用缓存机制，或者采用关中断策略，此时切入进行锻炼，会给后期面对多任务程序中的同步互斥程序，打下很好的基础。

中断和主程序之间的缓存机制程序代码示例如下：

/* 采样缓冲区指针 */
BYTE *pCur, *pNext;

/* 采样中断程序 */
void isr(void)
{
	/* 记录采样数据 */
	pCur = pNext;
	pCur[0] = ...;
	pCur[1] = ...;
	...;
	
	/* 下一点采样 */
	pNext += sizeof(...);
}

/* 电气量计算任务 */
void calc(void)
{
	volatile BYTE *pKeep;

	/* 采样指针存在互斥，先缓存 */
	pKeep = pCur;

	/* 基于pKeep进行电气量计算,后续不再允许使用pCur指针 */
	...;
}

上述例程中，当前采样指针pCur在采样中断和计算任务间存在读写互斥，如果在计算任务中直接使用，会因采样中断会频繁修改而导致程序异常。一个简单的策略就是增加一个pKeep缓存指针，对pCur指针进行缓存。

◇◇◇

如果熟悉硬件，驱动程序本身并不难，难得是写出合适的驱动程序，让其恰好的适应框架对硬件的要求。这一点也是很多人感觉windows或linux驱动难学的原因所在。

回到我们的uart例程，如果串口接受以中断方式处理，中断任务会占用cpu多大负荷呢？假如有一个保护高优先级任务，要求最晚5ms必须出口动作，此时以中断方式处理的uart任务能满足要求吗？

实际上，在真实的强实时产品中，根本不允许以中断方式处理uart接受发送。如果uart接受发送中断优先级高于保护任务，会导致强实时任务难以满足实时性要求。如果用更高优先级中断调度保护高优先级任务，会因计算任务大会导致uart中断异常。因此，我们需要第三个版本，将uart里澜城修改为dma工作方式。

基于DMA的版本实现并不难，目的是让新人体悟驱动程序和体系架构那种水乳交融的感觉，有助于后期从事驱动程序工作。如我们的某款产品，需要实现一个基于vxWorks和flash的文件驱动程序。某工程师从网络上找到一个版本，试验后好用，满以为可以交差了。没想到应用层对文件系统存在频繁读写的情况，导致flash很快就被写废了。此时或者重新调整应用层使用模式，或者在驱动层增加缓冲机制，才能达到水乳交融的感觉。

◇◇◇

三个例程都写完了，到了总结的时候了，不过驱动程序的总结同其他存在些许不同。写过驱动程序的人应该都知道，调试驱动程序的那几日，所有的寄存器都能背的光瓜烂熟，但用不了多久，你就会忘记的干干净净，感觉好似白折腾了。

出现这种原因，其主要原因是因为你背诵的仅是一个个孤立的寄存器，没有逻辑，无法内化为自己的知识体系。那么针对驱动程序这个特性，我们应该总结什么呢？

调试各硬件模块之前需要先相关阅读技术文档，这是一项费时费力费眼的工作。初学者磕磕碰碰的阅读数遍，才能理出其中的关键信息。一些经验丰富的工程师，他们不是在阅读技术资料，而是带着问题去查找，拿着自己的uart知识体系去碰撞的。如重新调试一个UART，有经验的工程师会立即问出一大堆问题，如波特率如何设置、最大波特率支持多少、支不支持奇偶校验、是否支持dma、有没有主动帧间隔硬件识别、每bit几点采样、异常判断机制有哪些，……。而这，就是你需要总结的内容。

我们不是去总结寄存器，而是在总结uart的工作机制和特性，这些才能内化为你自己的知识体系。随着你总结的硬件特征越来越多，面对驱动程序工作，自然能随心所欲。

◇◇◇

驱动程序没有你想的那么简单，但掌握了技巧和关键知识点，也没有你想的那么难。此时，你能体悟到这句话背后的深意吗？

2.8.5 算法分析，matlab快速入门

matlab技术是工科领域最常用的数据分析工具，尤其是一些算法仿真模拟。幸运的是，我们团队主要使用matlab进行采样数据分析，仅使用最基本语法和plot绘图函数，因此新人入门matlab比较简单。我们采取的策略是给新人分享一个简单的例程，只要能读懂基本就入门了。

在电力系统，模拟通道采样回路一般为二阶RC滤波器，如下图所示：

其频谱特性曲线如下图所示：

依据频谱特性曲线分析，如果输入50hz的波形，幅值恰好是1，其他频率的波形幅值就会存在波动。因此，不考虑频谱特性，当电气量频率发生变化时，测量精度就会下降。

因此，通过电力系统测试仪分别加45~55hz的电气量，用matlab分析采样数据，获取真实硬件的频谱分布，并进行反向系数补偿，不仅是平时测试准备工作的基础一环，也是新人难得的练手机会。

2.8.6 写必要文档，word快速入门

本章一开始和大家讲解快速入门策略时，就是以word作为例子。word作为工作中最常使用软件，只要有过认认真真写毕业论文的经历，大部分同学都已经可以熟练掌握。

word快速入门学习，侧重于理解word同记事本txt的差别，需要去理解word中的诸多格式概念，如目录、页眉、样式、导航、奇偶页、分节符、引用、分级标题、段落、模板等，以及针对这些概念的基本操作。这些基本操作百度上都有非常直观的演示，步骤详尽，用多了自然会记住。因此，word入门比较容易。

我们团队的所有文档中，产品说明书需要面对客户和付梓打印，因此是格式最严谨，要求最严格的。说明书一般需要多人维护，而且会持续升级。为了防止某人不小心破坏说明书文档格式，我们对所有新人都有一项要求：具备从txt文档恢复说明书的能力。谁破坏谁恢复，不仅在说明书下一任审核时就能截断问题，而且也提升了大家的word技能。

word入门后，我一般会给大家推荐秋叶的网络课程：和秋叶一起学word。这是我目前见过最好的word自学教程，没有之一。

2.8.7 给用户讲产品，ppt快速入门

嵌入式软件工程师并非整日面对电脑与程序为伴。实际上，交流、测试、文档、工程等工作甚至会占去我们大部分时间，如新产品刚推出来，营销人员必然会整日拉着你去给用户讲产品的。此时，就需要你具备连夜赶出一个ppt，并能表达到让客户心动的能力。

演讲类ppt各公司都有基础模板，你只要老老实实的套用，不故弄玄虚弄一堆换页动画，不堆砌大段文字，不搞得五彩斑斓花里胡哨，将要讲的内容整理成条目分重点罗列清晰，就已经是一个不错的商业ppt了。

该处继续推荐秋叶的网络课程：和秋叶一起学PPT。都不用学太多，只要花半个小时，学习一下第一章的秋叶四步美化技法，你做的PPT立马高大上了。

ppt好做，难得的是讲产品的能力。新人最大的问题是没底气，演讲时给人一种不自信的感觉。演讲者代表着产品，演讲者的这种不自信也会传递给用户。如何提升新人的演讲能力呢？我在培训过程中发现有一招特别好用：慢；如果还不行，把ppt备注写详细点就好；如果再不行，多找点人多讲几遍就好了。

2.8.8 总结

本章介绍了一些我们团队常用的快速入门课程，因限于篇幅，都未能详细展开，仅罗列出其关键点。

不知大家是否能够体会到，这些快速入门关键点并不是随随便便设定的，需要有经验的工程师总结自己产品中的通用特征，更需要在新人入职培训中反复迭代改进。

我做咨询活动时，很多老人经常埋怨现在的新人不好学不积极不敢批评等一大堆缺点，我个人持谨慎反对的态度。实际上大多数新人刚迈入职场，学习态度一般都是非常积极的，只是我们没有帮助他们构建入职的台阶，他们被反复打击不得门而入才颓废下来的。

试着将你的工作中80%的常用特征提炼出来，构建成快速入门课程吧！或许这一点点的付出，会迎来你意想不到的惊喜。

——————————————

我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如感兴趣可加个人微信号nzn_xiaomaer交流，需备注“异维”二字。