![]() In that case documentation and maybe a walk through with xdebug is in the cards. This being in complete contrast with something built from scratch where every convention was soley up to the previous developer. If you already knew something about how things are built using those tools (or even if you didn't), you can glean how it's built pretty quickly as there are key places where things go. Some real life examples would be if someone showed you a website built using a common CMS like Drupal or Wordpress, or a web application built using Laravel or Symfony. Having this, we then know what's going on without having to disect any given lifecycle request for the app to see how it's working. The things that are left which us developers create usually follow a pattern or convention (again based on a pre-defined tool) so that from project to project you can spot a folder structure or file naming similarites. are all usually built into CMS's or web application frameworks and are known to work. Things like authentication, data migration, MVC routing, etc. These days we use frameworks and common tools to keep all of the complicated stuff off in a black box and out of sight. Assuming for a second you disagree, I'll also argue that 95% of any modern PHP being written shouldn't warrant immediate debugging at the level of xdebug. In my mind it's nice to know it's there when I need it but too heavy to use as a normal tool while developing. That all being said, this isn't something you should incorporate into your everyday coding. These are all familiar concepts you'd normally see while debugging a compiled language, or even Javascript using the debug tools in the browser. While using an xdebug capable editor or IDE, you're able to set breakpoints, step into, over, and out of code and watch variables and the call stack change as the request makes its way through the code. ![]() If you want more info, you can nerd out on DBGP here. Just know that the server and your editor are connected and you can watch the process flow while seeing current state information passed down as the code executes. Here is a quick explanation of what is going on with DBGP with a visual. Xdebug on the server works together with your IDE or code editor over a protocol called DBGP (I'm guessing that stands for Debug Protocol). It is with a PHP extension called Xdebug. The best way to debug PHP code is similar to how you would a compiled language (C++ or Java). Sometimes it's not enough to just read through the code to try and understand what's happening, or start killing the script to dump variables with print_r or var_dump (more on that later). Over the years I've stumbled upon code that's had the need to really be examined at a deep level in order to understand what it's trying to do.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |