Long before doing any development in Rails, I had begun honing my skills as a developer pf Object Oriented software, learning TDD, learning about design patterns, learning good software architectural principles such as Law of Demeter, Single Responsibility Principle, preferring encapsulation over inheritance, etc. Now, after focusing more and more on Rails development for the last few years, I find my practices to have eroded somewhat, and I’m now endeavoring to re-invigorate them.
Some Problems with Rails
Rails is an opinionated framework, and as we learn the Rails philosophy, we also learn to stick with the standards except where we have good reasons not to. The problem with that is — while the Rails standards work great for simple CRUD applications, it turns out that there are very few simple CRUD applications in the world. To the extent that we do keep trying to shoehorn our our applications into the Rails paradigm when they grow to become neither “simple” nor primarily “CRUD”, we start to damage their quality and maintainability.
Even though we may come to Rails relatively competent developers who always strive to improve our craft, to the extent that we get seduced into writing Rails applications and doing them the Rails way, we can easily find ourselves suffering a decline.