May 22nd, 2016
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
Let me tell you a story about what can happen in a convoluted Rails codebase. Once, I joined an existing project. It was a huuuuge app which was running an on-line shopping community website. Complicated sales model, complicated promotions, complicated product setups, coupons, user groups, messages – it had it all. I joined them to help ship a few new features. One of my early tasks was to…add a link to something on some page. It took me few days to add this stupid link. Why? The app was a big ball of complex domain logic scattered across multiple layers with view templates so complicated, it wasn’t even simple to find the right template where the link was supposed to be added. Since I needed some data in order to create that link, it wasn’t obvious how I should get it. There was a lack of internal application APIs and relying on ActiveRecord exclusively made it extremely difficult. I am not kidding you.
…We’ve been talking about ways of improving architecture of our Rails applications for roughly 6 years. I’ve been trying to contribute to this discussion as much as I could, with articles, conference talks and by working on many OSS projects that strive to solve various hard problems.
The arguments and ideas people have had are always being ridiculed by Rails Core Team members, and especially by DHH. This has been off-putting and discouraging for me, and the reason why I never tried to contribute to Rails. I’m pretty damn sure that my proposals would end up being drastically downvoted. Monkey-patches? C’mon, not a problem, we love our 10.years.ago! New abstractions? Who needs that, Rails is SIMPLE! TDD? Not a problem, it’s dead, don’t bother! ActiveRecord is bloated – so what, it’s so handy and convenient, let’s add more features instead!