debuggable

Ok, this is probably one of the most important tips I'll give throughout this entire "desserts" series, so listen up.

For those of you who have been reading this blog for a while you probably know that I've written a lot about soft hacking CakePHP which allowed to overwrite some difficult-to-bypass conventions with custom behavior. But lately I have come to realize that I was all wrong about this kind of stuff. Not wrong in the sense that I published bad code, or had bad ideas, but I was wrong by misunderstanding the basic principles of RAD development.

Whenever I worked on an application with CakePHP in the past I frequently noticed some things were I thought "Hmm, would'nt it be nice if this [function, class, ...] would work like this". And a lot of times I took it as a personal challenge to find a way to cirvumvent the standard behavior without having to modify any core files. Up to now I've only failed at this one single time when trying to make some major changes to the behavior of the current ACL implementation. But other then that, one way or the other, I was able to put my own configuration over the CakePHP'ish convention. Now as I already said, I think most of the times those soft hacks "improved" the framework and would be nice to have in the core. However, what I didn't realize back then was that I was loosing the #1 major advantage of using the framework - Rapid Application Development. Because by implementing all those modifications, I spent a lot of time on configuration that slowed down my development process considerably. And not even that, now that I had a good amount of little tweaks and "improvments" in my application my debugging began to be more difficult since whenever I hit a bug, I had to check if one of my soft hacks broke something. No way to get support in #cakephp or somewhere else if your code doesn't behave the default way CakePHP behaves.

So, let me try to translate the paragraph above in a pragmatic workflow for you guys so that you don't have to go through the troubles I went through. First of all: I am not saying that you should never soft hack some CakePHP behavior. Sometimes you have to support legacy table names, legacy url's or other things. BUT - most of the times - you don't. If you feel like tweaking some convention ask yourself this question: "Is this change needed to satisfy a real world requirement, or is it my ego pushing for a more 'advanced & flexible' approach to the problem". I don't hesitate to admit that in the past it was mostly my ego that demanded those nifty little tweaks that would be so cool to have. But looking back at it I didn't take any real advantages of it. A while ago I read about about an extreme/agile programming approach called YAGNI (You Arent Gonna Need It), and I think my advice above is a very pragmatic adoption of it when working with a framework like CakePHP.

Today I have started to completly refactor my current project under the aspect of removing all tweaks I did to CakePHP behaviors and I noticed something else I didn't even percieve as soft hacks before: My AppController modifications. When looking at my old AppController I noticed that I filled it with nice and convenient functions I wanted to have available throughout my project. Now I don't say it is a bad practise to put useful stuff in your AppController, but I think there is a better one to do it. Instead of filling it with all those functions directly try to think if they could be refactored as Components. This maybe doesn't sound like a big difference, but I found that now that my AppController has less then 20 lines of code in it and my components folder has 3-4 more components, the structure and simplicity of my project has increased dramatically. I mean stuff like a beforeFilter that would send a Utf-8 header, retrieve my MenuEntries and a very simple Auth function seemed to work just fine in the AppController, but now that I've moved them into components my understanding for the application really increased. I can easily turn those things On & Off by removing the components and tracking down bugs became a lot easier.

So far so good, I would love to hear your guys oppinion about this post.

PS: Oh and if you are afraid I'll never publish a soft hack again, that's not going to happen either. But I'll try to be a lot more thoughtful about my reasons for doing so and will always point to this article when describing the technique I used ; ).

--Felix Geisendörfer aka the_undefined