近来由于工作太忙，期间几度想撂挑子不干了，后来一想，大部分的让自己难受的事情，其实在一开始就埋下了隐患。
比如延时优化问题，当时那个代码写的那叫一个惨不忍睹，后来自己看着都累的不行，真心不想再维护了，当时作为临时方案提供出去，
早晚要重构的，跑不掉的。所幸的是，这周阶段性的工作算是有了一个不错的结果，使得我可以在此较为心平气和地把这个过程中吸取到的经验和教训也在此一并列出。
1、coding style的问题，CPP还是规范一下用camel case, 比如mName这种。为啥这个放在第一个，因为规范的命名才能让自己有持续下去的动力，否则后面一次又一次地会因为这些小问题而拖底自己的效率
2、常用的一些辅助功能，编到各自对应的小lib里面，模块化便于维护。
3、release给用户的库要尽量少，比如libA是给用户的，后来libA中进行了重构，libA要依赖libB和libC，这时不要让用户去掉libB和libC中的接口，而是把这些封一层还是从libA中提供出去，这样用户还是只要link原来的libA即可。
4、先设计，再写test，最后coding
5、一个patch尽量只干一件事情
6、代码要往平台化的层次去考虑，这个过程可能需要经过若干次重构，这是必经之路。我认为一个人很难提前预知到各种情况，所以我现在也是赞同在需要重构的时候去重构，但是要有充分的理由去做重构这件事。
重构是“优化现有代码的设计”。在本文，优化意味着使之更加易于理解和/或更加灵活。下面的行为都被视作重构：
- 把臃肿的方法拆分成较小的、功能集中的方法。
- 重新命名变量和参数，使之更有意义。
- 把功能从一个类移到另一个类（更加适当）。
- 基于一个类的方法，产生一个接口，然后让这个类实现该新接口。
7、不断扩充自己的常用代码段，提升coding效率，当然不断学习探索IDE提供的功能，也有很大好处，比如trim space和blank line
以及把native文件加入到include解析的路径中，这样可以方便跳转
8、patch先线下检查coding style然后再提交
9、关于log的设计，可以把相关的log前面加上相同的关键字，这样看log的时候可以grep对应的关键字去看，减少干扰。
还有就是log的格式化打印，最好能较为美观的对齐，赏心悦目，一目了然，调试起来也舒服。
10、最好是熟练使用各种debug工具，比如debuggerd看hung的问题, gdb, addr2line查crash，perf看性能, top看内存泄漏和CPU占用
11、真的要坚持多看代码，这样学的才快。
12、不断拓展自己能touch的边界，从自己熟悉的模块不断向外延展，了解自己的上下游做的事情，有时可以整合起来提高效率。
13、什么时候别人会觉得你很靠谱，不论谁问到和你的模块相关的问题，你总是能很清楚地告诉他，并且还有一些注意细节补充给他，这个时候就会感觉到靠谱。还有就是为自己的模块设计一个调试和测试工具。
14、文档要及时更新，这样可以减少一些人来问问题时耗费的沟通成本。
15、选一个方向，开始深挖，比如计算机图形学。
16、全局变量一定是有办法可以避免的，比如可以把需要全局变量的地方挪到一个库中，并通过接口来访问它。当在一个程序文件中看到两个以 上的全局变量时，这个代码中就出现了不好的味道。
17、还有一点要注意，函数名字不要太短和宽泛，这样容易撞库，比如起了个check_result的函数名，就很容易撞。不暴露的就声明为static, 养成好习惯
18、学会使用各种图来表达自己的设计，比如UML类图和时序图就比较常用，也方便和他人交流。