We do a lot of work on custom Rails projects and bump into technical debt quite a bit. One of our software engineers wrote a blog post about the most common types of tech debt out there with tips on how to handle it. Hoping this helps someone and looking for feedback.
Let me know what you think -- [Most Common Types of Technical Debt in Rails](https://nextlinklabs.com/insights/most-common-technical-debt-in-rails-projects).
10 thoughts on “Most Common Types of Technical Debt in Rails”
Nice article, I’m an intermediate rails dev and most of these are pain points I’m experiencing in my pet project. Thanks for sharing!
Can confirm – as a SaaS solo tech founder who’s business grew to require a larger team, I definitely made all these mistakes. My dev team constantly reminds me about ‘em!
Awesome blog post. Thank you.
> Using ActiveRecord Callbacks […] cause more headaches […]
They should be used sparingly, yes, but they’re also a pretty immature concept (in software generally?). So perhaps this is simply a question of exposure and getting used to them?
I certainly see some excellent use cases for them in our codebase. People probably don’t run into problems because they use callbacks, but because they use the wrong or incorrect callbacks for the task they’re trying to solve.
Rails (and Ruby) has a concept of “sharp knives”. You don’t have to use the knife unless it’s the right one for the job, but when you do choose to use it it will not restrict you. It will do exactly as you ask it to.
So the problem is: Do you understand what you’re asking your code to do? In my experience, poor call-chain comprehension is tied to poor product comprehension, which in turn is tied to a communication problem in the company. Either the C-suite isn’t explaining what they want well enough to the product owner, or he’s not explaining it well enough to the developers, or the developers are not explaining it well enough to each other during code review.
And incorrectly applied callbacks and call-chains are very hard to track down and refactor away.
The irony of advocating for service objects in content marketing about technical debt. Please, no.
Awesome post! About the AR callbacks, does anyone have a good resource on learning how to transition away from callbacks? alternatives, best practices etc
I think we all face these. More details on preventing it is desired. But would love an article which covers design patterns to common coding scenarios.
Ok – I have one nitpick with this article. While I highly agree with the overall comments regarding callbacks, this article conflates ActiveRecord Callbacks (before_save, after_save, etc) and AbstractController Callbacks (before_action, after_action, etc) – calling them all ActiveRecord Callbacks. That is incorrect.
Lack of referential integrity. I don’t think Rails added out the box support for FKs until version ~~5~~ 4. What a joke!
1. no tests
2. slow test suites
3. fat controllers
4. fat models
5. using callbacks
6. old readme
7. no view partials
8. useless gems