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

PrinciplesD R Y

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.

20

Live Coding Experiment

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

30

Peritor GmbH

Blücherstr. 2210961 Berlin

Telefon: +49 (0)30 69 20 09 84 0Telefax: +49 (0)30 69 20 09 84 9

Internet: www.peritor.comE-Mail: kontakt@peritor.com

Peritor GmbH - Alle Rechte vorbehalten