Refactoring Fat Components (with Ruby on Rails examples)

When starting a project it's usually easy to find stuff, read and understand the code even if it's not super organized, but as the time goes by and the codebase gets bigger, usually the development team gets bigger too, things can become quite messy.
- What are fat components (specially models) and why is it a problem
- Ways to extract logic out of models into dedicated objects

Transcript

1. Refactoring Fat Components With Ruby on Rails examples
2. Who am I? • Tutti Quintella (@tuttiq online) • From São Paulo, Brazil • Major in Computer Engineering • Software Engineer since 2011 • Software Engineer @ Mercari • Director @ Women Who Code Tokyo
3. DEAR WOMEN, WE NEED YOU https://meetup.com/Women-Who-Code-Tokyo/
4. Disclaimer • This presentation touches controversial topics like: ◦ Code readability ◦ Design patterns ◦ Coding principles / "good practices" • Most of the content is opinion based and subjective to exceptions / counter-arguments
5. What are Fat Components? • Too much logic in the same place • Too many responsibilities in the same component
6. Problems of fat components • Harder to find logic when looking at the file structure • Harder to read and understand what a component does • Components are too specific and less reusable • Harder to break the app in separate modules • Harder to unit test
7. Design patterns • Splitting the code into smaller parts • More defined responsibilities • Well known patterns: easier to find people that already know them, or easier to find learning resources
8. Design patterns - MVC Image copyright by Sandro Mancuso at Codurance
9. Sometimes only M, V and C is not enough... • Fat Controllers • Fat Models • Too much logic in one place
10. First advice "Skinny controllers, fat models" "Controllers should only concern themselves with receiving data from the client and passing data to the views. Logic should be on the models" Result: Skinny controller, OBESE models. User.rb - 700+ lines...
11. Single Responsibility Principle SOLID ↪ Single Responsibility Principle: a class should have only a single responsibility
12. Ways to extract logic • Mixins • Value objects • Service objects • Form objects • Policy objects • Query objects
13. Mixins • Pulling sets of methods out of a large model into a module/interface: makes the model smaller, but does it really organize the logic?
14. Mixins (properly implemented)
15. Value Objects • Most languages already have some native value objects like Date, Time, URI, File. • Any attributes that are more than basic strings or numbers are good candidates to be domain specific value objects • Ex: Phone, Address, Currency, Rating, Score, Color...
16. Value Objects
17. Service Objects Moving actions to objects dedicated only to perform them. Good candidates: • Actions that reach across multiple models ◦ E.g.: User + Order + CreditCard to perform a purchase • Actions that interact with external services / APIs ◦ E.g.: FacebookAPI Service
18. System design: Service Objects Moving actions to objects dedicated only to perform them. Good candidates: • Actions that are not a core concern of the underlying model ◦ E.g.: data cleanup, parsing, normalization... • Actions that can be performed in multiple ways (Strategy pattern) FileParser XML Parser JSON Parser
19. System design: Service Objects
20. Form Objects • Form Objects are useful (and recommended) when a form doesn't map directly and simply to a single model. E.g: ◦ Data needs parsing or formatting ◦ Data has complex validations ◦ More than one model are updated through the same form (nested models)
21. Form Objects
22. Others • Policy objects (define rules / complex validations for other models) • Query objects (objects to perform complex queries, that depend on multiple relations) • etc...
23. Bonus: Breaking down the architecture microservices.io
24. THANK YOU Contact: - Email: q.tuane@gmail.com - Facebook: https://fb.me/tuttiquintella - Twitter: @tuttiq - Github: @tuttiq - LinkedIn: https://linkedin.com/in/tuttiquintella