跨平台PHP调试器设计及使用方法——立项

        作为一个闲不住且希望一直能挑战自己的人，我总是在琢磨能做点什么。自从今年初开始接触PHP，我也总想能在这个领域内产生点贡献。那能做点什么呢？我经常看到很多phper说自己设计了一个什么框架，或者说自己搭建了一个什么系统。虽然这些对自己来说算是一种历练，但是这些对更多的人来说可能并没太多帮助。而我希望我能做的是可以帮助到更多人的东西。于是就有了标题中这个项目的立项。（转载请指明出于breaksoftware的csdn博客）

        这个项目的相关想法我酝酿了一两个月。利用零零散散的时间我不停的调研相关技术可能性，思考产品的形态和功能。于是在今年七月份，我给组内发了一份《PHP调试器设计心路历程和初步想法》的邮件。现在翻看了一下这封邮件，写的还算正式。我就将该邮件的内容作为该博文的主要内容给贴出来，最后我会对该封邮件进行补充：

Hi all:        

        由于我们组需要产出一些公共使用的组件，所以上次会上我提出一个制作PHP调试器的想法。        

        这个想法的初衷是为了解决PHP调试的一些痛点。我观察并询问了一些长期从事PHP开发的同学，发现他（她）们几乎都是使用var_dump/print之类的打印方法去进行调试。这个方法虽然很管用，但是其也有很多弊端：

• 需要改动源码进行调试。要在需要观察的数据的地方加上打印函数，否则无法观察数据。
• 增加代码出错的概率。调试结束后还需要找到之前添加的打印函数，并删除它们，如果忘记删除可能会导致输出错误。
• 降低效率。由于调试前需要修改文件，调试结束后还需要还原文件。这个过程消耗的时间会大大降低我们调试的效率。
• 不可更改性。我们可能对需要打印的数据做了错误的判断，导致打印数据的位置不正确，从而导致本次增加的调试信息不可以辅助我们调试。而这种不可更改性，需要我们重新修改文件以进行新的调试。

        基于以上的问题，我最初的想法是想设计出一种PHP扩展，它将所有过程中的变量（全局变量，成员变量，临时变量等）都保存起来。这是一种轻量级的设计，可以让我们在执行一次PHP文件后，记录所有变量，然后回溯各个变量的值。但是这个方案我觉得存在以下问题：

• 大数据量。比如我们在PHP中需要读出一个文件，这个文件的内容可能只是简单使用一下，而我们的设计将要永久记录下它。
• 循环中处理数据的问题。如果循环中不停读取文件和写文件，那么我们要要记录大量中间数据。
• 递归处理数据问题。问题同上。
• 浪费磁盘空间，影响效率。因为存在可能需要将大量数据存储中磁盘中的操作，所以这个效率将影响整个调试过程。
• 不具有通用性。我们要输出的是一个希望大家都能使用起来的产品，这种轻量级的产品存在之前列出的很多的缺点，所以不可能成为一个通用性的产品。

        于是上周五我将这个方案给否了，又进行一次方案的调研和设计。好在天无绝人之路，我找到一个我们可以做、且很有前景的一个方案：Xdebug+DebugWebServer。

        Xdeug是PHP的一个调试扩展，我看了一下它的源码，写的挺好，是一个值得信任的插件。它提供了基本的调试功能，而这些调试功能也正好能解决我们之前的痛点。而且：

• 大牛作品，质量可信耐。且还在维护中。
• 有群众基础。有大量的用户使用这个扩展进行调试。
• 多版本支持。有标准PHP版本，还有hhvm版本，目前PHP标准版已经可以支持PHP7了。
• 开放的协议。它使用了一套开放的调试通信协议，方便用户使用其调试功能。

        但是目前已经有很多关于Xdebug调试的方案，比如netbeans+xdebug、notepad++ + xdebug、vim+xdebug。好在大家都没有将事情给做绝了，还给我留下一条路——就是DebugWebServer+Xdebug。我们先来分析下这个方案和其他方案的不同：

• Vim+xdebug。应该是一个最容易让人接受的方案。但是Vim是Linux系统上的软件，如果在Windows系统上部署的PHP引擎并在Windows上进行PHP开发，将无法使用这套方案。所以这个方案存在局限性。
• Netbeans+xdebug。诸如Netbeans这类IDE，很多开发者并不喜欢用，他们电脑也会存在这些IDE。所以这类IDE+xdebug的方案也存在局限性。
• Notepad++ + xdebug。不同的开发者喜欢不同的开发编辑工具，有很多人喜欢Notepad++，也有很多人喜欢Sublime。这些无法做到统一，所以编辑器+xdebug的方法也存在局限性。

        而DebugWebServer则不存在以上问题，因为

• 作为网络服务存在，可以运行在Windows或者Linux系统上。
• 只需要在PHP所在的环境上部署一次，可以在不同环境下使用，降低学习成本。

        最后讲下DebugWebServer的设计：

• Python去实现相关功能。因为我们调试的是PHP，所以不想产生鸡生蛋蛋生鸡这类的问题，所以我没有选择PHP去实现功能（虽然Xdebug有Session这样的概念）。同时，我也没选择编译型语言——C/C++去实现。因为编译型需要需要在不同平台上编译出结果。而我希望提供的是一个可以直接使用的产品，所以编译型语言也不合适。而Python是一个广泛使用的工具性脚本语言，学习门槛低、且有大量组件可以直接使用，可以避免我们重复造轮子。
• Python去实现一个Http服务器，提供一个调试界面。Python实现Http服务器的代码非常简单，网上一搜一大堆。但是这个地方的难点就是调试界面的设计

        一个重要的功能就是PHP文件分析和着色。然后修改相关着色部分的点击事件，让其在右侧区域展现出来。我对这块不是特别了解，但是可以在网上找到相关资料http://www.oschina.net/project/tag/172/wysiwyg?lang=22&os=0&sort=view。其中有一款应该使我们需要使用和定制的。

• 打通debugwebserver和Xdebug。Xdebug的的调试协议是https://xdebug.org/docs-dbgp.php。实现协议是件很麻烦的事情，因为不仅要实现还要去调试各种场景。好在Python有相关实现。我找到一个我们可能可以使用的实现http://jaredforsyth.com/pydbgp/。但是这个实现没有给出使用的例子，所以这块也将是一个比较复杂的过程——我们可能要用它去模拟每个指令，然后打通它和我们的服务器。

        大家对上面的想法有什么意见和建议请和我反馈，如果有特别想去攻关的技术或者特别想实现的功能，我们可以商量怎么一起去做。

        谢谢。

这封邮件基本展现了这个项目立项时的背景。而在之后调研和实现的过程中，我也是按着这封邮件的思路去实施，其中若干的复杂点也是一点一点被攻克。其实这封邮件隐藏了我当时的一个疑虑——界面的实现，因为我并不擅长做网页，更不擅长做界面设计。但是最后我还是逼着自己把这块给攻克了下来，当然这些都是后话。在详细介绍这个工具诞生过程和使用方法前，我先把其目前相对稳定的版本展现给大家看。希望能吸引大家的注意，如果有兴趣，可以一起把这个项目完善。