Ich stehe noch am Anfang meiner beruflichen Karriere als Informatiker und begegne nun schon zum zweiten mal einem grundlegenden Problem:
Wenn man in ein laufendes Projekt einsteigt, muss man in möglichst kurzer Zeit den vorhandenen Quellcode und dessen Semantik verstehen.

Meine Frage ist nun, wie Ihr diesen Problemen begegnet?

Zusätzlich muss ich noch anmerken das ich bisher nur mit C/C++ Code Probleme hatte. Java-Code(ohne Templates) ist meist übersichtlich genug um auch bei grösseren Projekten mit Papier und Bleistift bewaffnet an ihn heranzugehen.

Grüße, MainBrain

...
Zusätzlich muss ich noch anmerken das ich bisher nur mit C/C++ Code Probleme hatte. Java-Code(ohne Templates) ist meist übersichtlich genug ...

"Ich liebe den Geruch von Napalm am Morgen ....."

Gruß,

Simon2.

vorhandene Klassendokumentationen lesen (meistens mußt du gar nicht wissen, WIE die vorhandenen Klassen arbeiten - du mußt nur wissen, was für Klassen es gibt und wie du sie verwenden kannst)
alteingesessene Programmierer fragen (die kennen das System und können dir helfen, dich einzulesen)
wenn's geht, ein paar Testprogramme schreiben, um dich mit dem System vertraut zu machen
...

Das klingt vernünftig aber in den Bereichen, in denen ich tätig binn geht das leider nicht so gut. In der Forschung sieht es so aus das, oft viele Experten, die meist nicht Informatiker, sondern Maschinenbauer, Elektrotechniker, Mathematiker etc. sind, an einem Projekt arbeiten. Diese Leute können gerade so viel Programmieren wie unbedingt nötig um ihr Teilproblem zu lösen.

Die Quelldateien mit denen ich in so einem Umfeld zu tun hatte, haben folgende Eigenschaften:

• schlecht Programmiert: Da sind keine professionellen Programmierer am Werk.
• schlecht Dokumentiert: Entweder fehlende, veraltete oder gar fehlerhafte Doku
• viel Expertenwissen: Ich kann mir nur Grundlagenwissen zu den jeweiligen Fachgebieten aneignen. Es gibt viele Funktionen die ich nicht verstehe.
• viele Abkürzungen: Ich bekomme es mit duzenden von Abkürzungen zu tun.
• schwierige Kommunikation: Manchmal ist es nicht möglich mit dem Urheber eines Programmteils zu kommunizieren. Man muss dann versuchen jemanden zu finden der sich damit auskennt.

Selbstverständlich lässt sich alles mit Kommunikation klären, aber das ist meist mit viel Rennerei verbunden und ist nicht immer möglich. Auch wenn man Jemanden findet, dann wird meist unter Zeitdruck erklärt. Sogar das Erklärte ist auch nicht unbedingt einfach zu verstehen, denn in der Forschung hat man es manchmal mit Leuten zu tun die...
Es ist vorteilhaft wenn man versucht möglichst viel selbständig zu arbeiten.

Ich binn für jeden Tipp der mir die Arbeit erleichtern könnte dankbar.

Grüße,
MainBrain

Ps:
Meine Aussage über C++/Java war nicht offensiv gemeint. C++ bietet nunmal mehr möglichkeiten. Und wenn jemand mit geringen Programmierkentnissen oder zu hohen Ambitionen damit arbeitet kann eher unleserlicher Code entstehen.

Edit:
Kleiner typo korregiert. Danke CStoll

Das klingt vernünftig aber in den Bereichen, in denen ich tätig binn geht das leider nicht so gut. In der Forschung sieht es so aus das, oft viele Experten, die meist nicht Informatiker, sondern Maschinenbauer, Elektrotechniker, Mathematiker etc. sind, an einem Projekt arbeiten. Diese Leute können gerade so viel Programmieren wie unbedingt nötig um ihr Teilproblem zu lösen.

Dann solltest du mit dem Teil beginnen, den du gerade brauchst und dich Stück für Stück durcharbeiten.

schlecht Programmiert: Da sind keine professionellen Programmierer am Werk.

Autsch

[*] schlecht Dokumentiert: Entweder fehlende, veraltete oder gar fehlende Doku

Was denn nun? fehlende Doku oder fehlende Doku?

[*] viel Expertenwissen: Ich kann mir nur Grundlagenwissen zu den jeweiligen Fachgebieten aneignen. Es gibt viele Funktionen die ich nicht verstehe.

Wichtig ist erstmal, daß du die Aufgabe einer Funktion verstehst. Was sie genau macht, kannst du später noch ergründen.

Meine Aussage über C++/Java war nicht offensiv gemeint. C++ bietet nunmal mehr möglichkeiten. Und wenn jemand mit geringen Programmierkentnissen oder zu hohen Ambitionen damit arbeitet kann eher unleserlicher Code entstehen.

Wer keine Ahnung hat, was er da eigentlich tut, kann mit Java genausoviel Unsinn fabrizieren

Doku gibt es zu dem Java-Client garnicht (auch keine Sourcecomments). Ich habe mir vom ehem. Kollegen die wichtigsten Dinge dazu erzählen lassen. Habe mir Notizen gemacht und in seiner Nochanwensenheit ein oder zwei kleine neue Features eingebaut, um ihn nochmal fragen zu können.

So, vieles was er mir erzählt hatte, war so viel, das ich die hälfte schon wieder vergessen habe. Aber egal, keiner reisst mir hier den Kopf deswegen ab, wenn ich doch mal wieder zu den alteingesessenen Kollegen gehe, und frage was denn noch mal Dies und Das war? Ansonst schlage ich mich halt einfach durch den Soucecode durch, wenn ein neuer Bug entdeckt wurde oder ein neues Feature eingebaut werden soll.

Irgendwann kommt der Zeitpunkt, wo ich dann der King über das Ding bin, weil ich endlich jede Ecke und Kante kenne. Und natürlich habe ich schon diverse Sachen, die mir im Source nicht gefallen, umgebaut. Weil mein Vorgänger anders getickt hat als ich. Ist ja jetzt mein Projekt! har har har!