工作中最让开发者头疼的是测试人员提出的一列列bug，比这个更恐怖的是有bug在测试阶段没发现，到了生产环境才暴露出来。如何减少测试人员的提出的bug量，还有避免到了生产环境才暴露出bug，就需要从各方面下手，我这里就简单谈谈编程习惯的问题。

   首先不可否认的是任何程序都会有bug，bug出现的原因有很多，关键是能够快速地修复过来和正确地应对客户的反馈。有时候开发者技术够硬了，却没有一个良好的编程习惯，导致出现意料不到的bug。个人就编程习惯来一个抛砖引玉，简单地谈一下，希望大家多多指教。

1.数字计算的问题。用基本数据类型进行数字计算时，如果是整数类型的还好，但浮点型的计算会出现精度的误差。所以苹果也提供了相关的类，NSDecimalNumber。这里不做相关的介绍，大家可以搜下这方面的资料。

2.异常情况的处理。iOS比android有一点好那就是空指针不会抛异常，当然异常并不止程序的崩溃，还有逻辑上的异常，以及边界值的处理。比如网络连接不上，网络超时等都要特定的提示显示给用户。或者imageview的比例和所要显示的图片的比例是不同的，还有label的文字过长。这就要求开发者在设置autolayout时尽量不要把控件的宽度和高度固定死，以及在开发时模拟特别的数据。还有弱网络的处理，很多情况开发者连着公司的Wi-Fi下运行程序看起来很正常，但用户的网络很差的时候会出现意料之外的情况。开发者真机调试时可以在手机设置－开发者选项里面模拟弱网络的情况。

3.默认值的处理。当页面所需要的数据没有要显示什么？开发时要想好这张情况的处理，不然就显示空白页面很难看。有时候新手觉得自己按照需求那种页面开发出来就可以了，但到了生产环境，出现了情况就是你的问题了。

4.不要轻易修改已经封板的代码。很多时候项目开发时比较紧，所以代码写的比较烂，比较乱。然后上线后有可能很闲，整天没事做。有的人看不惯就来一个重构，这样可以显示自己有多牛逼。这样的做法是错误的！不管你代码之前有多烂，多乱，如果经过测试人员测试没问题的话，请不要修改它！如果真的要修改，那你修改后请提交给测试人员测试，不要相信程序员的自测！

5.关于copy和paste的问题。有时候一个变量可能有多个地方使用，为了方便会不断的copy和paste。然后别的变量也复用这个过程。这时候突然漂亮的测试mm跑来叫你和下午茶（一般都是程序员去叫漂亮mm喝下午茶），或者旁边的伙伴在手机上看到不可言喻的东西，发出嘿嘿的叫声分散了你的注意力。然后悲剧就发生了，你copy和paste的变量没改过来。提交完之后就彻底忘记了，然后就测试提了bug自己还觉得不可能发生这张错误，仔细一看代码就觉得没眼看。

6.黄色警告。编译时除了错误，还有黄色的警告。有时候新手觉得编译没错就行了，这些不影响运行无所谓。然后有时候致命的地方在这里。尤其是通过这个方式performSelector发送消息时，编译时不会报错。还有你所引用第三方的静态依赖库的版本比你项目的Deployment Target高的时候，编译时也是警告而已。

7.添加文件到目录。一般添加图片或者第三方的源码时一般是先复制文件到项目的文件目录下，再添加到项目。这样避免项目移植时缺少文件。

要确保产品少出bug，避免出现生产上的bug，除了编程习惯，沟通也是非常重要的。

有些问题可能是因为沟通不及时导致的，如：1.有可能对需求的理解不够，所以就需要开发者认真地阅读需求文档，不懂就要问清楚，或者觉得不合理就要提出建议。注意工作交流场所一定是公司的会议或者公司的内部通讯群。有时候不一定说服得了业务，或者业务是一个风情万种的熟女，拥有傲人的曲线和迷人的笑容。而开发者往往骚闷的很，内心的小九九让他不好意思和业务发生争吵。OK，记住，无论怎么样，你一定要依照文档行事，业务漏了某点，你在工作的交流场所向他反馈了，他没更新文档的话，那就是他的问题。

2.项目架构的不合理，这个单独开发的新手往往会出现这个问题。所以在开发之前需要认真的想一想，多在技术论坛问问老人，比如现在这个论坛就很好。不过无论在什么论坛，老手一般都很清高，不屑回答简单的问题。这时候你要做的可以注册个帐号，把头像换成一个美女，性别也改为女的，说不定收到奇效。

3.项目周期的问题，有时候项目时间很紧，紧到你裤子掉到地上都没时间提上来。这时你需要向你的老板哭诉了，要他增加人手。虽然很大可能老板不吊你，但至少大家都有心里准备了。

这个原因还有很多很多，不管怎么样，开发者要确保自身没沾屎，够硬朗。