rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
Hallo Mario,
Am 12.10.2007 um 10:27 schrieb Mario Schroeder:
eine Frage, die etwas entfernt mit Rails zu tun hat, aber für mein
Railsprojekt wichtig ist, weil es sehr schnell wachsen wird und
andere Entwickler dazu stossen werden.Die Prozesse die abgebildet werden müssen sind erfasst.
Also Dinge wie Check-In-Zyklus, CI, Deployment?
Die Weboberfläche ist designed
Das ist meiner Erfahrung nach von Vorteil (also wenn die Oberfläche
am Anfang schon steht).
Wann entwerfe ich das Datenbankmodell und kann ich das zu einem
späten Zeitpunkt erweitern und/oder migrieren?
Während der Entwicklung. Rails ist explizit darauf ausgelegt das
Datenmodell iterativ zu entwickeln und entsprechend und migrieren:
http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations
Was aber viel wichtiger ist. Wie organisiere ich meine Arbeit am
besten, dass neue Entwickler schnell und einfach den Einstieg
finden können.
Rails sieht ja ein Standard-Projektlayout vor, daher ist es meiner
Erfahrung nach sehr einfach sich in neue Rails-Anwendungen einzulesen
und sich schnell zurecht zu finden.
Dokumentation ist gut, aber gibt es dafür gute Tools oder genügt
die Dokumentation im Quellcode?
Zum einen gibt es ja Rdoc (für Doku-Generierung aus dem Code). Außer
bei “Library-artigen” Funktionaltäten verwende ich das bei Rails
eigentlich sehr selten. Controller sind meist selbsterklärend (wenn
man sie entsprechend schlank hält) und die Models sind auch meist
sehr deskriptiv.
z.B.
class User < AR::B
has_many :tickets
acts_as_searchable
end
Das braucht nun wirklich keine weitere Doku mehr. Meist reicht es,
wenn man Code, der auf den ersten Blick nicht verständlich ist in
eine Methode mit sprechendem Namen zu extrahieren und man kann sich
die zusätzliche Doku sparen.
z.B.
user can receive credits after 3 months of membership
if user.created_at < 3.months.ago
send_credits
end
vs.
if user.can_receive_credit?
send_credits
end
und im User dann eben
def can_receive_credit?
user.created_at < 3.months.ago
end
Um zu kommunizieren “warum” man etwas tut, gibt es ja noch die Tests
(wenn man Test::Unit verwendet) oder Specs (bei RSpec).
Meine persönliche Einstellung zum Thema Doku ist etwa so:
Folgende Fragen will man ja gewöhnlich beantworten:
“Wie wird etwas getan?” → Code
“Was wird getan?” → Code (vor allem sprechende Methodennamen)
“Warum wird etwas getan?” → Tests
Kommentare sind meiner Meinung dann sinnvoll, wenn man irgendwelche
obskuren Dinge tut und direkt im Code kommunizieren möchte warum dies
so ist
We have to use the strange format YYYY-DD-MM here, because the
external interface wants it that way
Das war zwar jetzt irgendwie alles sehr allgemein geraten, aber hat
dann doch mit Rails/Ruby zu tun, weil man da aufgrund der Art wie
Ruby als Code aussieht, mit relativ wenig Kommentaren/Doku auskommt.
Just my 2 cents… YMMV 
Gruß,
Hendrik