This presentation was for the Ironhack students in Barcelona by our CTO Xavier Redó. In this presentation, you will learn best practices of developing web applications that are easy to maintain, by ensuring code readability, scalability and other criteria you can benefit from in the long-term.

1. BUILDING LARGE WEB
APPLICATIONS
That won’t be a pain to maintain

2. WHO AM I?
Xavier Redó Cano
CTO & Co-Founder
@xavier_redo
xavier.redo@marsbased.com

3. FIRST MONTHS BUILDINGTHE NEXT
BIGTHING ®

4. ONEYEAR LATER

5. –Henning Koch - Makandra CEO and author of Growing Rails
Applications
“Large applications are large.”
AN INCONVENIENT SECRET

6. WHAT DOYOUTHINKTHAT MAKES AN
APP MORE MAINTAINABLE?

7. 3 STEPSTO GLORY
• Follow conventions
• Write code for human
beings
• Always test

8. –Arthur Forman
“Not everyone thinks the way you think, knows
the things you know, believes the things you believe,
nor acts the way you would act. Remember this and
you will go a long way in getting along with people.”
FOLLOW CONVENTIONS

9. THE EASY ONE: CODING STYLE
if current_user
redirect_to user_tasks_path(current_user, format: 'json')
end
!
if(current_user)
redirect_to(user_tasks_path(current_user, :format => ‘json'))
end
!
unless current_user.nil?
redirect_to( user_tasks_path( current_user, format: 'json' ) )
end
!
redirect_to(user_tasks_path(current_user, :format => 'json') if current_user
!
current_user && redirect_to(user_tasks_path(current_user, :format => 'json')
!
current_user and redirect_to(user_tasks_path(current_user, :format => 'json')

10. • It is very easy to start doing it.
• You’ll be faster reading code that follows a certain
style.
• Saves time avoiding trivial discussions.
• When your team grows, you want to maintain
coherence amongst your codebase.
WHYYOU SHOULD BE ADOPTING A
CODING STYLE?

11. • Almost every Ruby on Rails company use and recommend a Style Guide:
• Thoughtbot: https://github.com/thoughtbot/guides/tree/master/style
• Plataformatec: http://guidelines.plataformatec.com.br/ruby.html
• MarsBased: Coming soon!
• If you can’t afford to build yours. Use the community ones!!
• https://github.com/bbatsov/ruby-style-guide
• https://github.com/bbatsov/rails-style-guide
WHY SHOULDYOU BE ADOPTING A
CODING STYLE?

12. FRAMEWORK CONVENTIONS
• ModelView Controller architecture
• CRUD centric RESTFUL approach
• ActiveRecord pattern
• Convention over configuration
• Unobtrusive Javascript
• DRY (Don’t repeat yourself)
• Concerns and modules to extend functionality
• etc.

13. resources :projects
!
!
class ProjectsController <
ApplicationController
!
def index
end
!
def show
end
!
def new
end
!
def create
end
!
def edit
end
!
def update
end
!
def destroy
end
end
EXAMPLE: RAILS CRUD BASED RESTFUL
APPROACH

14. resources :projects
!
!
class ProjectsController <
ApplicationController
!
def index
end
!
def show
end
!
def new
end
!
def create
end
!
def edit
end
!
def update
end
!
def destroy
end
end
Publishing
feature
EXAMPLE: RAILS CRUD BASED RESTFUL
APPROACH

15. resources :projects
!
!
class ProjectsController <
ApplicationController
!
def index
end
!
def show
end
!
def new
end
!
def create
end
!
def edit
end
!
def update
end
!
def destroy
end
end
resources :projects do
member do
patch :publish
patch :unpublish
end
end
!
!
class TasksController < ApplicationController
def index
end
!
def show
end
!
def new
end
!
def create
end
!
def edit
end
!
def update
end
!
def destroy
end
!
def publish
end
!
def unpublish
end
end
Publishing
feature
EXAMPLE: RAILS CRUD BASED RESTFUL
APPROACH

16. resources :projects do
member do
patch :publish
patch :unpublish
end
end
resources :projects do
member do
patch :publish
patch :unpublish
post :duplicate
patch :add_collaborator
patch :remove_collaborator
end
!
collection do
get :search
end
end
Lots of features
EXAMPLE: RAILS CRUD BASED RESTFUL
APPROACH

17. A TRULY RAILS RESTFUL APPROACH
resources :projects
!
namespace :projects do
resources :publishings, only: [:create, :destroy]
resources :duplications, only: [:new, :create]
resources :collaborator_addings, only: [:create, :destroy]
resources :searches, only: [:create]
end
EXAMPLE: RAILS CRUD BASED RESTFUL
APPROACH

18. DEVELOPERS CONVENTIONS:
DESIGN PATTERNS
Context Strategy
Concrete
Strategy 1
Concrete
Strategy 2
Concrete
Strategy 3

19. YOUR OWN CONVENTIONS
• Your team is going to naturally develop a
coding style and a set of conventions.
• Embrace them, document them and use
them in all your projects.
• It’s part of your company’s culture.

20. YOUR OWN CONVENTIONS
Don’t change your
conventions every 2
months

21. –David Heinemeier Hansson (@dhh) - Ruby on Rails creator
“We are not computer scientists.We are software
writers.”
WRITE CODE FOR HUMAN BEINGS

22. Ruby programming language
WHY IS IT IMPORTANT?
BrainFuck programming language

23. USE INTENTION REVEALING
METHOD NAMES
aka: Let your code speak to you

24. INTENTION REVEALING METHOD NAMES
class SearchUsersService
def search_users(params)
# TODO: refactor
conditions = {}
conditions["hireable"] = params[:hireable] unless params[:hireable].nil?
conditions["availability"] = params[:availability] unless params[:availability].nil?
conditions["profile.tags_array"] = params[:tags].split(",") if params[:tags]
conditions["category_ids"] = params[:category_ids].split(",") if params[:category_ids]
!
if params[:location]
filter = {
:multi_match => {
:query => params[:location],
:fields => ["profile.country","profile.state","profile.city"]
}
}
end
!
if params[:q].present? || !conditions.empty?
query = User.search(params[:q], where: conditions, execute: false)
query.body[:query][:bool][:must] << filter if params[:location].present?
query.execute.results
else
User.active.ordered_for_directory(params[:order])
end
end
end

25. class SearchUsersService
!
def search_users(params)
conditions = extract_conditions_from(params)
filter = extract_filters_from(params)
!
if query_term_for?(params) || conditions.any?
query = build_users_search_query(params, conditions, filter)
query.execute.results
else
User.active.ordered_for_directory(params[:order])
end
end
!
end
INTENTION REVEALING METHOD NAMES

26. KISS: KEEP IT SIMPLE STUPID

27. HOW DOYOU ACHIEVE SIMPLICITY?
Create reusable components only when you detect
duplication.
Apply a design pattern to a problem only when
simplifies your code and improves code readability.
Prefer being explicit than being implicit.
Maintain the abstraction low.

28. KISS: KEEP IT SIMPLE STUPID
It also applies to the 3rd party software you are using

29. HOWTO BE SUREYOU ARE WRITING
UNDERSTANDABLE CODE?
Pair programming
Git workflow based on pull requests and
code revisions
Reading, reading and reading open-source
applications and libraries

30. ALWAYSTEST
– Anonymous
“The principle objective of software testing is to give
confidence in the software.”

31. WHYTESTING?
Bring confidence and peace of mind.
Discover hidden bugs in your application.
Save lots of time avoiding manual tests.
Allow you to refactor code.

32. # TODO: It needs refactoring. Replace conditionals with
# polymorphism and delegate responsibilities.
def author_information
if author.kind_of?(Teacher)
if author.male?
"Mr. #{author.full_name} - Dpt #{author.department}"
elsif author.female?
"Ms. #{author.full_name} - Dpt #{author.department}"
end
elsif author.kind_of?(Student)
"Student of #{author.degree}"
end
end
DON’T FORGETTO REFACTOR
A green test is not the final step

33. WHY DO CODERS STOP
TESTING?
Testing require a different set of skills.
Some tests are hard to write (e.g.
integration).
Tests also need maintenance.
Customers don’t mind if you test or
not.

34. THANKYOU!
@xavier_redo
xavier.redo@marsbased.com
Don’t be shy and drop me a line

35. BONUSTRACK
Model
Controller
View
Decorators Presenters
Service Objects
Policy Objects
Facade