|
|
|
| Sitemap |
Ein Blog-Eintrag von Martok (Mo 28.02.11 01:46)
Views: 1968850
|
oder
Von einem der auszog gewachsenen Code zu verstehen
Um eine vernünftige Basis für weitere Entwicklungen zu haben, wurde bereits vor laaaaaaaanger Zeit beschlossen, dass das Forum was die Ajax/DHTML-Funktionen betrifft auf ein "erwachsenes" Framework umzustellen. Mehr durch Zufall ("Was wollen wir benutzen?" - "Mir egal." - "Gut, ich kenne nur jQuery...") ist vor mindestens genauso langer Zeit die Entscheidung auf eben dieses jQuery gefallen. Nun kennt das der ein oder andere vielleicht: wenn man vor einem so riesigen Haufen gewachsenem Code steht, ist die Motivation das umzuräumen nicht selten eher klein.
Aber hilft ja nix, muss man durch.
Gleichzeitig sollte aber noch etwas passieren. Wer schonmal Firebug offen hatte während das DF offen war, wird im DOM-Tab einiges bemerkt haben: phpBB wirft mit unglaublich vielen Variablen im Global Scope (wie wir JSler sagen), also freifliegend, ohne Sicherungsnetz. Das steht bei Crockford auf den ersten paar Seiten, dass man genau das niemals tun sollte - erzeugt unüberschaubare Fehler. Und vor allem unüberschaubaren Code, denn in dieser Form weiß man nie so genau, wo eine Variable jetzt eigentlich herkommt und schon gar nicht ob sie irgendwann nochmal verwendet wird. Grade das sollte sich noch zu einem Problem entwickeln...
Der Ansatz hier war anfangs recht simpel: erstmal alles 1:1 portieren und dann schauen, wo man optimieren kann. Für so "simple" Sachen wie Die Letzten 10 hat das auch noch recht gut funktioniert, aber an der Shoutbox war dann auch Feierabend. Das direkt zu portieren war schon auf den ersten Blick Unfug: immerhin kenne ich den Code zu genüge, da beschäftigt sich ja fast die Hälfte des EdgeMonkey mit 
Also wurde die Erste Direktive etwas angepasst: erstmal grob portieren und bestehende Strukturen beibehalten. Ich muss sagen: man hätte damit anfangen sollen Definitiv der beste Einstieg in so eine Aufgabe.
Damit kam ich dann immerhin bis zum Beitragseditor. Aber nicht viel weiter, denn was ich nicht wusste: das Ding ist die größte Ansammlung von Browserweichen die jemals geschrieben wurde  Das Meiste davon betrifft ein und dasselbe Problem: Selection in Textfeldern. Und da gibt es wie so oft den DOM-Weg und den IE. Und ratet mal wer davon zuverlässiger funktioniert
Damit also Versuch Nummer 3: gucken was der Code tut und neu schreiben. Ich weiß, ist nicht sonderlich kreativ, aber wenn der ganze Kram hinreichend kompliziert ist, funktioniert das doch irgendwie am Besten.
Hier hab ich dann mal das getan, worüber sich Christian hinterher richtig gefreut hat: ich hab mein erstes jQuery-Plugin geschrieben - eine allgemeine Abstraktion für Textauswahl. Das ganze lässt sich jetzt so bedienen, wie wir das als Delphine alle kennen: Start, Ende, Länge und Text, und das für alle Browser absolut identisch. Damit wird dann auch der restliche Code wesentlich kürzer... dachte ich.
Aber dem war eher nicht so...
... erstmal ist das ganze nämlich 100 Zeilen länger geworden. Genau soviele Zeilen umfasst nämlich das Selection-Plugin. Man muss aber sagen, die Arbeit hat sich gelohnt, denn sowohl die Tag- als auch die SplitQuote-Funktionen sind wahnsinnig viel kürzer geworden. Und was da dran viel besser ist: sie haben sogar auf Anhieb funktioniert... bis ich sie mal auf Echte Beiträge losgelassen hab. Zwei Lektionen:
- Wenn man Code guttenbergt, sollte man auf die verwendeten Variablennamen aufpassen. Wenn man first an second zuweist sollte man sich nicht wundern, dass es hinterher nicht funktioniert.
- der IE ist ein Win32-Produkt. Nicht lachen, das spielt wirklich eine Rolle
In Mozilla und Opera ist nämlich in textarea.value der Text lediglich durch #10 getrennt. Im Gegensatz dazu verwendet der IE zufälligerweise Win32-LineBreaks: #13#10. Wenn man das nicht weiß, führt das zu lustigen Effekten sobald man mehrere Zeilen hat und z.B. in der 3. Zeile etwas einfügen will... da sind dann auf einmal 2 Zeichen zuviel vorhanden und die Einfügung passiert zu weit vorn. Sehr interessantes Fehlerbild, tritt auch nie auf wenn man testet - weil zumindest ich da immer nur eine Zeile getippselt hatte.
Ich erwähnte grade das Problem mit kopiertem Code... nun stellt euch mal vor, es existieren nicht nur 2 Variablen, sondern dazu noch über 20 globale. Unvorstellbar? So ist es aber gewesen. Deswegen stand parallel auch ein Umbau auf ein etwas sinnigeres Prinzip auf dem Plan. Hier haben wir uns dafür entschieden, die jeweiligen Module (meistens Modul=Quelldatei) in Closures zu verpacken. Wer's nicht kennt: das sind die sonderzeichenreichsten Konstruktionen in JS:
  JS-Quelltext
