to the Future DEATH OF THE MONOLITH Introduction (or what I’ll be covering…) • Rails is a framework (wow) • Rails skyrocketed to popularity in the late 2000’s and empowered many small companies to quickly build and maintain robust web apps. • DHH would say it’s the best choice to build web apps nowadays
Rails to the Future DEATH OF THE MONOLITH What if you started a Rails project in 2008? • Considering your business is good, the project evolved to date • You should have updated the libraries • You should have some tests • You have 598753275932 models • You have 4891040319 controllers • You have 999439249324329432 views and partials • Or if you’re lucky, some cool api and new js frontend
Rails to the Future DEATH OF THE MONOLITH What can you do? Move to another technology and rewrite Rewrite whole app in Rails (again…) Break into smaller chunks of functionality Do you have tests? Refactor while you build PANIC, PANIC & PANIC What about new features?
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Refactoring and adding value New Features • Added as small chunks of independent logic • Refactor old code into smaller chunks • Tested • Make it a minilith
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Fearless Refactoring There is a book about it so it must be true • What is refactoring? • Where to start? • What do the cool kids think about it?
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) What is refactoring? • It should be a habit • It takes a systematic approach and team support • It will make you duplicate code and unduplicate it afterwards
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Where to start? • Some say, controllers are the entry point of the application • Do you need all your models? • Views are pretty easy to split up
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Where to start? Problems with controllers: • before_filter groups • multiple, nested if-branches • setting @ivars to access them in the view • Controller inheritance • Controller mixins/concerns
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) What do the cool kids think about it? • It takes time • It costs a lot • We should allocate special time and tasks for refactoring
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) What do the cool kids think about it? • It takes time • It costs a lot • We should allocate special time and tasks for refactoring • Boy Scout the code • Being confident and improving refactoring skills minimise time and cost
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Some numbers (that are not true) 100% of the people that hate refactoring are not doing it right 100% 100% of the people should try refactoring and read the referenced books 100% 25% of people that are doing refactoring right hate it 25%
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) Conclusion • You can’t have it all • Refactoring and the boy scout rule should be habit • You need tests • These techniques will better isolate your modules; Isolated modules are the step forward into microservices
Rails to the Future DEATH OF THE MONOLITH (not actually killing it…) References (or must reads) • http://rails-refactoring.com/ • Martin Fowler “Refactoring: Improving the Design of Existing Code” • Michael Feathers “Working Effectively with Legacy Code” • Joshua Kierevsky “Refactoring to Patterns” • (Uncle Bob) Robert C. Martin “Clean Code: A Handbook of Agile Software Craftsmanship” • (video) Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin - http://www.youtube.com/watch?v=WpkDN78P884
yutobara
rshindo
mixplace
lef237
satoshi256kbyte
a_matsuda
akihisaikeda
steliosf
moro
kishida
yukiny
yub0n
jonoalderson
pauljervisheath
oripsolob
addyosmani
akademiya2063
helmedeiros
skipperchong
techseoconnect
cassininazir
malarkey
greggifford
