Stop using development mode

Stop using development mode

Rails development mode is easy, useful and fast: we can spin up an app, edit its source, hit reload in a browser and see the result of our changes. But what effect does this workflow have on our code, and does it really help us? In this talk I look at the dark side of development mode — where it falls down, what it does wrong, and how it ultimately encourages us to develop software in the wrong way — and suggest an alternative way of working which avoids these disadvantages.

Given at Railsberry (http://railsberry.com/). There's a video of this talk at http://youtu.be/TQrEKwb5lR0.

Cd9b247e4507fed75312e9a42070125d?s=128

Tom Stuart

April 20, 2012
Tweet

Transcript

  1. Stop using development mode. by @tomstuart, at Railsberry, in Kraków,

    on 2012-04-20.
  2. How to develop a Rails application:

  3. RAILS_ENV=development

  4. config/environments/ development.rb: config.cache_classes = false

  5. $ rails server

  6. None
  7. None
  8. None
  9. None
  10. None
  11. None
  12. None
  13. None
  14. None
  15. None
  16. None
  17. None
  18. (That was 2005.)

  19. Development mode is what first got me excited about Rails.

  20. Reload-driven development ™

  21. What’s wrong with this methodology?

  22. cowboy programming testless programming inside-out programming it encourages:

  23. Cowboy programming

  24. programming before thinking pressing reload until it looks like it’s

    working writing the code you want to write
  25. Testless programming

  26. why write tests when you can press reload?

  27. PRESSING RELOAD DOESN’T SCALE

  28. why write tests when you can press reload? the app

    works! now write tests so you don’t feel guilty the app broke! now write tests so it doesn’t break again
  29. THE DEFINITION OF WORKING IS THAT THE TESTS PASS

  30. Inside-out programming

  31. write a migration write a model write a controller write

    a template write a route press reload
  32. database.

  33. database. model.

  34. database. model. controller.

  35. database. model. controller. template.

  36. database. model. controller. template. route. user.

  37. You build each layer before you’ve built the layer that

    uses it.
  38. You are imagining what the next layer will need this

    one to do.
  39. If you love imagining things that much,

  40. move to Los Angeles

  41. and become a Scientologist.

  42. Development mode doesn’t let you see anything working until you’ve

    completed a full vertical slice through the application.
  43. This makes it easier to write badly designed code.

  44. If Rails has a development mode, shouldn’t I use it?

  45. None
  46. What’s a “web framework”?

  47. “A collection of libraries, utilities and conventions to make web

    application development easier.”
  48. You are right and good.

  49. “A note from my mother excusing me from responsibility for

    every decision.”
  50. YOUR FAULT YOU ARE WRONG AND BAD EVERYTHING IS

  51. Rails is software. It doesn’t care about you.

  52. Be mindful. Use judgement.

  53. There is a better way.

  54. Two related ideas:

  55. 1. Work outside-in.

  56. Start by writing an acceptance test to explain the ultimate

    goal.
  57. (An automated one.)

  58. Drill down into the application by writing unit tests to

    set intermediate goals.
  59. Make progress towards the ultimate goal by getting unit tests

    to pass, not by pressing reload.
  60. Reach the ultimate goal by getting the acceptance test to

    pass, not by pressing reload.
  61. (During development, your primary clients are automated tests, not web

    browsers.)
  62. How is this possible? How can you test the controller

    before writing the model?
  63. 2. Use mocking.

  64. Ruby is inspired by Smalltalk.

  65. Smalltalk says: a program is a network of collaborating objects.

  66. None
  67. Reboot your brain to think in terms of object collaboration.

  68. Drive out the design of objects using mocking, not guessing.

  69. mock these unit test this

  70. You can implement an object before its collaborators exist.

  71. By the time you start implementing them, you’ll already know

    what they need to do.
  72. It’s not about coverage, it’s about driving your design directly

    at every level.
  73. The only limitation is your acceptance tests.

  74. Some automated tests are too hard, or impossible, to write.

  75. Fine: use development mode to run those acceptance tests with

    your eyes and brain.
  76. Why work this way?

  77. Better design. Better code. Less pressing reload. Faster tests.

  78. It is possible to build a web application without opening

    a web browser.
  79. “Do I need to use development mode?”

  80. In practice:

  81. growing-object-oriented-software.com

  82. pragprog.com/book/achbd/the-rspec-book

  83. Thank you. @tomstuart / tom@experthuman.com / computationbook.com