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