Debugging in VS Code

I have a debug environment set in PhpStorm, but since I started using VS Code for ES6 version of Qedy, I was lazy to fire up the other IDE just to debug a problem.

One day I was fed up by only using debugger statement, so I decided to set up debugging in VS Code as well.

JavaScript

I installed “Debugger for Microsoft Edge” extension by Microsoft.

I wanted to attach the debugger to my Edge Dev I'm already using, but most tutorials expect to launch a new browser every time.

Launch Edge with --remote-debugging-port=9222

Brilliant idea are conditions for keyboard shortcuts, I can use F5 for both Debug/Restart (when: inDebugMode && debugState == 'stopped') and Debug/Continue (when: debugState == 'stopped').

PHP

I installed “PHP Debug” extension by Xdebug.

settings.json

1. "php.validate.executablePath": "C:/php/php.exe",

launch.json

1. {
2. "version": "0.2.0",
3. "configurations": [
4. {
5. "name": "PHP",
6. "type": "php",
7. "request": "launch",
8. "port": 9003
9. }, {
10. "name": "Edge",
11. "request": "attach",
12. "type": "edge",
13. "runtimeExecutable": "dev",
14. "port": 9222,
15. "webRoot": "${workspaceFolder}/src/js",
16. }
17. ]
18. }

I'm not a code monkey

As I wrote before, I've decided, that whenever I'll feel the project is steering into a skid, I'll either take over, or quit. I've got this feeling after I dove into the new codebase in project I [|mentioned in June].

I expected the guy, who took over, had much more experience, but from my point of view he's something like a seasoned junior. He does the exact same design mistakes I did when I created my first iteration of Qedy five years ago.

His approach creates a lot of static code, spaghetti code, many copy-pastes, tons of element queries, no internationalization, multiple versions of the same thing (like modal window), ignoring accessibility, and with lack of guidelines it creates multiple coding styles.

He enforced heavy gulp, compiling JS modules with Webpack and Babel into a single .js file, which currently has over 1.5 MB.

My original version didn't have this size even with all assets and featuring triple the functionality. Plus, I believe the widely used querySelectorAll to data attributes takes as much CPU cycles as my version needed for the whole module to parse and render.

I tried to object to all this, but the other junior sided with him, so my complaints were dismissed. My further ideas for improvement got glided over as well. I didn't want to look offended they replaced me, which I was, to be honest, but I was also relieved it won't all stand on my shoulders.

And he configured the gulp with BrowserSync, which is probably used by someone who doesn't save their code often, because I do and the constant unnecessary reloads drive me and my CPU temperature up the wall. Also, I often lost my progress within the app, because I did a change and PhpStorm saved it for me.

So, I obeyed and started re-creating three modules under this new paradigm. Yes, it was really nice and refreshing, that everything was possible, but I was also quickly forced to create a bunch of sets of fairly similar functions. I took the liberty of not optimizing anything, because it was faster and apparently that's what matters now.

But soon I had enough of it, with a very slow progress and a lot of annoyances. I took advantage of my younger colleague and introduced him to the team as my upcoming replacement. At work I have the golden opportunity to refuse working on projects like this, so after a point of no returned I gladly, but also sadly, played this card.

I wish the team the best of luck. I simply don't want to sink so many hours into blindly coding thousands and thousands of lines of single purpose code.