我有一个观点，并且我认为这是无须详细去解释的，那就是：

每一个程序员，都得学会对自己的代码做性能测试

当然，性能测试的工具并不一定是JMeter，但以当前开源框架来说，我认为它是最好的选择。

从本周开始，在讲编码之道的同时，我将同时每周讲一篇技术，也就是编码之术。

做为一个优秀的程序员，道与术同等重要，不可偏废。

编码之术的第一个系列就是：写给程序员的JMeter教程

性能不是最重要的

要记住一个原则，性能只是技术价值中的一个维度，不要说业务价值，光是从技术价值上来考量，性能也并不是最重要的，甚至得排在很多点后面，比如可维护性。

我一向认为：可维护性是最重要的技术价值

因为性能是可以用硬件来弥补的，但可维护性差就不是弥补这么简单的事了，为可维护性付出的代价会远高于提升下硬件或在集群中多加个服务来解决性能问题的代价，硬件永远是越来越便宜的。

做为程序员，一定要有这种认知。

当然，这不代表性能是可以轻视或者忽略的，关于如何对待性能这个技术点，我的观点是：

在不牺牲可维护性的前提下，努力做到性能最好

尴尬的性能测试

相比其它维度的测试工作，性能测试稍显尴尬。

测试人员

性能这个事情，不理解技术，没有实际编码过，坦率的讲要做好并不容易。而理解编码或编码过的测试人员其实是少数。因此，仅有此部分的测试人员能够去做性能测试，而大多数测试人员在性能测试方面始终有点难以着手与深入。

程序员

好吧，大多数程序员可能并不认为性能测试是需要自己动手的一个事情。这显然并不是一个正确的认知。

自动动手，丰衣足食

我认为，程序员是非常有必要自己做性能测试的，它应该是一个程序员的必备技能之一。

有谁会比你更熟悉你自己编程的思路与实现？

程序员的自我性能测试应该是第一道防火墙，无论后面测试团队会如何进行性能测试，本身你自己要先给自己把这一关给过了先。

原因我认为有以下几点：

1. 专业性

其实无论是单元测试，还是性能测试，程序员理当自己去做这些事，自己写的代码自己要保障它的质量，这应该是专业性的一种体现。我们想做好一个程序员，那对专业性的追求就必不可少。

2. 发现隐蔽的错误

很多功能，如果不在大并发下运行，可能一切正常。但这并不意味着它就真的正常，我们要明白我们的服务是在网上运行，它并不是一个人在使用。大并发下会出现非常多你意料不到的问题与Bug。

3. 自己最清楚自己的逻辑

别人测试你的代码，永远不如你自己清楚，你知道自己是怎么实现的，当然就更清楚在性能上如何测试它更好。

4. 这不是一件很难的事

其实技术整体发展方向是越来越易于使用，不断的有更好的工具出现。我要讲的JMeter就是一个足够简单且易于使用的工具，使用JMeter绝大部分情况下，只需要用图形界面就能搞定，极少数情况下才需要编写脚本。

5. 它更节省时间

好吧，我知道这听起来有点夸张或不可思议，很多人理所当然的会认为这会花费更多的时间。

其实这个点与单元测试是一样的，凡是认为单元测试或性能测试会延长编码时间的程序员，这些想法都属于想当然，他们可能从未尝试过。

实际上，你不做这些事，未来你会在其它方面为它付出更多的时间。而只有做这些事，才有可能保障代码的可维护性。

JMeter与LoadRunner

当然，现在我们都尽量使用开源的工具，因为很多开源的工具足够强大并且是免费的。

在性能测试领域，当然最专业的要属LoadRunner这个工具了，但显然这个太重了，还只支持Windows。

事实上，很多互联网公司主流都是使用了更轻，更易于使用的JMeter。

且不论JMeter和LoadRunner熟优熟劣，对于程序员来说，选择JMeter肯定是当下最正确的选择。

学习使用JMeter

所以，从现在开始你可以跟随我的脚步来学习与使用JMeter吧。其实它足够简单，你并不需要花费太多的时间。

下一篇，写给程序员的JMeter教程（一）：理解常见的性能数据概念及JMeter的安装

关注【微言码道】公众号或访问【微言码道】官网 https://taoofcode.cc : 用我们微小的力量传播编码之道

访问【myddd-全栈式领域驱动】官网: https://myddd.org