← Back to Upcase

Refactoring Hartl's Rails Tutorial using Concerns

(Justin Gordon) #1

Here’s my first code sample for my refactoring talk at RailsConf 2014:
https://github.com/justin808/fat-code-refactoring-techniques/pull/3

I’m introducing concerns into Hartl’s Rails Tutorial web application.

Aside from lacking a surprise factor, is there any reason that I would not want to share my talk’s code samples so that I can get the most feedback possible before my talk at RailsConf?

Thanks in advance for any feedback!

0 Likes

(Daryll Santos) #2

As an alumni of the Michael Hartl book, this is great. I think that book needs a continuation. Can you add tests, too? When I was watching Destroy All Software, the fast tests (both in speed and in terms of steps per test_ are really what sold me on refactoring.

0 Likes

(rubylove.io) #3

I dislike concerns very much, but I wont stop that from sharing slides :smile_cat:

It is far better to catch things before you put the slides up in HUGE MODE.

If you would like to talk about why I hate AR::Concerns we can talk. I prefer encapsulation and decoupling, and concerns violates those principles pretty handily.

0 Likes

(Justin Gordon) #4

I’m going to post the more advanced refactorings of going to “Decorators”, “Presenters” and “Service Objects”. Take a look at the pull requests for more details: https://github.com/justin808/fat-code-refactoring-techniques/pulls.

My general feeling is that Concerns (and Decorators) are a great first step toward the more advanced refactorings, and for simple operations, quite sufficient. For example, if coming on to a new project with insufficient tests, I’d be comfortable knowing I didn’t break anything by breaking a model up with a few concerns. Then I could add a test file on each of those concerns, which, yes, are really just tests on the model. However, I find smaller files useful in itself.

0 Likes

(Justin Gordon) #5

I’ve created pull requests for my fat controller, fat model refactoring examples on github.

I’m going to create a separate topic on Learn for each of these.

Concerns:
https://github.com/justin808/fat-code-refactoring-techniques/pull/3

Decorators
https://github.com/justin808/fat-code-refactoring-techniques/pull/4

Presenters:
https://github.com/justin808/fat-code-refactoring-techniques/pull/5

Service Objects:
https://github.com/justin808/fat-code-refactoring-techniques/pull/6

0 Likes

(Luís Ferreira) #6

@Justin_Gordon Good job. Hope the talk goes well.

My problem with concerns is that they are mixins, which in turn are ruby’s way of having multiple inheritance. This raises an alarm for me. Not that inheritance is bad, it is not, it is a very powerful technique and concept, but it is often misused and overused I dare say.

I believe the first approach should be composition and only after trying that do I go for other solutions. Adding a concerns directory is something I do not agree with, because I think it encourages the wrong things. Even ActiveSupport::Concern has it’s share of problems.

That being said, it is a legitimate solution to try as long as one is aware that it is a form of inheritance and all of the pros and cons that has.

1 Like

(Pedro Moreira) #7

I agree with @zamith on this. Also, I’ve come to noticed that Concerns are getting used as a macro to avoid typing… and thus further hide an underlying problem.

@Justin_Gordon, hope the talk goes well!

0 Likes