Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
In alten Code zurück- und dort wieder zurechtfinden?
Hallo zusammen,
nach arbeitsbedingter Abwesenheit von den wirklich wichtigen Dingen im Leben (wie Java ) versuche ich gerade endlich mal wieder, mich in einen alten Code zurückzufinden. Trotz reichlicher Kommentare tue ich mich unglaublich schwer, da wieder reinzukommen und da weiter zu machen, wo ich aufgehört habe. Ich habe vllt. auch etwas viel auf einmal machen wollen und einige Baustellen gleichzeitig eröffnet... hat jemand ein paar Tipps, wie man sich wieder einen Überblick verschafft? (z.B. ja auch nötig, wenn man sich in Fremdcode einarbeiten muss)
Kommt das bei euch auch schonmal vor und wie geht ihr das an, wenn ihr nach einigen Wochen an einem Projekt weiterarbeiten wollt?
Vllt. gibts ja den ein oder anderen Tipp (auch hinsichtl. zukünftiger Arbeiten), wie man Code "zurücklassen" sollte, damit man den Faden leicht wieder aufnehmen kann.
LG
Für die Zukunft:
Grundsätzlich würde ich auf Kommentare tunlichst verzichten. Schreib den Code lieber so, daß du ihn als Fließtext lesen kannst. Da kann man ruhig auch mal Methoden einfügen, um einem Arbeitsschritt einen Namen zu geben. So z.B.:
Java:
void tryToMakeBetterCode(){
file = grabFileFromServer();
//...
}
File grabFileFromServer{
if(isNetworkAvailable()){
openServerConnection();
}
else{
return null;
}
if(fileExists()){
return downloadFile();
}
return null;
}
boolean isNetworkAvailable(){
//...try a ping and wait a seccond
}
void openServerConnection(){
//See Java tutorials how to do this
}
File downloadFile(){
//See Java tutorials how to do this
}
Zugegeben, das wäre mit Tenäroperator noch besser lesbar, aber ich denke du bekommst eine Ahnung davon was ich meine. Und ja, es dauert manchmal etwas bis man das perfekt formuliert hat, und da gehen durchaus mal fünf Minuten und eine Tasse Kaffee drauf bis man einen griffigen Bezeichner ersonnen hat. Aber du siehst ja gerade selber, warum man sich diese Arbeit machen sollte.
Und am Besten geht schon aus den Klassen- und Paketbezeichnungen das Konzept hervor, daß du umsetzen willst.
Ich habe übrigens selber schon erlebt, daß diese Vorgehensweise absolut sinnvoll ist und auch was bringt. Ich habe mein jCLS-Projekt jetzt sicher ein bis zwei Jahre ruhen lassen, und ich werde mich da ganz sicher wieder reinfinden.
Für jetzt:
Würde ich dir raten, deinen Code entsprechend umzubauen. Das ist zeitintensiv, ja, aber hilft dir beim Verständnis und sorgt dafür, daß du künftig nicht mehr in Verständnisprobleme läufst.
Für Fremdcode könnte dir SourceTrail helfen, für eigenen Code und schlechten Code ist das aber wenig sinnvoll.
Und ja, es dauert manchmal etwas bis man das perfekt formuliert hat, und da gehen durchaus mal fünf Minuten und eine Tasse Kaffee drauf bis man einen griffigen Bezeichner ersonnen hat.
Gut formulieren: Ja.
Auf Dokumentation verzichten: Nein
Innerhalb der Methode ist es vielleicht nicht immer von Vorteil, außer es handelt sich um einen komplexen Algorithmus, aber die Methode sollte in jedem Fall so dokumentiert sein, dass ihr Verhalten von außen ersichtlich ist (was passiert z.B. bei null-Werten oder wenn ein negativer double übergeben wird, wo nur positive vorgesehen sind?). Die Dokumentation darf hierfür gerne länger sein als der eigentliche Quelltext.
Bei private Methoden ist das jetzt nicht ganz so wichtig, aber bei public-Methoden muss die auf jeden Fall rein. Bei "downloadFile()" gehört meiner Meinung nach z.B. hinen, was passiert, wenn der Download abbricht. Kriegt man dann null oder ist das File-Objekt unvollständig? Kümmert sich die Methode selbst um Resume oder muss von außen reagiert werden?
Also der Themenkomplex, um den Du Dich kümmern solltest, ist Clean Code.
Wenn man da einen Einstieg haben will, dann kann ich nur www.clean-code-developer.de empfehlen. Dort findet man eine schrittweise Einführung in das Thema. Die einzelnen Punkte kommen dann Schritt für Schritt und man wird nicht von Anfang an überfordert.
Man kann aber ein paar Regeln relativ einfach aufstellen:
- Technische Grundlagen müssen sein! Dazu gehören eine Source Code Verwaltung wie git. Ohne geht es nicht.
- Code muss sauber strukturiert sein! Dazu gehört die ganze Unterteilung in Komponente, Klassen und Methoden. Die Abhängigkeiten müssen auf allen Ebenen klar und sauber sein! Da kommen dann diverse Pattern ins Spiel wie MVC oder Strategy Pattern um zwei Beispiele zu nennen. Das ist aber natürlich ein großes Themengebiet und es gibt viele Bücher dazu und auch viele unterschiedliche Ansätze.
- Theorie: SOLID Principles - Aus meiner Sicht sind das mit die wichtigsten Regeln überhaupt. Diese nicht einzuhalten führt eigentlich immer zu Problemen. Aber das ist leider recht theoretisch - ich erlebe immer wieder, dass es gerade am Anfang schwer ist, das in der Praxis um zu setzen.
- Praktische Regel: Code muss lesbar sein. Das ist ja schon angeklungen. Und dazu gibt es einfache Mittel: Du kannst Einheiten klein halten. Also lieber mehr kleine Methoden mit guten Namen haben. Hier ist es wichtig, dass die Bezeichner genau beschreiben, für was sie stehen. Und das kann so weit gehen, dass man Bedingungen einer if Anweisung in Methoden packt um da dann direkt etwas lesen zu können a.la. "if (order.isValid())` oder so. Das kann man schon für ganz einfache Dinge machen. [URL='https://www.java-forum.org/thema/test-driven-development-anhand-von-fizzbuzz.189510/']FizzBuzz Beispiel[/URL] aus der TDD Einführung: if (isFizz(x)) wo isFizz nur prüft x % 3 == 0``
- Praktische Regel: Es gibt keine Kommentare im Code selbst (es gibt nur sehr wenig Ausnahmen!)
Nehmen wir einfache in Beispiel:
Du hast paar Code Zeilen, zu denen willst Du etwas schreiben:
Java:
// mache etwas wichtiges
whatever.doSomething(...);
somethingElse.doImportantStuff(...);
==> Bessere Aufteilung und damit wird der Bezeichner der Methode sozusagen zu dem Kommentar.
Die Kommentare, die es auf jeden Fall gibt oder geben kann: JavaDoc: Es gibt also nicht offensichtliche Dinge. Es wird z.B. eine fachliche Anforderung umgesetzt. Da kommt dann JavaDoc ins Spiel: Dinge können auf der Ebene der Klasse oder der Methode erläutert werden.
- Praktischer Hinweis: Ich nutze gerne Statische Codeanalyse Tools. (PMD, FindBugs, ...) Die Regeln sind nicht alle immer sinnvoll, aber wenn man eine Regel nicht befolgt, dann kann man sich mit dieser beschäftigen: Was verlangt die Regel aus welchem Grund? Dann stellt man seinen Code ggf. um, man macht im Code eine Ausnahme oder man nimmt die Regel ganz raus.
Beispiele können hier z.B. sein:
PMD: Es gibt eine Regel, die System.out.println verbietet. Zielt halt auf Server Applikationen. Bei einer Konsolen-Anwendung ist das natürlich Quatsch
PMD: Law of Demeter - Das ist eine ganz wichtige Regel! Damit werden Verkettungen unterbunden, also sowas wie getSomething().getSomethingElse().getAnotherThing().doSomething()
Das Problem wird deutlich: Ich bin in irgendwas und dann gehe ich in Something um dann weiter zu gehen nach SomethingElse um da mit AnotherThing etwas zu machen. Das ist natürlich absurd und bricht jede Kapselung. Die Regel ist aber deaktiviert, denn Builder und Streams werden leider auch angemeckert.
Wie kann man weiter vorgehen?
www.clean-code-developer.de
Hier wird man in mehreren Graden an Clean Code heran geführt. Man wird also nicht massiv erschlagen sondern hat immer nur um 4 Prinzipien und 4 Praktiken pro Grad, die dann neu sind.
Ich bin mal so frech: Wenn man nach einem halben Jahr nicht mehr weiß, was der eigene Code tut, so ist das ein Anzeichen dafür, ihn beim nächsten Mal besser zu schreiben, weil man sich nicht an "Clean Code Xy" gehalten hat.
Leider ... "widersprechen" sich manche Clean-Code-Prinzipien, sodass man diese nur dosiert einsetzen sollte. Oder anders: Man muss es erst lernen (so wie viele andere Dinge auch; wer konnte mit 4 schon Klavierspielen oder Fahrradfahren?).
Ja...Dokumentation kommt in die JavaDoc, die ist wichtig und darf gerne ausführlich sein. Besser: Erst eine kurze Zusammenfassung, und danach noch gegebenenfalls ein sehr ausführlicher Absatz.
Aber JavaDoc sind für mich keine Kommentare. Unter Kommentar verstehe ich, was im Code selber steht und als Kommentar deklariert ist.
Puh ja danke euch allen. Hilft mir JETZT leider nicht mehr weiter Aber für die Zukunft natürlich, klar. Clean Code als Zauberwort ist mir ein Begriff und der Sinn dahinter absolut verständlich. Aber das tatsächlich bewusst und immer anzuwenden, da fehlt mir leider der Praxisbezug bzw auch die Erfahrung. Vllt. bemühe ich mich doch mal um ein Praktikum in der Softwareentwicklung, in der Hoffnung, dass mir mal jemand unmittelbar Feedback geben kann ..
Allgemein:
Wie geht ihr vor, wenn ihr Fremdcode bearbeitet, z.B., wenn ihr in ein schon laufendes Projekt einsteigt? Wo und wie fangt ihr an, euch da durchzuarbeiten?
Wie geht ihr vor, wenn ihr Fremdcode bearbeitet, z.B., wenn ihr in ein schon laufendes Projekt einsteigt? Wo und wie fangt ihr an, euch da durchzuarbeiten?
Und nur weil da "neu schreiben" genannt wurde: Das mag teilweise die beste Lösung sein, so lange es um kleine Projekte geht oder wenn die Defizite zu groß sind und damit Änderungen extrem erschwert werden.
Aber natürlich kann man auch mit Legacy Code gut umgehen. Das muss man aber natürlich auch erst einmal können. Und das ist eine Thematik, die auch von Büchern abgedeckt wird, z.B. https://www.amazon.de/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
Wobei die Amazon Daten schlicht Müll sind. Wie die auf Robert C. Martin kommen verstehe ich nicht. Das Buch ist von Michael C. Feathers. Uncle Bob hat da ein Vorwort geschrieben, aber sonst ....
Und was da ein ganz wichtiger Schritt ist: Man muss verstehen, was die Entwickler bei der Erstellung gedacht haben. Nur weil wir heute andere Vorgehen haben, bedeutet das ja nicht, dass das Vorgehen früher generell schlecht gewesen ist. Und wenn man eine Software sieht, dessen Entwicklung vor 30 Jahren anfing und heute immer noch gewartet und erweitert werden kann, dann sollte klar sein, dass es vor allem Anders ist aber nicht zwingend generell schlechter. (Das Vorgehen mag auf PM Sicht geringere Chancen auf Erfolg haben, aber das ist dann nicht zwingend der Fall.
Was ein großer Bestandteil von Clean Code ist, sind Refactorings. Und die muss man gut kennen und beherrschen. Denn das ist der richtige Weg um eben zu verhindern, dass Code "verrottet". Und gerade am Anfang würde ich daher auch immer raten: Statt Code neu zu schreiben: Probiere Refactorings aus! Das ist etwas, das man zwingend lernen muss.
Und wo ich gerade dabei bin: Es ist für mich irritierend, wenn jemand lange über einen Bezeichner nachdenkt. Also die Vorstellung: Ich nehme mir einen Kaffee und dann sitze ich da und denke über einen Bezeichner nach. Mir fehlt da irgendwie das Verständnis. Und wenn da jemand beim 4. Kaffee ist, dann läuft etwas ganz schief aus meiner Sicht! Da hat dann jemand schlicht nicht Voraussetzungen, um an dem Projekt zu arbeiten. Da fehlt ggf. eine Einarbeitung ins fachliche. Da hilft dann ein Gespräch oder so. (Das Verständnis wird aber bei agilem Vorgehen doch im Rahmen der Sprint Vorbereitung erarbeitet. Wie kann man sonst Stories / Tasks bewerten? Oder wenn man nicht agil arbeitet, dann hat man eine Analyse / Planungsphase. Wie kann man ohne sowas etwas entwickeln? Man setzt sich einfach an den Rechner und macht einfach? Und mal schauen, was dabei raus kommt?)
Also: Wenn ich etwas entwickeln soll, dann ist der erste Schritt das fachliche Verständnis. Ich weiss also, was ich machen muss. Und dann kann ich direkt Code schreiben. Der erste Gedanke mag nicht optimal sein, aber es reicht um zu starten. Wenn man dann etwas implementiert, dann sieht man auch direkt, ob etwas richtig ist oder nicht. Ob als die Methode wirklich aussagt, was ich in der Methode entwickle. Diesen Prozess der Verarbeitung und der Prüfung gibt es also immer. Das ist wie bei Klausuren: Erst alle Aufgaben einmal durchlesen. Das kostet nicht viel Zeit und das Gehirn kann unbewusst an Dingen arbeiten. Dann löst man die Aufgaben, die man schnell lösen kann. Und dann erst kommen die Zeitfresser. Und die sind dann oft deutlich leichter zu lösen als ursprünglich gedacht.
Und wenn ein Bezeichner nicht gut ist: Dann benennt man den um. Wo ist das Problem? Das ist ein Tastendruck, Name anpassen, fertig!
Die einzige Ausnahme sind Interfaces nach außen. Wenn ich mit Swagger eine API definiere, dann wird das einmal gemacht. Da muss man dann also sicherer sein. Aber das mache ich nicht, indem ich da 4 Kaffee trinke, während ich über einen Namen nachdenke. Auch da erstelle ich die API nach meinem fachlichen Verständnis, welches in einem Meeting erarbeitet wurde. Und da die Bezeichner wichtig sind, gibt es da ein entsprechendes Review vom ganzen Team und von fachlichen Experten. Also viel Aufwand rund um die Bezeichner bei APIs: Ja, aber nicht in der beschriebenen Form!
Ich nehme mir einen Kaffee und dann sitze ich da und denke über einen Bezeichner nach. Mir fehlt da irgendwie das Verständnis. Und wenn da jemand beim 4. Kaffee ist, dann läuft etwas ganz schief aus meiner Sicht! Da hat dann jemand schlicht nicht Voraussetzungen, um an dem Projekt zu arbeiten.
Mir scheint, du hast doch arge Verständnisschwierigkeiten, was agile Entwicklung ist - vielleicht neben den Voraussetzungen, um guten Code zu schreiben.
Es geht keinesfalls darum, schnell schlechten Code zu schreiben - es sei denn, den soll hinterher keiner mehr lesen oder anfassen.
Naja, aber so hat wohl jeder seine eigenen Vorstellungen, wie gutes Projektmanagment zu sein hat. Gut das ich nicht bei Konrad arbeite.
Was ein großer Bestandteil von Clean Code ist, sind Refactorings. Und die muss man gut kennen und beherrschen. Denn das ist der richtige Weg um eben zu verhindern, dass Code "verrottet". Und gerade am Anfang würde ich daher auch immer raten: Statt Code neu zu schreiben: Probiere Refactorings aus! Das ist etwas, das man zwingend lernen muss.
Ah, das habe ich noch vergessen. Da zeigt sich dann durchaus, was eine IDE so alles kann. Einfach mal eine Variable markieren, Rechtsklick, und dann schauen ob es da einen Menüpunkt "Refactoring" oder so ähnlich gibt und was der alles bereithält...
Was für Dokumentation schreibst Du wie? Das würde mich mal interessieren. Vor allem die Bezeichner werden alle irgendwo dokumentiert?
Die Software selbst hat JavaDoc - schau Dir mal die Refactoring Möglichkeiten von aktuellen IDEs an... Dann wüsstest Du, dass dort dann auch alles mit umbenannt wird.
Und zu den APIs habe ich bereits explizit etwas geschrieben....
Mir scheint, du hast doch arge Verständnisschwierigkeiten, was agile Entwicklung ist - vielleicht neben den Voraussetzungen, um guten Code zu schreiben.
Es geht keinesfalls darum, schnell schlechten Code zu schreiben - es sei denn, den soll hinterher keiner mehr lesen oder anfassen.
Naja, aber so hat wohl jeder seine eigenen Vorstellungen, wie gutes Projektmanagment zu sein hat. Gut das ich nicht bei Konrad arbeite.
Jetzt hast Du Dich 1 Woche zusammen gerissen - Hätte nicht gedacht, dass Du es schaffst, 7 Tage nicht gebannt zu werden ... Aber das ist jetzt vorbei.
Statt so dummes Zeug zu schreiben könntest Du einfach mal paar Argumente bringen. Aber Dir geht es mal wieder nur um pers. Angriffe. Es ist immer interessant, mit anderen Entwicklern Argumente auszutauschen. Nur dann kommt immer wieder der kleine Tobias und will aus dem Bällespieleparadies abgeholt werden ....
Ah, das habe ich noch vergessen. Da zeigt sich dann durchaus, was eine IDE so alles kann. Einfach mal eine Variable markieren, Rechtsklick, und dann schauen ob es da einen Menüpunkt "Refactoring" oder so ähnlich gibt und was der alles bereithält...
Vor allem geht das Refactoring wirklich über alles. So werden auch Referenzen in Kommentaren ersetzt und so. Also das reine "Rename" Refactoring ist extrem stark.
Daneben gibt es aber noch viele weitere Refactorings, die ich nutze. Man kann da sehr effektiv mit arbeiten. Es lohnt sich also, sich auf eine IDE zu spezialisieren um diese dann zu meistern. Da ist dann also auch nichts mehr mit Rechtsclick oder so. Bei IntelliJ sind also diverse Tastenkombinationen in "Fleisch und Blut" übergegangen. Renaming ist da einer
Ah, das habe ich noch vergessen. Da zeigt sich dann durchaus, was eine IDE so alles kann. Einfach mal eine Variable markieren, Rechtsklick, und dann schauen ob es da einen Menüpunkt "Refactoring" oder so ähnlich gibt und was der alles bereithält...
Zumindest bei Klassennamen habe ich das schon mehrfach eingesetzt. Bezeichner selber zu ändern ist ja bei dem Code, den ich bisher schreibe, noch sehr gut machbar. Im Zweifelsfall zeigt mir die IDE ja nach einer Änderung auch an, wo Fehler entstehen. Und Eclipse z.B. bietet ja auch viel an, was dann automatisch geändert wird.
Ich denke, ich habe einen ganz guten Wiedereinstieg gefunden. Aber immerhin habe ich ja keinen Fremdcode dabei.
) versuche ich gerade endlich mal wieder, mich in einen alten Code zurückzufinden. Trotz reichlicher Kommentare tue ich mich unglaublich schwer, da wieder reinzukommen und da weiter zu machen, wo ich aufgehört habe. Ich habe vllt. auch etwas viel auf einmal machen wollen und einige Baustellen gleichzeitig eröffnet... hat jemand ein paar Tipps, wie man sich wieder einen Überblick verschafft? (z.B. ja auch nötig, wenn man sich in Fremdcode einarbeiten muss)
