Ask A Question

Notifications

You’re not receiving notifications from this thread.

Code Review: Refactoring the Receipts gem for Composability Discussion

One thing I've found helpful is to purposefully start with a very concrete approach (like you following the designer's template) and only refactor it later to make it more flexible if and when it's needed. Because it's hard to predict exactly what flexibility you need. You don't want to end up with the wrong abstractions.

Curious to hear your views on this. Do you think you would have found this composable approach for the receipts gem if you didn't first start out with the more fixed approach?

How do you balance the trade-offs of A) getting something shipped quickly that works and can be refactored later, versus B) taking a more flexible/composable approach from the beginning and risk using the wrong abstracting or even spend additional time on code that might be removed in the near future anyway (e.g. if it's a feature users don't end up using).

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,464+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.