Saturday, January 8, 2022

Rails related: Concerns, Module-method extraction Vs Class-based extraction, Concerning module

1) Single-use Modules are probably better off as Classes as per the below article.

 https://www.cloudbees.com/blog/when-to-be-concerned-about-concerns

By and large, maintainers tend to agree that smaller composable classes are the best way to isolate code and keep things clean.

....

....

I'm not saying that you need to go out and refactor all your single-use modules into classes. I am saying if you find yourself reaching to do a module-method extraction, stop. Consider what road you're starting down and these lessons I've shared. What would a class-based extraction look like instead?

2) https://blog.appsignal.com/2020/09/16/rails-concers-to-concern-or-not-to-concern.html 

3) https://api.rubyonrails.org/v5.0/classes/Module/Concerning.html

4) https://scoutapm.com/blog/rails-concerns - sort of consolidates content from the above articles

5) https://rails.devcamp.com/trails/dissecting-rails-5/campsites/data-management-rails/guides/how-to-use-concerns-rails-5

 

Sunday, January 2, 2022

Draft Pull Requests

 https://software.rajivprab.com/2021/12/26/our-engineering-principles-and-best-practices/

Draft Pull-Requests

For each pull-request, first create a draft pull-request, demonstrating the proposed implementation at a high level. Use TODOs and placeholders to indicate which classes/methods you will be touching. Send it off for review and then immediately start working on the actual code and tests.

This mitigates the amount of wasted effort, if your reviewer then suggests a completely different way of implementing things. Once your reviewer approves the draft, link to it in your pull-request, to make sure everyone knows what was already discussed and agreed on.