Application

Architecture

Topalov Alex 2016

BORING!!!

Intro

duplication is far cheaper than the wrong abstraction

- Sandi Metz. RailsConf 2014

Happy Case

After awhile

And sometimes...

DRY?!

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

- Andy Hunt and Dave Thomas.

What to DRY

  • Things that changes rarely
  • When same concepts in different places
  • When same concepts have different names

Abstraction

Abstraction is the unsplittable block of a knowledge representation.

Collect Duplication

Collect Duplication

Collect Duplication

Something not right

Weird

Weirder

Weirdest

Why and how that happens

Why and how that happens

1. Unreasonable expectations because of tight budget or else

Why and how that happens

1. Unreasonable expectations because of tight budget or else.

Solution: Try to at least squeeze some integration testing or(and!) re-write in a future completely.

Why and how that happens

1. Unreasonable expectations because of tight budget or else.

Solution: Try to at least squeeze some integration testing or(and!) re-write in a future completely.

2. Lack of application design understanding. 

Some common solutions

  1. Adapters

Some common solutions

  1. Adapters

 

  • Unify API for different classes.
  • Reduce conditional branching.

Some common solutions

  1. Adapters
  2. Decorators

Some common solutions

  1. Adapters
  2. Decorators

 

  • Remove logic from views or other contexts
  • Do not mixup business and representation logic.

 

Solutions:

  1. Draper
  2. Own/Custom

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  • Extracting complex business interactions/routine in separate class.
  •  Reduce code in controllers/models

 

Solutions:

1. Interactor

2. Light-service

3. Custom/Own

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators

 

  • Remove conditional validations.
  • Remove or unify logic for specific validations.

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers

 

  • Represent objects in a special format by a special rules

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers
  6. Strategies

Delegate tasks to Strategy objects which have same interface

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers
  6. Strategies
  7. Concerns/Policies

Rails concerns or non-rails.

 

Idea is to encapsulate logic around some functionality that used only in one context.

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers
  6. Strategies
  7. Concerns/Policies
  8. Observers

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers
  6. Strategies
  7. Concerns/Policies
  8. Observers
  9. Duck typing(technique)

Some common solutions

  1. Adapters
  2. Decorators
  3. Services
  4. Validators
  5. Serializers
  6. Strategies
  7. Concerns/Policies
  8. Observers
  9. Duck typing(technique)
  10. Repository object
  11. Data object

12. Factory

13. Abstract Factory

14. Proxy

15. Command

16. Iterator

17. Builder

18. Singleton

19. Interpreter

20. etc

Junior Sindrome

Symptomps:

  • Sunk Cost fallacy
  • Cowboy coding

 

Treatment:

  • Code review
  • Peace of internal mind

Big boss syndrome

Symptomps:

  • Over Engineering
  • Pattern Seeking

 

Treatment:

  • Refactoring of old pieces of own code
  • Real life examples
  • Code review

How develop with ease

  1. Wait for a code to tell when to reveal abstraction

How develop with ease

  1. Wait for a code to tell when to reveal abstraction
  2. Be ready to break rules that you thought is unbreakable

How develop with ease

  1. Wait for a code to tell when to reveal abstraction
  2. Be ready to break rules that you thought is unbreakable
  3. Be open to new ideas

How develop with ease

  1. Wait for a code to tell when to reveal abstraction
  2. Be ready to break rules that you thought is unbreakable
  3. Be open to new ideas
  4. Read books and review legacy projects

How develop with ease

  1. Wait for a code to tell when to reveal abstraction
  2. Be ready to break rules that you thought is unbreakable
  3. Be open to new ideas
  4. Read books and review legacy projects
  5. Write integration/contract tests !? FTW

Conclusion

It's not a framework issue - it's your issue

Architecture

By Alex Topalov

Loading comments...

More from Alex Topalov