Refactoring Rails Applications

1.782 Aufrufe

Veröffentlicht am

The slides to the Refactoring Workshop of Mathias Meyer and Jonathan Weiss at the Rails Konferenz 2009 in Offenbach/Frankfurt.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.782
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
83
Aktionen
Geteilt
0
Downloads
16
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Refactoring Rails Applications

  1. 1. Refactoring Rails Applications <ul><li>Mathias Meyer und Jonathan Weiss, 01.09.2009 </li></ul><ul><li>Peritor GmbH </li></ul>
  2. 2. Who am I ? <ul><ul><li>Jonathan Weiss </li></ul></ul><ul><ul><li>Consultant bei Peritor GmbH in Berlin </li></ul></ul><ul><ul><li>Specialized in Rails, Scaling, Deployment, and Code Review </li></ul></ul><ul><ul><li>Webistrano - Rails deployment tool </li></ul></ul><ul><ul><li>FreeBSD Rubygems and Ruby on Rails maintainer </li></ul></ul><ul><ul><li>http://www.peritor.com </li></ul></ul><ul><ul><li>http://blog.innerewut.de </li></ul></ul>
  3. 3. Who am I ? <ul><ul><li>Mathias Meyer </li></ul></ul><ul><ul><li>Chief Cloud Officer bei Peritor GmbH in Berlin </li></ul></ul><ul><ul><li>Rubyist </li></ul></ul><ul><ul><li>Asynchronist </li></ul></ul><ul><ul><li>Post-Relationalist </li></ul></ul><ul><ul><li>http://www.paperplanes.de </li></ul></ul><ul><ul><li>http://www.dailyawswtf.com </li></ul></ul>
  4. 4. Refactoring <ul><li>Definition: </li></ul><ul><ul><li>Refactoring bezeichnet die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des beobachtbaren Programm-Verhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken. </li></ul></ul><ul><ul><li>Wikipedia </li></ul></ul>
  5. 5. Von
  6. 6. Zu
  7. 7. Und zu
  8. 8. Wie?
  9. 9. Live Coding & Übung
  10. 10. Grundlagen
  11. 11. MVC
  12. 12. Model <ul><li>Business-Model </li></ul><ul><li>Domain-Logik </li></ul><ul><li>Wiederverwendbar </li></ul>
  13. 13. Was macht das Model? <ul><li>Business-Logik kapseln </li></ul><ul><li>Nicht direkt auf Requests und Sessions zugreifen, höchstens indirekt </li></ul><ul><li>Schnittstelle zur Datenbank </li></ul>
  14. 14. View <ul><li>“ Dumme” Präsentation nach außen </li></ul><ul><li>Peilt spezifischen Use-Case an </li></ul><ul><li>Stellt Information dar </li></ul><ul><li>Unterschiedliche Sichtweisen auf Model </li></ul>
  15. 15. Was darf der View? <ul><li>Repräsentation erzeugen </li></ul><ul><li>Keine komplexeren Querys oder Code-Schnipsel </li></ul><ul><li>So wenig Instanzvariablen wie möglich verwenden </li></ul><ul><li>Datenbank-Querys aus dem View sind kein Verbrechen </li></ul>
  16. 16. Controller <ul><li>Dirigiert und verbindet </li></ul><ul><li>Vermittelt ans Model </li></ul><ul><li>Delegieren anstatt schuften </li></ul>
  17. 17. Was macht der Controller? <ul><li>Model finden und Aufrufe ins Model machen (Mediator) </li></ul><ul><li>Bestimmen welche Template zu rendern ist </li></ul><ul><li>Authentifiziering, Authorisierung </li></ul>
  18. 18. D R Y Principles
  19. 19. You Ain’t Gonna Need It <ul><li>Ron Jeffries: </li></ul><ul><ul><li>Implementiere Dinge nur wenn du sie tatsächlich brauchst, nicht wenn du denkst dass du sie brauchst. </li></ul></ul>
  20. 20. Live Coding Experiment
  21. 21. Redmine <ul><ul><li>A load-balancer distributes the incoming requests </li></ul></ul><ul><ul><li>Some load-balancers will deliver static requests themselves </li></ul></ul><ul><ul><li>Several Rails instances handle all requests </li></ul></ul><ul><ul><li>Number of concurrent requests equals number of Rails instances </li></ul></ul>
  22. 22. Redmine <ul><ul><li>In Entwicklung seit 2006 </li></ul></ul><ul><ul><li>Noch auf Rails 2.1 </li></ul></ul><ul><ul><li>Viele Faux-Pas die jeder mal gemacht hat </li></ul></ul>
  23. 23. Redmine <ul><ul><li>Multiple projects support </li></ul></ul><ul><ul><li>Flexible role based access control </li></ul></ul><ul><ul><li>Flexible issue tracking system </li></ul></ul><ul><ul><li>Gantt chart and calendar </li></ul></ul><ul><ul><li>News, documents & files management </li></ul></ul><ul><ul><li>Feeds & email notifications </li></ul></ul><ul><ul><li>Per project wiki </li></ul></ul><ul><ul><li>Per project forums </li></ul></ul><ul><ul><li>Time tracking </li></ul></ul><ul><ul><li>SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs) </li></ul></ul>
  24. 24. Do <ul><li>Models einführen wo angebracht, es besteht kein Datenbank-Zwang </li></ul><ul><li>Es ist in Ordnung, Parameter ins Model zu reichen und dort zu verarbeiten </li></ul><ul><li>View-Code gleichmäßig einrücken, wie allen anderen Code auch </li></ul><ul><li>Dinge mit ordentlichen Namen versehen, lieber zu lang als zu kurz </li></ul><ul><li>Helper verwenden anstatt Logik in den View zu stopfen </li></ul><ul><li>Noch besser: Logik ins Model verschieben </li></ul>
  25. 25. Do <ul><li>Ein Auge auf neue Rails-Features haben, machen u.U. das Leben leichter </li></ul><ul><ul><li>z.B. Object#try, Named-Scopes, Einfacheres render in Rails 2.3 </li></ul></ul><ul><li>Es muss nicht RESTful sein, Ressourcen sind aber als Guideline sinnvoll </li></ul><ul><li>Code in Module auslagern, egal ob im Controller oder Model </li></ul><ul><li>Komplexe Finder gehören ins Model, named_scopes to the rescue </li></ul>
  26. 26. Don’t <ul><li>Benutze nie Fixtures </li></ul><ul><li>self nur benutzen wo unbedingt notwendig </li></ul><ul><li>Einige Exceptions muss man nicht selbst abfangen </li></ul><ul><li>Keine Instanzvariablen im Controller nur für Darstellungslogik </li></ul>
  27. 27. Don’t <ul><li>Zugriff auf Instanzvariablen in Partials vermeiden, lokal gewinnt! </li></ul><ul><li>Komplizierte Konditionen sind State, gehören in Extra-Methoden </li></ul><ul><li>Exceptions wiederholt in Actions abfangen, rescue_action_in_public </li></ul><ul><li>Anstatt request.get? und request.post? neue Action einführen </li></ul><ul><li>return in einer Controller-Action </li></ul><ul><li>Validierungen im Controller, gehören ins Model </li></ul>
  28. 28. Praktischer Teil
  29. 29. Q & A
  30. 30. Peritor GmbH Blücherstr. 22 10961 Berlin Telefon: +49 (0)30 69 20 09 84 0 Telefax: +49 (0)30 69 20 09 84 9 Internet: www.peritor.com E-Mail: kontakt@peritor.com  Peritor GmbH - Alle Rechte vorbehalten

×