Im Endeffekt kann man sich damit ein neues Scope erzeugen, dessen private Variablen auch wirklich privat sind. Um gezielt einzelne Funktionen zu veröffentlichen, verwenden wir das, was andere Sprachen Namespaces nennen würden und was auch der Edgemonkey schon so ähnlich tut: es gibt Dummy-Objekte mit sprechenden Namen, denen dann Methoden zugeordnet werden. Damit bestimmt man ganz bewusst, wenn man etwas im Global Scope hinterlassen will - viel besser als der Zustand vorher, nicht wahr?
Und weil ich euch was Unterhaltsames versprochen hab, aber der Beitrag bisher eher technisch war, gibts den Witz einzeln hinterher:
 Martok hat folgendes geschrieben: | | Ui, ich sehe grad eine Moderatoren-Funktion zum ersten mal: Sourcecode-Tags neu hinzufügen für eine Textauswahl. Hab das bisher immer von Hand gemacht |
So kanns einem gehen, wenn man in den Untiefen undokumentierten Codes gräbt
Viele Grüße und bis zum nächsen Mal (dann hoffentlich mit ersten gefixten WAK-Einträgen),
Sebastian
 Kommentar von Christian S. (Mo 28.02.11 09:05)
Die Closures hatte ich vor Deinem ersten Checkin tatsächlich noch nie gesehen, die waren eine wirkliche Offenbarung 
Kommentar von Regan (Mo 28.02.11 11:23)
Es wäre nebenbei auch noch interessant, in wie fern das die Ladezeiten sowohl von der Seite als auch der einzelnen Aktionen verändert hat. jQuery ist zwar sehr mächtig, dennoch hat selbst geschriebener Code oftmals den Geschwindigkeitsvorteil.
Kommentar von Martok (Mo 28.02.11 16:53)
Ladezeiten haben sich genau gar nicht geändert, das wird eh alles aus dem Cache bedient. Dafür ist der Code überwiegend kürzer geworden (Beispiel: posting.js von 1100 Zeilen + Code im HTML  780Zeilen ohne Extracode)
Die Ajax-Refresh-Dinger fühlen sich responsiver an... das kann aber auch daran liegen dass momentan ja Synchrone Requests gemacht wurden - die sind immer etwas holprig
Und was den Rest angeht kann ich keinen fühlbaren Unterschied vorweisen, selbst wenn ich den Laptop auf niedrigste Taktrate stelle, da merkt sonst man sowas eigentlich ziemlich stark. Für das bisschen was hier auf eine User-Aktion hin passiert muss man sich da keine Sorgen machen.
Oh und: jQuery-Quältext lässt sich besser JITten, weil man viel weniger Code Duplication hat.
Kommentar von BenBE (Mi 02.03.11 14:24)
Wieviele der im Würgarounds notwendigen Würgarounds lassen sich auf Grund dieser Änderungen demnächst als Legacy-Code bezeichnen?
Die Problematik mit #13#10 vs. #10 vs. #13 ist übrigens der Grund, warum ich beim GeSHi als einer der ersten Schritte die Linebreaks generell normalisiere. Das Erspart einiges an Arbeit.
Erste Veränderungen habsch aber schon gemerkt Denn ein paar Dinge funktionieren jetzt nicht mehr ...  Aber dazu an anderer Stelle mehr. 
Du hast Methode 2.5 überhaupt vergessen auszuprobieren: Verantwortlichen suchen und so lange prügeln, bis der Code von sich aus besser wird. 
Kommentar von jaenicke (Mi 02.03.11 22:39)
@Christian:
Das hätte ich nicht gedacht. Closures kannte und nutze ja sogar ich, und ich bin kein besonderer JavaScript Spezialist.
|
|
