经验 | 初学者注意这几点，可以少走一些弯路！

Posted 2022-11-30 嵌入式大杂烩

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了经验 | 初学者注意这几点，可以少走一些弯路！相关的知识，希望对你有一定的参考价值。

大家好，我是杂烩君。

时光匆匆，杂烩君也毕业好几年了，也是一路从小白走过来的，现在有一丢丢小经验。今年作为应届生导师，带了一位应届生，与他相处的这几个月时间里，看到了他的一些不足之处。

想想以前刚入行的自己，也会犯类似的错误。我觉得这些问题挺有代表性的，在这里把这些问题抛出来，大家可以看看自己有没有犯相同的错误，及时纠正可以少走一些弯路。

阅读代码

1、阅读代码之前没有先弄清整个项目的框架

这位新来的小伙伴，一上来就开始看代码，哪怕我已经把相关的系统设计文档已经发给他了。他没有仔细阅读，对各模块的功能也不是很了解。所以，刚开始看代码时一头雾水。

公司里的项目，往往都是很多人一起开发的。参与公司的项目开发，无论我们最终分配到负责哪个模块的开发，在去专研那个模块代码之前，都很有必要先了解这个项目的总体框架。这个项目实现了什么功能，由哪些模块组成？哪些硬件模块？哪些软件模块？各模块之间是怎么交互的？

只有了解了这些，我们再去做某个模块时，能更清楚的知道我们负责的模块要做什么，才能更好地开发好这个模块。

2、阅读代码时没有把握住主线

对项目整体框架有一定了解之后，我让他去看上层的业务逻辑模块，因为业务逻辑模块直接跟产品功能挂钩，看懂这个模块就可以很好地了解我们产品的功能。业务逻辑作为最上层的模块，下面一层好几个模块都对其服务，对其提供了很多接口。

这位小伙伴一开始看代码时，从第一个函数开始往下阅读，遇到嵌套好多层的代码，也一层一层点进去阅读，好像要试图看懂每个函数、每行代码，最后越看越懵。

我们在阅读某个模块的代码时，尽量沿着这个模块的主线去阅读，沿着主线尽可能快地弄清这个模块做的事情。

本模块可能会调用了其它模块的接口，而且可能还会嵌套好几层函数，我们只要大概知道这些接口实现了什么功能就可以，先不用一层一层地看、先不要去纠结其实现的细节。等我们弄懂本模块之后，日后对其它模块感兴趣再去仔细阅读其具体实现也不迟。

3、阅读代码时没有及时做一些总结笔记

这位小伙伴全面阅读某个模块的代码时，没有做一些自己的学习、理解记录，这就会导致看了后面部分，又忘了前面部分。

我们刚开始切入某个陌生的项目，并且代码量比较大的情况下，在阅读代码的过程中，很有必要做一些阅读笔记，便于自己反复阅读（有些代码不看好几遍可能理解得不透彻）的时候加深一些理解。

做笔记得方式可以是写一些注释描述、流程图、思维导图等。

学习、工作习惯

1、遇到不会的没有及时做笔记记录及学习

这位小伙伴刚开始对一些git常用命令及Linux常用命令不熟悉，我演示过几遍之后，后面再用到的时候，让他自己操作他也还不会。

我们刚开始参加工作时，需要一些很常用，但是又不能马上掌握的知识点要及时的记录写来、多用，直至掌握。特别是一些流程、步骤之类的，要记录下来、然后多操作几次，操作次数多了，就熟了。

我们做技术的，还是要有写文档、写总结的习惯，这会加深我们对某些知识的理解。写出来的技术总结，如果自己愿意，可以发到网上，或者自己本地存档。

2、总想一次性把基础补好

刚开始时，这位小伙伴整天阅读某个学习网站学习C语言知识。以前，我也有这种想法，但是我觉得你只要看懂C语言语法、知道if、else、for等，就可以直接去看项目代码了，从项目代码中去学习C语言的知识，项目代码中，遇到不会的C语言知识，针对性地去查资料进行学习，这样印象反而会更深一些。

其实看代码也可以分这么两种情况：

C语言基础比较差得情况下，阅读代码时可以先不管这些模块都实现了什么功能，就盯着这个模块用到的C语言知识，遇到不会的C语言知识就去查资料学习。
C语言基础比较好的情况，就可以看这个模块的具体实现及内部机理。

写代码

1、写代码之前没有思考清楚

刚开始时，这位小伙伴拿到工作任务时，还未想清楚就去写代码了，导致在开发的过程中，反复地进行修改。

在接到一个开发任务时，我们首先要弄清楚需求并大致想清楚整体的实时流程，至少要保证大的方向没错，否则一上来就去编码，这可能会做很多无用功。

2、写代码不注重编码规范

可能是在学校时养成了不是很好的编程习惯，导致他没有及时地改过来。我们业务自己开发一些小项目时，可以有自己遵循的一套编码规范。

但是，与他人协同开发一个项目，还是要尽量跟着项目遵循的规范来进行编码，特别的，在某个模块里添加代码时，最好参照该模块的编码风格进行编码，这样至少可以保证整个模块的风格是统一的。

3、写完代码没有检查

以前在学校，考试的时候，老师常常强调答卷做完了要仔细检查检查。同样的，我们软件开发中，平时写完代码，也有必要检查一下自己写的代码，看看有没有比较明显的编码错误，否则等到调试阶段，出问题可能要找半天。

比如这位小伙伴某次写case时忘记写break了，出问题了，他很懵，还觉得问题很奇怪。

分析问题

1、遇到问题没有仔细阅读问题说明

我们遇到问题时，要尽可能地去查找原因。特别的，有些问题是有一些比较明显的问题反馈的，比如编译错误、git冲突等。这也是这位小伙伴目前比较欠缺的，遇到问题常常忽略掉问题的提示。

2、遇到问题不会加一些必要的日志定位问题

平时，开发调试，遇到问题是很正常的事情，有时候加几条打印就可以定位到问题的所在，却一直盯着代码查半天。特别的，刚接手某个模块，对这个模块不是很熟的情况，可以多加一些日志打印，可以很好地帮助我们去理解该模块。

3、容易被问题的表象迷惑

好几次，遇到问题，他跟我描述问题都是：xxx可以正常运行，xxx不行，然后怀疑xxx出了问题。

我们平时遇到问题，还是要有理有据地去定位、分析问题，不能瞎猜。更不能害怕问题，我们要清楚，遇到越多地问题，解决越多的问题，我们成长得越快！

以上就是本次的分享，如果觉得文章有用的话，麻烦帮忙转发支持，谢谢！

注意

由于微信公众号近期改变了推送规则，为了防止找不到，可以星标置顶，这样每次推送的文章才会出现在您的订阅列表里。