几年前就有人说我应该写专栏，当时想的就是，自己还不足以达到融会贯通的程度。
写出专栏来万一给了人误导，那就不好了。
极客时间之前也有人联系过，但是因为时间原因，觉得自己应该写不出来，就放弃了。
后来有一天宗刚给我打电话说，极客时间也找他写，但是他也没有时间，于是想起我来了。
于是我又再次跟极客时间讨论专栏的事情。
有一天我在咨询客户现场的时候，极客时间的编辑到我上班的那边，中午吃饭聊了一下。
谈到性能测试的市场，我也有些经验和感觉，想想自己也过了而立之年，再不写，以后是不是也不会有什么太大的进步了呢？索性现在就把自己所学全都展示出来吧，以免以后后悔。
刚开始写的时候，和编辑讨论的结果是，我以前写了不少原创文章，应该也能做得到，想想写出来30篇3000字不加代码不加图的专栏。
基于这些原因就答应了。
签合同的时候，我还一直犹豫，想着拖长一点，先写几篇垫个底，让后面不至于时间太紧张。
当写到第一篇的时候，发现不对劲。拾掇拾掇公众号，发现之前写的内容并不完整，断断续续的知识体系，并不足以凑成专栏的体系。
但是已经答应了，就没有再后退的道理。于是开始重新码字。
写到第一篇《性能综述》的时候，就觉得文如泉涌，一开始就停不下来，于是第一篇直接写到了一万多字，于是拆成了两篇。对性能相关概念的梳理是经过了长时间的考虑的。因为不想人错云亦错云，更不想偷换概念，也不想凑字数。
于是我开始重新定义自己认为的性能测试到底应该有什么样的理念，而这些理念又是如何在实际工作中应用的。
既然有了开始，后面的内容就顺理成章了。其实内容上是跳着写的，后面几篇是先写成的，因为我想直接写最想写的那一部分。
等写到十几篇之后，突然发现，整个专栏缺少一个中心，不是考虑专栏应该有个中心，而是考虑性能应该有个中心。于是开始写第六篇《06丨倾囊相授：我毕生所学的性能分析思路都在这里了》，这一篇是写的最是酣畅淋漓的。因为写它的时候，我觉得找到了之前没想通的目标。我把自己认为的性能核心理念都放在这一篇当中了，这一篇当时就写的超过了6000字。
但是由于这是一个完整的部分，所以没有拆成两篇。
其实从一开始写，我都没想着凑字数，一直想的是到底应该写哪些内容才是性能的核心。
高屋建瓴的虚话，纵然可以得到一些小白们的仰望，但是不能落地那就是耍流氓。
如果让我从完整的技术栈写，从广域网、局域网，到企业级部署架构，再到应用级业务架构，再到架构中的各个组件，再到性能测试过程，再到性能瓶颈分析，这样写的话，我觉得路绕的太远，并且这些话题没有一个是可以在一个专栏中尽述的，最后只能泛泛而谈。那不是我想要的。
如果只写测试工具、监控工具、剖析工具，那就成了度娘搬运工，都能查得到的东西，何必改头换面拼凑文字呢。这也不是我想要的。
思前想后，最后决定写性能测试分析调优中的核心环节，而那些工具们都只是我思路上的一个砖头，需要的时候就会填进来。
于是就把专栏组织成了现在的结构。
这是一个说的是基础但是并不基础的专栏。因为其中的每一篇都能够在性能项目的实施流程中找到对应的部分，并且还是前后都想关联牵一发而动全身的。比如说，写脚本这样基础的事情，写的脚本能不能满足业务场景的需要是关心的重点；再比如，关联、断言、参数化，这些也很基础，但是总有人不把这些基础操作和整个场景结合起来思考。
所以后面，我加入了场景、监控等部分，这些是性能项目中执行的重点。
当写到性能监控分析的时候，我一直在思考的一个问题是：应该按市面上的操作系统分析、数据库分析来写吗？总是觉得有些不对劲。
对每个知识点的细节要有足够的把握是必然的，而只把握细节的知识点是非常离散的，串不起来仍然不能运筹帷幄。
最后想到自己要写的，其实是一个分析决策树的创建过程。因为只有这个过程有了，才能触类旁通，在性能分析中无往不利。而这个过程就是找到瓶颈的证据链的过程。
所以在每一篇组件分析中，都加入了这样的描述，这使得我觉得是在写性能分析了。
从性能知识的整理上来说，我已经写出了我想要的内容，也写出了我对性能的完整的思考。
可能在一些细节上，还需要再润色修正，但总体上，我非常满意写出来的内容。
专栏只要求写到9万4千字，最后我数了一下，写出了14万字。
辛苦是自然的，但是也完成了一件大事，
以此纪念。
