忙与担子的三月和四月

事情

　看git仓库，在3.10号有一个文件管理器的项目落实在我头上，开发了大概10天后就交给其它人去维护了。我开始着手一个IM即时聊天的项目，这个项目因为其它人已经给我做了框架搭建，主要的服务器登陆以及各种接口都给我封装好了，只要我去填界面就好了，主要是一些回调接口的填写。
　之间接手了一个公司的落地解决项目，MMI相关测试工具的编写，技术难点是JNI的使用和逻辑层面的理解和权衡。这个case做的比较蛋疼，因为和实际的项目牵扯着很大，简而言之，就是写的东西很直接地很快地影响着很多手机，心情就比较慌张了，代码写起来没那么单纯。本来就两个函数，测试和升级，就是几个if和else。

经验

　代码要可以测试，通过测试。对于不断出来的用例，要自己积累一下，写完代码，自己在对应情况再测试一遍，然后再发版本。因为公司比较重视，所以经理也经常来问我，因为写的代码没有都是由当时脑袋想出来的，所以有时候经理拿一些样例来问我，我并不能给出确切答复。
　编码版本用git来管理，重大节点一定要原模原样地马上commit，对外版本要注意用本地文件夹来进行管理，特别是发出去的一些小文件。这些在定位客户问题和反查代码的时候是很有用的，一开始给了客户一个完整的工程包，这个是完整的日志记录，后来因为是给方法，所以直接给了一个java文件要求对方覆盖，这时候git记录的节点就不能完全对应，不能确定是否和对方的整个调用关系和反馈结果一样，所以可以在发文件的时候用本地文件夹进行一个记录。我这边就感觉有点混乱。
　出了问题，要把问题剖开，控制变量法。对于某个可能影响的因素，隔离开，用其它方法进行一定的压力测试。比如考虑线程和activity的影响，那么就直接在界面中用button来点击获取。考虑java上层和JNI调用的影响，那么直接在adb中执行命令。这样层层测试，从上层java-JNI-驱动层-硬件，逐步去做，上一步没问题了，再对下一步进行分析，毕竟直接对下层进行分析的成本是比较大得。对于机器出现的现象，一定要抓到典型现象，当出现多种现象时，一定要针对现有的资源(机器)进行充分协调，不能就抓到一台然后就报告，要有验证性的分析，是系统版本的影响，还是次品率，看看错误的日志以及内核日志等，有没有正常的，便于之后定性分析。
　调研项目时，即使是干着最基层的活儿，也要对大体性的东西有一个基本了解，除了直觉观还要有一个大局观。去工厂看看基本情况，就是代表部门出一个人，然后对于出错的情况进行一下分析。不是那么简单地，除了自己专业，其它基础的数据也要有一个分析，比如这次装了多少台，在我们出来的时候有多少台不良，这个是作为基本数据要知道的，其它比如手机用的什么CPU，内存多少，什么样子，有哪些特性NFC指纹5GWIFI？，用的什么材料，有什么新特性，用的什么系统等等。而不能只是对工厂错了的进行一下分析，错了怎么错了，换个程序看看，正常的是不是继续正常，用程序分析一下，要有一个对比。
　有基本的安全意识。有些东西是涉密的东西，有时候因为技术的问题私下里交流下，但是如果一旦被有些人士不小心商业应用到，就成就了别人，坑了自己。传闻酷派，有内部技术人员拿了一张技术图纸想到家里面研究一下，但是出门被检查到，然后被公司以意图窃取公司机密给告了判了半年。你是经手人，交接人，担保不是那么好做的。特别是有些你看着简单，但是实际上如果里面牵扯到了商务，那就有文章做了。即使是公司内部其它人员使用，那也是他们去拿机器去做。