Frameworks are about efficiency and effectiveness. They save you time. By forcing common conventions, a framework helps solve common issues like view rendering, asset generation, security, application configurations -- things that happen in every web application.
This is good. It brings consistency to decisions. Instead of implementing a feature by writing a number of custom modules, all we have to do is implement it the way the framework wants us to. This saves us time and headaches, and makes the development process easier. However, that is the basis of the problem.
Because frameworks are so good at making decisions for us, we get lazy. Instead of thinking hard about how to build a clean system with crisp abstractions, we think about what the framework would want us to do, regardless of whether the resulting code is clean.
To the hammer, everything looks like a nail
The Law of the Instrument is best described by Abraham Kaplan, "...Give a small boy a hammer, and he will find that everything he encounters needs pounding."
When relying on a framework, we are victims of the law of the instrument. Whenever we implement a feature that doesn’t fit perfectly into the framework, we get sloppy. We look at solving a problem like the framework wants us to. It is easiest to shoehorn the idea into the framework, instead of designing the code that is best for the feature.
This is a matter of professionalism, and delivering the best possible code for each feature, instead of doing what is easiest. It’s a matter of taking personal responsibility for the design of your application instead of letting something or someone else do it for you. As professional developers, we must think independently of our framework.
It’s really your fault
Ever hear someone complain about a particular framework? I know I’ve heard complaints about Rails plenty of times: “Rails apps promote bad architecture” or “Rails tests are so slow”. At first, I bought into it. I blamed Rails. But now when I hear it, I just think that the person complaining is lazy. Rails, or any framework, is just a tool. You are the one in control. Blaming an inanimate object for your bad code is just unprofessional.
Choose the right tool, or use the tool properly
Coding with a framework is still coding, after all. And as programmers, we have the choice of how we want to implement a feature. As people that care about clean code, it’s important that we commit to SOLID design and well-abstracted programs that do just what you’d expect. And to do that, we have to actively think about our design choices, especially in a framework.
Decide to be a professional
We must choose our tools on a use case by use case basis. A framework can do many things, and the use case should dictate the architecture. Sometimes the framework will fit perfectly into the implementation of a use case. When it does not, it is your responsibility to write within or around the framework for the sake of clean code.
