第一次上车测试

说实话，对汽车电子的软件还不是很了解，本来以为会做一个简单点的demo熟悉开发工具和开发流程，没想到直接被发配到项目中去了，有点胆战心惊的。照着老大的话说，修改软件后要有200%的把握保证你的目的是能够达到的，当然也要保证不影响其他功能模块。我还做不到很有把握，因为其他人是不可信的，这里的不可信不是说同事会告诉你错误信息，而是说本着掌握每个细节的态度，即便同事告诉你可以这是对的，可以这么做，你也不能只停留在“照他的话去做”的层面，自己还是要再实际确认。貌似只有软件文档才是可信的，其实照我们老大的意思，所有的都不信，除了你自己。因为没有人会为你担责任，除了你自己。

第一个项目竟然就是负责软件接口，主要负责在整个软件内为其他组员开发的功能模块寻找可用的接口，一般来说是没有现成接口的，需要自己修改。接口工作开起来简单，但是每一个软件指令的发出一直到执行器的物理动作是怎样的，指令是否会被其他模块的指令覆盖掉，都是需要确认的，这样一来工作量和难度就比较大了，每一个接口都要考察一整条链路。除此之外，还要考虑自己的改动是否会牵一发而动全身，比如说在发动机点火过程中关闭掉喷油会对发动机有何影响，对别的部件呢？

总的来说，上车测试的时候还是有些稀里糊涂的，和学车的时候第一次开车的感觉有点像，什么都不懂，照教练说的做，车就跑起来了…现在跑来做发动机软件开发，还没太搞明白软件架构，写的软件就可以控制发动机了…虽然有点糊涂，但是蛮兴奋的。

从简单开始是很重要的，可以在未知领域快速获得信心，由于种种原因没有能够按照自己的想法了解发动机软件，但是这次上车测试也算是获得了第一份信心，对以后的学习和工作应该是有帮助的。

GPD

GPD是什么缩写也没记住，可能是Goal Performance Dialog，年终的时候，顶头上司会和手下做全年的review，对一年的performance做一个评估，然后和设定来年的工作目标。在和科长做GPD的时候，他和我分享了他自己从软件开发转做销售的那段时间的经历。他说的一点我蛮赞同的：在接触新东西的时候，刚开始就投入大量的时间和精力，拼命学习，至少要把必须的基础知识想办法掌握，避免问一些低级问题，那么接下来的学习和工作就会很顺利。想当初学zynq的时候，就是按照这种方法来做的，除了每天工作时间，几乎所有业余时间也都花在zedboard上面了，当然也和zedboard是借来的有关系。由于本身有些底子，所以花了半个月的时间就入门了，后面的开发可以说是顺风顺水了。

所以打算利用晚上的时间每两天学习一个topic，尽快对发动机的组成和汽车电子常用功能有一个大致的了解。