测试不是程序员的救命稻草

测试人员可能是公司专职的职员，也可能是项目经理，也可能是你的老板，你的客户，所有在产品未发布上线时使用你的产品的人，你都可以认为是测试人员，包括你自己。

对于程序员来说，如果不懂得测试技巧，测试人员对你很难友好。因为对一个程序来说，其中包含的可能性是你加上程序员加上用户以及上线运行数十年直到产品下线都没有全部遇到的。

这么描述一个程序，相信对于程序员、管理人员、用户，都会深有感触。几乎所有产品上线了，都会有各种问题需要解决，往后则是越来越少，越来越少。

有一张图片很说明问题：

这个图片上一个程序员开始在认真写代码，然后越来越累，越来越烦躁，最后撞死在键盘上。

这个是很多初入软件行业的程序员遇到的问题，也是某些始终无法将代码bug量降低的程序员的苦恼。无论为公司做项目还是做产品，时间长了，就会总结出一句话：项目越做越复杂，维护难度越来越大，bug始终存在，越来越难找，然后把原因归结于开发时间短，用户需求变化快，无理要求多，很少有人愿意把原因归结到自己的开发水平上。

其实，无论多复杂的项目，都要进行一个合理的架构分解，接下来写代码的人还要针对架构的逻辑进行程序逻辑上的分解，继续往下则是代码结构上的分解。所以才出现诸多的设计原则，说简单点的话，所以几乎所有编程语言都支持函数。

linux操作系统、windows操作系统，算得上最复杂的软件了吧，发展这么多年，你会发现他们的架构也是逐层分解，到核心代码里也是函数里调用函数的。

那么对于程序员来说，怎么避免bug多，解决不完，解决不掉的问题呢？

从基础到高级，我们可以做如下事情：

1. 宽进严出原则：你要相信，用户输入，其它函数的输入，是有各种可能性的，但你的输出却坚决不可以有。比如一个数据库查询，显示一篇文章，从网址传过来的id号你要相信可能会是各种字符串甚至中文，那么我们可以将id进行类型判断，强制转换整数等工作，但你返回的一定要是一个数组，而不要可能是false，也可能是数组。
2. 每次做一个功能的时候，都将核心实现独立出来，在项目外用一个小demo去实现，并经过尽量全面的覆盖测试，如果有业务数据可以拿来测试，坚决不要放过。这个技巧很重要，如果需要实现一个将信息导出到word文档，那么你最好先去实现一个根据传入参数生成一个word文档的简单程序，再进行各种测试，最后再将程序嵌入到你的代码中，而且这段程序要么是一个函数，要么是一个对象。
3. 写代码时，封装好函数，一个函数尽量只做一件事情。如果你有一个get_info_by_id里面竟然进行了update操作，那技术主管可能会判断你为一个不合格的程序员。
4. 写代码要有条理，尽量让你的代码能够告诉阅读代码的人逻辑原则和顺序。这就要求变量命名规范并且能代表具体含义，写逻辑判断语句的时候，也要尽量能告诉别人你的逻辑判断是为什么。比如一个很复杂的If判断，比起写一堆判断语句加注释，就不如包装成一个函数，然后用函数名告诉别人你在判断什么。举例，判断一个订单是否可付款，如果用if (status == 5 && user_id == user.id && ...)，逻辑只要复杂到很难判断出来是哪种条件下可付款，就可以将逻辑写到一个函数中，函数名取为user_can_pay。
5. 无论你觉得自己的代码经过了多么精心的设计，编写和测试，一定要让他经历公众测试，并在公测阶段和正式上线的开始时间段内对它保持高度的关注，你可以检查日志，看看是否出过问题。

最后总结一下：测试人员不是程序员的救命稻草。如果程序员写完代码就交给测试人员，很可能引起测试人员的不满，你的bug太多了。如果程序员写代码眉毛胡子一把抓，不进行分解，不进行单元测试，那么测试人员可能天天都在测你写的代码，而你同事的代码却被测试人员一带而过的感觉。这个时候，测试人员最清楚哪个程序员“水平高”。