很久没有更新博客了，最近一直也不知道在忙啥。说好的android项目一直启动不了，自己也在打酱油的看着内核的书籍，关键是看不太进去。今天打开邮箱看到一位看了我博客的网友来问我之前我发的东西的问题，所以才想到我原来还有一个博客，原来我之前也有写博客。
手上一个项目，从去年开始一直到今年的昨天还在零星的改动着，虽然除了很多的衍生版本，但是基础还是有些问题。主要还是对于功能的考虑不是很全面，一些界面的显示总是考虑不到，会有遗漏，只有在测试发现后才会去修改。这也许也是作为一名菜鸟该犯的错误吧。
菜鸟做项目，又是一个手机的整套MMI, 马上这个项目就要进入生产的阶段了，也顺便来个自我的总结。
首先，在技术层面上讲，这个工作对于技术的门槛很低，但是要做好又的确很高。手机MMI的编码工作，只要是学过C的都可以做，但是不一定能够做好。 发现问题是可以通过修改代码去改，对于一些地方的修改，不行就用全局变量去控制，而这直接导致最后整个代码上全局变量一大堆。这就是菜鸟改代码的方法，从眼前的利益出发，只想着解决这个问题，从不考虑以后的扩展以及联想类似需要修改的地方。而菜菜鸟的改动就更加绝了，不仅仅是考虑眼前，还自己否定过去，最终导致改了这个出现了那个的问题。所以对于一个入门之后的MMI的工作者，应该做的是能够从长远的角度出发，真正站在一个系统的角度上，去考虑各个功能模块可能的相关联，对于类似的模块是否可以做成一个基础模板以供以后的扩展。这也就是那些书里常说的动手之前先想好，从体系结构的角度去想问题。
其次，在沟通层面上讲，这份工作既然是做MMI，那就必然会与客户（这里的客户包括测试人员，我们的测试人员也会根据他的测试用例来提出一些操作习惯上的需求）进行沟通讨论。在沟通上很重要的一点就是如何应对客户的变更。典型的例子就是：在工作中你会发现客户前一次沟通说这样做，可是当你这样做了后，客户那边的另外一个人过来说，这样做不好，我们应该怎么怎么做。这个时候，就需要发挥我们的沟通能力了。在这里分享一个同事给我的经验，作为一名开发人员，在客户对于目标不明确的情况下要去引导客户，对于我们觉得改动起来困难的地方，要尽量去说服客户不要去改动。当然如果真的是很明确的需求，在沟通无果后我们还是要硬着头皮去做的。
最后，在时间的安排上来讲，对于MMI的工作，涉及到多次的编译和下载，每次编译和下载都会用掉一些时间，而且多次的编译和下载也会让自己觉得很烦。那么我们在工作中就要竟可能的做到，将可以在模拟器上模拟的操作，一次性的都全部改完，再进行整机编译和下载验证。还有就是遇到问题的处理，这个我觉得也属于时间安排的问题。遇到难题我们是花时间去搞定呢，还是先去修改别的Bug,这是一个很重要的时间分配的问题。公司作为一个盈利性质的单位，不可能给我们太多的时间去做研究，所以解决问题才是关键，如果遇到暂且不能解决的问题，还是及时上报并跳过去做别的事情来得很实际些。
最后分享一个自己的工作经验：那段时间天天在调试摄像头，因为那个摄像头拍着拍着就会出现死机的情况，看异常的报错显示是内存爆掉了，内存不够。然后就去找原因，首先想到了会不会是在某个循环里面出不来了？在每个可能出现循环的地方就加调试语句，然后去复现，但是发现没有死在循环中。对于摄像头的那段代码，因为是属于第三方摄像头的IC公司给的代码，别人也一直说他们的代码在其他的平台上调试了没问题，怀疑我们的平台给的内存太小，然后就去改内存栈的空间，竟可能的给它一个大的空间。改完后又去验证，还是会复现，然后摄像头的IC厂就说是我们平台所限了，他们无解了。后来我们就觉得既然他们说是平台的问题，那么就上报给平台的提供商吧，那边听到我们上报了问题，他们也很积极就派人过来协助了。
供应商的支持人员过来后，第一句话就是说，我们写的代码太乱了，习惯很不好，没有按好的编码风格来写代码，看的很难受。 然后跟我说教我如何去排错，最好的排错方法就是，列出代码的流程、以及每个分支可能出现的结果。就这样我们按着每个分支的流程去走，考虑了每个分支的最坏的结果，最后发现原来是他们IC给的代码中竟然对一个已经释放掉的指针进行了赋值操作，而那个操作是在摄像头出现异常的情况下的才会走那段流程里去。所以才会在大量的拍摄后出现这个问题。
事后想想这个问题其实也不难啊，正是由于对驱动的畏惧感，以及对于IC厂商的信任，所以一直没有仔细的去看过那些他们给的代码，所以才会出现这个束手无策的情况。 所以代码编写还是要按能给别人看的代码的要求来对要求自己，而遇到问题呢，也还是不要畏惧，仔细去看代码去解决问题。
一口气说了那么多话，都是自己工作的经验之谈，希望没有让各位看客见笑。