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

Transkript

1 Refactoring Rails Applications Mathias Meyer und Jonathan Weiss, 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 2

3 Who am I? Mathias Meyer Chief Cloud Officer bei Peritor GmbH in Berlin Rubyist Asynchronist Post-Relationalist 3

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 4

5 Von 5

6 Zu 6

7 Und zu 7

8 Wie? 8

9 Live Coding & Übung 9

10 Grundlagen 10

11 MVC 11

12 Model Business-Model Domain-Logik Wiederverwendbar 12

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

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

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 15

16 Controller Dirigiert und verbindet Vermittelt ans Model Delegieren anstatt schuften 16

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

18 Principles D R Y 18

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. 19

20 Live Coding Experiment 20

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 21

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

23 Redmine Multiple projects support Flexible role based access control Flexible issue tracking system Gantt chart and calendar News, documents & files management Feeds & notifications Per project wiki Per project forums Time tracking SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs) 23

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 24

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 25

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 26

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 27

28 Praktischer Teil 28

29 Q & A 29

30 Peritor GmbH Blücherstr Berlin Telefon: +49 (0) Telefax: +49 (0) Internet: kontakt@peritor.com Peritor GmbH - Alle Rechte vorbehalten 30 30