正文
四、既要有攻城之力，也要有熬战之气——BUG
产品开发完成后，必然有bug。其实开发人员在工作过程中，是有一定的直觉或者心理预判的，即：某个功能模块的质量如何。 这里面的质量包括：可维护性、扩展性、算法\渲染效率，还有就是bug与崩溃率。
功能开发完成后，就要开始守城了。
bug，一部分产生是由于架构带来的，例如比较复杂的架构，会导致复杂的实现细节；
但还有很大部分bug，其实是基于如下三个原因产生的：
1 . 对于某个api的不了解，或者对于某个平台，或者SDK版本的不了解。 举例而言：andrid里面非主线程，是不能直接处理UI相关的事情的；JAVA的内存释放也不是绝对的，相互指向是无法释放的；函数个数是有DEX问题制约的---------------------这些bug的产生，也是开发人员摸索学习的过程，经历过一次就不会再犯了。这是学习广度与熟练度的问题；
2 . 还有一些bug，是由于粗心大意导致的。例如空指针的问题，野指针的问题。在C的开发中，野指针的问题，GDI句柄的释放问题，这些都是严谨的代码需要避免的； 而又一些工具，或者方法是可以规避这些问题的，例如android中的利用@Nullable和@NonNull加强空指针检测等方法；
3 . 还有一些bug，是由于“使用情况各异导致的”。例如：偶现在某个模块crash。这里的本质还是因为逻辑的异常边界没有处理好。例如android上的OOM问题，还有PC上UI焦点导致的对象释放问题。这些异常情况，一部分靠测试发现，一部分靠用户反馈，还有一部分就靠自己的异常处理。例如Android中的try catch机制，其实就是遇到异常了，你能纠正错误的机会。
五、自审
每过一段时间，都要站在高空俯视自己，问问：到底是在承担过去，还是在改变未来。
如果之前程序代码质量不好，后面修改问题的时间就会比较多。到了开发的中期，得多问问自己，你在不停的改正以前的错误，还是在做新的东西。 如果修改错误的时间多一点，那就要注意自己的代码质量了！
六、注释
我很喜欢写注释。有大牛说：代码就是最好的注释。 可惜我还没有达到那个程度。所以，我会把注释写的非常清楚。其一：为了自己以后维护的方便； 其二：为了其他人接手的方便。
这是我在翻译君项目中写注释的方式。1：对于很复杂的逻辑，务必用12345的顺序依次写清楚；2 ：对于函数中的某个参数，需要解释为什么要设置这个参数，尤其是公用工具类里面的函数---说清楚参数的背景含义，可以让其他调用者理解的更加清晰。
我一般不用英文写。虽然这样看起来格调很低，但胜在大家都能轻松的看懂。写代码不能太傲娇，写注释也不要太傲娇，目的是让你的搭档或者接手者，更轻松的理解，让她/他少加班。
七、代码结构
代码结构要清晰。有按照功能划分的，有按照UI结构划分的。还有公用工具类，有数据管理，有主逻辑控制。不管用哪种思想，有序的代码结构，可以让每个人感觉很干净。好比日本的收纳整理技巧让很多小资推崇，无非就是干净、整洁、便于管理。
而且，还有一个重要的好处：代码结构表现出来的其实是——程序的一个模块\逻辑思想——让大家工作在不同的区域。
八、代码风格
代码风格统一！好比一家人，有叫Tom的，有叫安东尼的，还有叫流川枫、石破天、圣杰夫拉斯基，无所适从。理论上，看一个函数，就能从名称上区分哪些是成员变量，哪些是局部变量，哪些是全局静态值。
除了命名统一外，还有一行代码最大的宽度，函数的连续调用长度等，头文件的包含风格，也最好有一个约定。类的出现时间，创建人名，最好也加上，看起来没用，但到了追踪问题时，就能看出时间线的好处。
九、安全与逆向
这是针对Android说的，还有PC插件也需要考虑。Android上首先要防止被别人逆向，我成功逆向并重新打包过有第一位和第二位的竞品。这似乎有点不可思议，但确实做到了。加固+混淆+代码判断，最好都有。
安全上，可以看金刚扫描的漏洞，逐一修改就行。公司很多工具很好用的！
十、开发效率
开发效率可以用这些方式提升：
1 . 构建公用工具类，方便大家使用
2 . 使用开源的一些包，例如ORM思想的数据库等
3 . 可以很快的找到问题。开发中，找bug的时间，往往是很多的。我用的方法有3个： 使用try catch； 拦截所有crash到我指定的地方；超多的Log，Log有统一的控制开关。
4 . 借力：数据上报用灯塔，崩溃上报用bugly，公司KM上很多经验，拿过来用。
十一、安装包体积
1 . TINY压缩图片
2 . 删除无效的资源文件
十二、UI渲染效率
UI是用户的第一感觉；UI快并稳定，第一感觉就不会差太多；管理好内存，基本管理好了一半crash；管理好UI，等于管理了人机交互感受。
UI上的开发是：渲染效率与渲染效果的平衡。
很匆忙的写的，必然有很幼稚的地方，欢迎斧正。
