Krautkanal.com

Veröffentlicht am 2015-10-15 18:06:56 in /prog/

/prog/ 7936: Überblick und Konzentration

shadowfreakapps Avatar
shadowfreakapps:#7936

Hallo Bernd,

ich bringe mir seit etwa zwei Jahren autodidaktisch Java bei. Etwas wirklich großes habe ich dabei noch nicht auf die Beine gestellt, halt eher kleinere Standardprojekte wie ein simples Schiffeversenken und solche Dinge.

Nun arbeite ich seit etwa 3 Monaten täglich mit Java Testautomatisierung mit Selenium-Framework und habe immer noch große Probleme, den Überblick im (sauberen) Code zu behalten.
Wenn ich jemandem etwas zeigen möchte, brauche ich relativ lange, um die Stelle zu finden. Häufig vergesse ich bei vielen Klassen auch einfach, wo bestimmte Implementationen zu finden sind und was diese tun, obwohl ich sie mir schon mehrfach angesehen habe. Rufe ich in einer Klasse also beispielsweise eine Methode auf einem Objekt einer anderen Klasse auf, so muss ich immer in die Implementation springen, um mir nochmal anzusehen, was genau dort passiert. Dies gestaltet sich natürlich besonders aufwändig, wenn auch noch Parameter übergeben werden.
Darüber hinaus brauche ich auch relativ lange, um Code schlicht und ergreifend zu verstehen. Schleifen in Schleifen, mehrere Parameter etc. - das alles bereitet mir ziemliches Kopfzerbrechen.

Ist das für den Anfang normal und alles nur Übungssache, oder kann es sein, dass die Leistungsfähigkeit meines Gehirns für derartige Arbeit einfach nicht ausreicht? ;_;

ayalacw Avatar
ayalacw:#7937

>>7936

>Ist das für den Anfang normal und alles nur Übungssache, oder kann es sein, dass die Leistungsfähigkeit meines Gehirns für derartige Arbeit einfach nicht ausreicht? ;_;

Normal. Als ich das erste mal einen for-Loop gesehen habe, brauchte ich einige Zeit, um den wirklich zu verstehen. Heute verstehe ich auch komplexen Code oft schneller und besser als andere. Nach einem Jahr Berufserfahrung wird es dir sicher auch leichter fallen.

alexcican Avatar
alexcican:#7938

Wenn du dir zum Verstehen einer Schnittstelle die Implementierung anschauen musst, dann ist die Schnittstelle Mist.

meisso_jarno Avatar
meisso_jarno:#7952

Dieser Bernd hat ein ziemlich gutes Gedächtnis für die "physische" Position von Codestellen und steht regelmäßig bei seinen Kollegen am PC und navigiert sie: "Scroll mal etwas hoch, noch etwas, noch etwas, nein das war zu weit, nochmal ein bisschen runter... hier, siehst du"
Bernds Kollegen indes verwenden alle tolle IDEs und haben oft (vermutet er) nichtmal eine Ahnung von der Verzeichnisstruktur der Projekte, weil sie ja auf alle Methoden nur draufklicken müssen, um hinzuspringen. Schaden tut es ihnen allerdings nicht.

Insofern: Konzentrier dich einfach darauf, sauber zu arbeiten. Gerade Tests sollten ja, wenn sie gut sind, immer auch ein Verständnis für den Code eröffnen. Es liegt also an dir, wenn du eine Stelle verstanden hast, vlt. auch die Tests so zu gestalten, dass du, wenn du die Stelle nochmal bearbeiten musst, eher die Tests als den Code angucken kannst, um schnell drauf zu kommen, wie der Code nochmal funktioniert.

polarity Avatar
polarity:#7954

Vielleicht enthalten deine Methoden zuviele Zeilen Code.
Wenn du kompakte Methoden (die dann ggf. viele private Untermethoden aufrufen) hast, kannst du treffendere/genauere Methodennamen vergeben, die damit wiederum deinen Code besser dokumentieren.

suprb Avatar
suprb:#7956

>>7954
Dies, tausendmal. Wenn man seine Variablen halbwegs sauber benennt und komplexere Codeschnipsel in Methoden auslagert, dann ist der Code schon zu 90% dokumentiert. Ein //if field is empty, do something else Kommentar hilft keinem was, das steht nämlich direkt drunter.

Wenn du aber die doppelt geschachtelte Schleife mit 5 eingerückten ifs aus deiner eigentlich Methode rausziehst und da nur noch selectMatchingParts mit was weiß ich aufrufst, dann kannst du sehr einfach über die eigentliche Methode drüberlesen.

gojeanyn Avatar
gojeanyn:#7957

>>7936
Du hast noch nicht die notwendige objektorientierte Abstraktionsebene erreicht und denkst prozedural. Für dich scheinen Methoden Funktionen zu sein, das sind sie aber nicht. Wenn du anfängst in Schnittstellen und Vererbungen zu denken wird der Code nie "zu kompliziert" werden, weil du die miteinander interagierenden Objekte immer so verpackst dass du den besten Überblick behältst denn die Objektorientiertheit arbeitet genau am Rande deiner aktuellen kognitiven Kapazität.

stevenfabre Avatar
stevenfabre:#7958

>>7936
Geht es um eigenen Code oder um Code von anderen? Dieser Bernd programmiert seit >10 Jahren und würde sagen, dass er sehr gut darin ist, Code zu schreiben. Bernds Fähigkeit, fremden Code zu lesen, lässt hingegen zu wünschen übrig. Das liegt daran, dass Bernd immer nur alleine vor sich hin programmiert hat und daher diese Fähigkeit nie geübt hat. Es sind einfach zwei verschiedene Fähigkeiten, die man trainieren muss. Bernd hatte auch schon mit Leuten zu tun, die schlechteren Code schrieben als er, aber war beeindruckt davon, wie schnell sie seinen Code verstanden haben. Bernd hätte seinen Code wohl selber nicht so schnell verstanden, hätte jemand anders ihm ihn vorgesetzt. Das lag einfach daran, dass diese Leute es gewohnt waren, in Teams zu arbeiten.

Es wird ja oft gesagt "Programmieren lernt man durch Code schreiben und Code lesen". Da ist was dran. Bernd hat einfach das Lesen immer vernachlässigt.

Man wird aber wirklich besser mit der Übung. Bei Bernd geht es steil bergauf, seit er auf Linux umgestiegen ist. Denn es gibt ja bei jeder offenen Weichware irgendeine Kleinigkeit, die einen stört. Wenn man dann einfach mal versucht, diese selbst zu beheben, ist das eine sehr gute Übung. Unter Linux ist auch die Hemmschwelle dazu nicht so groß wie bei Fenster, weil das Kompilieren in der Regel auf Anhieb funktioniert.

marcusgorillius Avatar
marcusgorillius:#7960

>>7958
> Bernds Fähigkeit, fremden Code zu lesen, lässt hingegen zu wünschen übrig.
Was auch daran liegen kann, dass es mehr Kot als Code ist.

bighanddesign Avatar
bighanddesign:#7961

>>7960
Mag sein, trotzdem scheinen andere irgendwie besser damit klarzukommen.

Neuste Fäden in diesem Brett: