Große JS-Dateien

[Rolf B]

Hallo fischlak,

ich arbeite bei größeren Themen objektorientiert, weil man damit den Code gut strukturieren kann. Kleinere Themen kann man rein funktional gut realisieren.

Ich beachte die Clean Code Maximen von Robert Martin. Die Zeilenzahl einer Methode ist kein Kriterium, sondern dies: Eine Methode soll genau eine Sache tun (Koordinieren anderer Methoden ist auch eine Sache). Damit sieht man ihr an, was sie tut, und wenn sie gut benannt ist, muss der Aufrufer nicht unbedingt in den Code schauen, um zu wissen, was passiert. Man soll Dinge nicht mehrfach an unterschiedlichen Positionen programmieren. DRY (don't repeat yourself) statt WET (write everything twice). Wenn eine Methode 50 Zeilen oder mehr hat, dann tut sie in den meisten Fällen mehr als eine Sache und sollte zerlegt werden.

In C# arbeite ich mit Dependency Injection. Das vereinfacht - oder ermöglicht erst - das Mocken für Unit Tests und hilft der Codestabilität. In JavaScript habe ich dafür noch keinen guten DI-Container gefunden, und bei stark UI-lastigen Programmen sind Unit Tests auch weniger hilfreich.

In JavaScript packe ich meine Klassen in Module, jedes in einer eigenen Datei. Für den Produktionscode werden sie gebündelt und minifiziert. Da meine Anwendung schon älter ist und auch im IE lief, ist das Tool dafür noch require.js. Es sind aber nur ca 1000 Zeilen JavaScript. Ein großer Teil der Logik läuft auf dem Server (ASP.NET mit C#). Daher kommt Visual Studio (das große, nicht Code) als Editor-Tool, mit Folding und Intellisense. Wobei ich Folding selten benötige.

Natürlich hat man durch Clean Code mehr Codezeilen. Es mag auch etwas langsamer sein. Aber ich komme damit besser klar als mit 1000 Zeilen langen Funktionen, wo man am Ende nicht weiß, was am Anfang passiert ist und man sich mit den Variablen ständig gegenseitig auf den Füßen steht.

Arbeit im Team? In den letzten Jahren betreibe ich meine Projekte alleine. Aber trotzdem ist eine saubere Modularisierung viel sinnvoller als alles in einer Riesendatei zu haben. Visual Studio hilft mir dabei sehr mit der Funktion "Go To Definition". Damit ist man, wenn man einer Aufrufkette folgen will, immer schnell am Ziel. Ich habe auch Projekte in größeren Teams gemacht. Dort bin ich mit OOP eher auf Schwierigkeiten gestoßen, weil Refactoring öfter man den Code der Kollegen zerbröselt hat. Aber das war, bevor ich von SOLID gehört hatte. Richtig verstanden habe ich es immer noch nicht…

Also kurz gesagt: Meine Arbeitsweise ist so ziemlich das Gegenteil von Deiner. Vor 41 Jahren habe ich bei deiner Arbeitsweise angefangen. Mit COBOL. Und im Lauf der Jahrzehnte genug Schmerzen damit gehabt, um OOP und Clean Code schätzen zu lernen.

Rolf