iOS问题总结（怎么预发不必要的bug）

1. 程序设计评审（对需求和程序设计的预演和验证）感觉目前这个步骤在实际执行过程中缺失，项目评审目前感觉就只是开个会而已（就从我接触的红包评审，上午10点多把需求发出来，下午就开始评审，我感觉自己就还没有理清楚这个业务逻辑，还不能在提出这个业务逻辑在代码实现中存在哪些问题）之前的做法是 至少前一天把需求文档发给开发，给开发足够的时间对需求和程序设计的预演和验证（我们当时的做法是画流程图，通过流程图能够很方便快速理清楚业务逻辑，和产品业务具体到代码实现的存在哪些问题），然后在会上讨论，哪些需求存在问题，改如何解决 ，又有哪些问题需要其他人配合的，预估一下开发时间。（为什么非要强调开发自己画流程图这个步骤，如果开发自己不理清楚需求业务前提下急于开工，这样做往往得不尝失，导致后续bug很多）

2.从实际写代码来说尽量编写可阅读性高的代码，有良好阅读性的代码，错误代码隐藏的可能性较低，有助于降低Bug产生的可能性。清晰的逻辑，统一的风格有助于提升代码的可阅读性。（之前在24小时看到 不同业务模块混到一个组件，具体到某个功能代码，业务逻辑比较混乱，写的比较粗糙，方法功能复杂臃肿，重要功能或者逻辑比较绕到方法注释比较少（特别是一些特殊的实现思路和一些需要别人知道的细节，这些必须写详细能够让别人一眼明白的注释），一眼看不出写的逻辑是什么，相互依赖比较深 ，这样很有可能改代码影响其他模块功能（比如因为修Bug而导致新Bug），还有警告太多）

3 在开发中就介入内存泄漏检测工具MLeaksFinder和检测帧率的YYFPSLabel工具，这样会在代码写的过程把因为内存泄漏 和卡顿的问题避免掉

4. 增强自测环节（这点其实在开发理清楚产品业务的前提下），根据你自己模块的流程图自测，虽然花点开发时间，但是尽早的发现问题，bug越早改动也就越好改，成本越低， 之前在51 如果测试反馈某个模块过多或者bug 过于明显就能自测出去，测试可以打回的你提测

5 Code Review （如果项目比较着急 这一步也可以放在提测之后），之前在51的时候基本上一个模块其实是两个人负责，一个是主工程，一个Code Review 的，在他正式提测之前，Review者需要花点时间看他的代码，一个帮忙找出他代码的错误和优化代码互相学习，还有一个是通过验证程序设计了解她的业务模块。

6 bug分析，在开发中如果碰到了一些难解决的bug或者通用的bug（其他模块也有可能回遇到的bug），会在团队的每天早上站会跟大家分享并且记录下来，这样大家都会知道这种类型的bug。

7  模块开发完成后 应该尽早的进入自测，自测完成之后通过之后应该尽早给另一个模块负责人的Code Review ，Code Review 通过之后应该尽早的给测试测，不需要非得等到其他模块完成一起提测，代码越早发现 修改成本越低

8  在上线前用OCLint工具静态分析 

OCLint可以发现这些问题

.可能的bug - 空的 if / else / try / catch / finally 语句

.未使用的代码 - 未使用的局部变量和参数

.复杂的代码 - 高圈复杂度, NPath复杂, 高NCSS

.冗余代码 - 多余的if语句和无用的括号

.坏味道的代码 - 过长的方法和过长的参数列表

.不好的使用 - 倒逻辑和入参重新赋值

9 项目上线前应该对正式环境提交上线的包 进行testflight （一般会有一个checklist 检查）

10.代码重构，由于历史原因，之前写的代码不是很好，但是担心改动引起其他问题，导致不敢改动，也也就无法对旧的代码整理和瘦身，这样子很容易存在隐藏的比较深 或者偶现的bug，后续被测试测出来之后还不太容易改动。之前在51的做法是 如果这个模块在大的版本改动比较大或者一个模块下的独立的子view新的需求变动明显比较大，能够预估这个模块会被测试详细测试，就直接弃用原来的（或者只是参考原来的一部分代码）按照新的代码规范要求写新的