猿创征文｜11年前，完美解决职业生涯的第一个bug，打开了工作新局面

每次回想起来，我总觉得自己足够幸运

初入职场

11年前，我大学本科刚毕业就非常幸运的进入了当时手机TOP2的公司的研究院，成为了一名Android ROM开发工程师。说来也巧，我本是学通信方向的，但分组的时候分到了负责多媒体组里。当时作为几乎没有任何JAVA经验的弟中弟，通过毕业前3个月的实习时间，从mentor那儿恶补了linux的基础知识（这样才能编译服务器上的Android系统），学习了一点点JAVA的皮毛，用着现在看来“极其拙劣”的水平，在通过入职培训（学习企业文化、基本礼仪什么的）后，就上工了。

遇到问题

作为应届本科生，项目组长也没有把什么工作量放在我们这种新人上面。解决各个型号中的bug是这个项目组最基础和简单的工作，所以组长就分配了一个bug给我修改。而这个bug的描述看起来也非常简单：
在X型号平板的Music Player的某一个界面中，出现了undefined，需要进行处理。

回过头看，这个bug的处理方式很简单，顺着xml找到对应的Activity或Fragment，对出参做个判断打个补丁，这个bug就可以结束，交付工作了。

刨根问底

只不过，当我复现问题的时候，发现许多地方都出现了同样的bug，从一个理工科学生的直觉来看，这个问题不应该这么简单。虽然我当时JAVA水平几乎为0（连上下文是什么都不明白)，linux水平也几乎为零（刚学会了一些简单的查询筛选），但当时年轻有冲劲肯学习，我加班人工遍历了所有本项目源码，把所有能发现的同类型问题，进行了一个汇总，并且对代码进行了刨根问底。记得当时正是google收购摩托罗拉的时间点，新的Android代码混杂着不同的代码风格，到处都是漏洞。最终通过2~3天的时间，我顺着APP找到了对应的Framework，从Framework层AIDL找到了底层C（也有可能是C++）的代码，看到了一行数据库输入输出的代码，问题的根源终于找到了。

由于大厂中分工的关系，我没有更新代码的权限。同时，问题发生的地方属于底层团队负责，我也没有修改代码的权限。在和项目组长沟通后，我通过bug提交系统，以及邮件的方式，将问题的路径和发生缘由，发送给了对应团队的负责人。在邮件发出的时候，距离我领取工作任务，整整过了1个星期。

重塑自己

这是我职业生涯中的第一个工作任务，虽然在时间上远远超过了组长和老同事们的预期，但是工作的结果也远远地超过了他们的预期。从那以后，他们不太让我像实习期那样做一些闲杂的工作，在交流的时候也更愿意向我传道受业解惑，一个技术上的bug被解掉，似乎职场里的新秀墙也被同时解决掉了。我不再是给团队拖后腿的那个新人，而是一个能够帮助到团队的新鲜血液，能够充满信心的面对工作中的不同挑战。许多同期进入的同学，后来都略表羡慕，但背后的坚持和努力只有自己知道。

哪怕过了十余年，当我创业路上遇到困难的时候，我依旧记得当初自己死磕bug的模样。保持初心，砥砺前行。

I fix bug, it refactors me.（我解决了bug，bug重构了我。）