16-mal heruntergeladen
Hochgeladen vonJonathan Weiss
Refactoring Rails Applications
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.
Weitere ähnliche Inhalte
Refactoring Rails Applications
- 1. Refactoring Rails ApplicationsMathias 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: Refactoringbezeichnet 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.
- 6.
- 7.
- 8.
- 9. Live Coding &Übung
- 10.
- 11.
- 12. Model Business-Model Domain-LogikWiederverwendbar
- 13. Was macht dasModel? 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 derView? 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 undverbindet Vermittelt ans Model Delegieren anstatt schuften
- 17. Was macht derController? Model finden und Aufrufe ins Model machen (Mediator) Bestimmen welche Template zu rendern ist Authentifiziering, Authorisierung
- 18. D R YPrinciples
- 19. You Ain’t GonnaNeed It Ron Jeffries: Implementiere Dinge nur wenn du sie tatsächlich brauchst, nicht wenn du denkst dass du sie brauchst.
- 20.
- 21. Redmine A load-balancerdistributes 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 Entwicklungseit 2006 Noch auf Rails 2.1 Viele Faux-Pas die jeder mal gemacht hat
- 23. Redmine Multiple projectssupport 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ührenwo 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 Augeauf 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 nieFixtures 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 aufInstanzvariablen 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.
- 29.
- 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