大家好，我是杂烩君。
时光匆匆，杂烩君也毕业好几年了，也是一路从小白走过来的，现在有一丢丢小经验。今年作为应届生导师，带了一位应届生，与他相处的这几个月时间里，看到了他的一些不足之处。
想想以前刚入行的自己，也会犯类似的错误。我觉得这些问题挺有代表性的，在这里把这些问题抛出来，大家可以看看自己有没有犯相同的错误，及时纠正可以少走一些弯路。
这位新来的小伙伴，一上来就开始看代码，哪怕我已经把相关的系统设计文档已经发给他了。他没有仔细阅读，对各模块的功能也不是很了解。所以，刚开始看代码时一头雾水。
公司里的项目，往往都是很多人一起开发的。参与公司的项目开发，无论我们最终分配到负责哪个模块的开发，在去专研那个模块代码之前，都很有必要先了解这个项目的总体框架。这个项目实现了什么功能，由哪些模块组成？哪些硬件模块？哪些软件模块？各模块之间是怎么交互的？
只有了解了这些，我们再去做某个模块时，能更清楚的知道我们负责的模块要做什么，才能更好地开发好这个模块。
对项目整体框架有一定了解之后，我让他去看上层的业务逻辑模块，因为业务逻辑模块直接跟产品功能挂钩，看懂这个模块就可以很好地了解我们产品的功能。业务逻辑作为最上层的模块，下面一层好几个模块都对其服务，对其提供了很多接口。
这位小伙伴一开始看代码时，从第一个函数开始往下阅读，遇到嵌套好多层的代码，也一层一层点进去阅读，好像要试图看懂每个函数、每行代码，最后越看越懵。
我们在阅读某个模块的代码时，尽量沿着这个模块的主线去阅读，沿着主线尽可能快地弄清这个模块做的事情。
本模块可能会调用了其它模块的接口，而且可能还会嵌套好几层函数，我们只要大概知道这些接口实现了什么功能就可以，先不用一层一层地看、先不要去纠结其实现的细节。等我们弄懂本模块之后，日后对其它模块感兴趣再去仔细阅读其具体实现也不迟。
这位小伙伴全面阅读某个模块的代码时，没有做一些自己的学习、理解记录，这就会导致看了后面部分，又忘了前面部分。
我们刚开始切入某个陌生的项目，并且代码量比较大的情况下，在阅读代码的过程中，很有必要做一些阅读笔记，便于自己反复阅读（有些代码不看好几遍可能理解得不透彻）的时候加深一些理解。
做笔记得方式可以是写一些注释描述、流程图、思维导图等。
这位小伙伴刚开始对一些git常用命令及Linux常用命令不熟悉，我演示过几遍之后，后面再用到的时候，让他自己操作他也还不会。
我们刚开始参加工作时，需要一些很常用，但是又不能马上掌握的知识点要及时的记录写来、多用，直至掌握。特别是一些流程、步骤之类的，要记录下来、然后多操作几次，操作次数多了，就熟了。
我们做技术的，还是要有写文档、写总结的习惯，这会加深我们对某些知识的理解。写出来的技术总结，如果自己愿意，可以发到网上，或者自己本地存档。
刚开始时，这位小伙伴整天阅读某个学习网站学习C语言知识。以前，我也有这种想法，但是我觉得你只要看懂C语言语法、知道if、else、for等，就可以直接去看项目代码了，从项目代码中去学习C语言的知识，项目代码中，遇到不会的C语言知识，针对性地去查资料进行学习，这样印象反而会更深一些。
其实看代码也可以分这么两种情况：
C语言基础比较差得情况下，阅读代码时可以先不管这些模块都实现了什么功能，就盯着这个模块用到的C语言知识，遇到不会的C语言知识就去查资料学习。
C语言基础比较好的情况，就可以看这个模块的具体实现及内部机理。
刚开始时，这位小伙伴拿到工作任务时，还未想清楚就去写代码了，导致在开发的过程中，反复地进行修改。
在接到一个开发任务时，我们首先要弄清楚需求并大致想清楚整体的实时流程，至少要保证大的方向没错，否则一上来就去编码，这可能会做很多无用功。
可能是在学校时养成了不是很好的编程习惯，导致他没有及时地改过来。我们业务自己开发一些小项目时，可以有自己遵循的一套编码规范。
但是，与他人协同开发一个项目，还是要尽量跟着项目遵循的规范来进行编码，特别的，在某个模块里添加代码时，最好参照该模块的编码风格进行编码，这样至少可以保证整个模块的风格是统一的。
以前在学校，考试的时候，老师常常强调答卷做完了要仔细检查检查。同样的，我们软件开发中，平时写完代码，也有必要检查一下自己写的代码，看看有没有比较明显的编码错误，否则等到调试阶段，出问题可能要找半天。
比如这位小伙伴某次写case时忘记写break了，出问题了，他很懵，还觉得问题很奇怪。
我们遇到问题时，要尽可能地去查找原因。特别的，有些问题是有一些比较明显的问题反馈的，比如编译错误、git冲突等。这也是这位小伙伴目前比较欠缺的，遇到问题常常忽略掉问题的提示。
平时，开发调试，遇到问题是很正常的事情，有时候加几条打印就可以定位到问题的所在，却一直盯着代码查半天。特别的，刚接手某个模块，对这个模块不是很熟的情况，可以多加一些日志打印，可以很好地帮助我们去理解该模块。
好几次，遇到问题，他跟我描述问题都是：xxx可以正常运行，xxx不行，然后怀疑xxx出了问题。
我们平时遇到问题，还是要有理有据地去定位、分析问题，不能瞎猜。更不能害怕问题，我们要清楚，遇到越多地问题，解决越多的问题，我们成长得越快！
以上就是本次的分享，如果觉得文章有用的话，麻烦帮忙转发支持，谢谢！
由于微信公众号近期改变了推送规则，为了防止找不到，可以星标置顶，这样每次推送的文章才会出现在您的订阅列表里。
猜你喜欢：
嵌入式设备AP配网实例分享
嵌入式Linux单板连接飞燕物联网平台
分享一种灵活性很高的协议格式（附代码例子）
嵌入式大杂烩周记 | 第 16 期
嵌入式大杂烩周记 | 第 15 期
访问非法内存为什么不会出错？
嵌入式大杂烩周记 | 第 14 期
分享几个实用的代码片段（第二弹）
分享一种你可能不知道的bug定位方法
分享一种修改配置文件的方法
《嵌入式大杂烩周记第 13 期：lz4》
《嵌入式并行多线程处理器，了解一下！》
《分享一种修改配置文件的方法》
《分享几个实用的代码片段（附代码例子）》
《废旧板子再利用：搭建无线调试环境！》
《嵌入式段错误的3种调试方法汇总！》
《简说TCP通信非阻塞接收（附代码例子）》
《TCP通信常用接口的使用封装》
《嵌入式软件中，总线错误的坑？替大家先踩一步》
《分享嵌入式软件调试方法及几个有用的工具！》
《分享两点提高编程能力的建议！》
在公众号聊天界面回复1024，可获取嵌入式资源；回复 m ，可查看文章汇总
