Refactoring Rails Applications Mathias Meyer und Jonathan Weiss, 01.09.2009 Peritor GmbH

Mathias Meyer und Jonathan Weiss, 01.09.2009

Peritor GmbH

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

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

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

Mathias Meyer

Chief Cloud Officer bei Peritor GmbH in Berlin

Rubyist

Asynchronist

Post-Relationalist

http://www.paperplanes.de

http://www.dailyawswtf.com

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

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

Von

Zu

Und zu

Wie?

Live Coding & Übung

Grundlagen

MVC

Model Business-Model Domain-Logik Wiederverwendbar

Business-Model

Domain-Logik

Wiederverwendbar

Was macht das Model? Business-Logik kapseln Nicht direkt auf Requests und Sessions zugreifen, höchstens indirekt Schnittstelle zur Datenbank

Business-Logik kapseln

Nicht direkt auf Requests und Sessions zugreifen, höchstens indirekt

Schnittstelle zur Datenbank

View “ Dumme” Präsentation nach außen Peilt spezifischen Use-Case an Stellt Information dar Unterschiedliche Sichtweisen auf Model

“ Dumme” Präsentation nach außen

Peilt spezifischen Use-Case an

Stellt Information dar

Unterschiedliche Sichtweisen auf Model

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

Repräsentation erzeugen

Keine komplexeren Querys oder Code-Schnipsel

So wenig Instanzvariablen wie möglich verwenden

Datenbank-Querys aus dem View sind kein Verbrechen

Controller Dirigiert und verbindet Vermittelt ans Model Delegieren anstatt schuften

Dirigiert und verbindet

Vermittelt ans Model

Delegieren anstatt schuften

Was macht der Controller? Model finden und Aufrufe ins Model machen (Mediator) Bestimmen welche Template zu rendern ist Authentifiziering, Authorisierung

Model finden und Aufrufe ins Model machen (Mediator)

Bestimmen welche Template zu rendern ist

Authentifiziering, Authorisierung

D R Y Principles

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.

Ron Jeffries:

Implementiere Dinge nur wenn du sie tatsächlich brauchst, nicht wenn du denkst dass du sie brauchst.

Live Coding Experiment

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

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

Redmine In Entwicklung seit 2006 Noch auf Rails 2.1 Viele Faux-Pas die jeder mal gemacht hat

In Entwicklung seit 2006

Noch auf Rails 2.1

Viele Faux-Pas die jeder mal gemacht hat

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)

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)

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

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

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

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

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

Benutze nie Fixtures

self nur benutzen wo unbedingt notwendig

Einige Exceptions muss man nicht selbst abfangen

Keine Instanzvariablen im Controller nur für Darstellungslogik

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

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

Praktischer Teil

Q & A

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