In ein Projekt einarbeiten

Guten Abend,

ich bin durch Kontakte in ein längeres Praktikum bei einer größeren Firma gelandet.

Keiner erwartet dort sonderlich Meisterleistungen von mir, allerdings ist es Vollzeit und ich werde sogar bezahlt.
Ich weiß, dass ich selber schuld bin, dass ich in dieser etwas komischen Situation bin, weil ich eig. auch nur da bin, weil ich wie gesagt Kontakte habe.
Soll jetzt nicht falsch rüberkommen, ich hab mich da jetzt nicht reingezwungen oder sonstiges, aber sagen wir mal die Firma war nicht wirklich auf einen Praktikanten vorbereitet.

So, nun will ich auch was leisten und nicht jeden Tag 8 Stunden rumsitzen. Allerdings muss ich feststellen, dass es mir schwer fällt, mich einfach mal so in ein Projekt dieses Umfangs eizuarbeiten, nur anhand des Projekt-Codes.
Ist jetzt kein Giganten-Projekt, aber sagen wir mal etwa 15 Leute arbeiten da seit etwa 2 Jahren dran.

Ich will nicht wie der größte Dummkopf rüberkommen, daher frag ich mich, wonach ich fragen kann?
Ich erwarte nicht, dass jemand seine Zeit verschwendet sich 24/7 neben mich zu hocken, das ist ganz klar.
Aber ist es realistisch nach sowas wie Dokumentationen oder technisches Fachkonzept oder irgendwas zu fragen? Ist es üblich, dass sowas existiert?
Ich verstehe momentan echt Bahnhof (heute war allerdings auch erst der erste Tag). Hybris, SAP, tausend verschiedene Vernetzungen zwischen diesen beiden Systemen, Test und Live-Systeme, Versionskontrollen mit Branching, dies und das Tool zu QA, ... .

Musstet ihr Euch schonmal in grössere, bestehende Projekte einarbeiten? Wie lief das ab?

Ich will noch mal betonen, dass ich hier niemanden schlecht darstellen will. Ich würde einfach nur sehr gerne irgendwie produktiv werden und ich frage mich, wie ich das am besten anstelle ohne jedem auf die Nerven zu gehen.

Danke schon mal im Voraus

Hallo,

ich habe vor kurzem auch meine erste Werkstudentenarbeit begonnen und hatte ähnliche Probleme. Am Anfang ist man doch recht erschlagen von den Tools und Workflows. Was mir sehr geholfen hat: Ich habe innerhalb der ersten Woche um einen Walkthrough durch die Codebase (weniger Leute als bei dir, aber etwa drei Jahre) gebeten. Dabei ergibt sich auch die Gelegenheit alles mögliche, auch was nicht direkt mit dem Code zu tun hat, zu fragen, weil sich jemand konkret für einen Zeit nimmt. Da mich ein Backend-Entwickler betreut hat, ging es erstmals vorwiegend um das Backend. Meine erste Aufgabe war dann (un)passenderweise ein Feature im Frontend. Ich habe dann einfach um einen weiteren Walkthrough, dieses mal mit Fokus auf das Frontend, gebeten.
Insgesamt waren das jeweils etwa drei Stunden mit zwei verschiedenen Entwicklern. Nach dieser Einführung hatte ich ein gutes Grundverständnis und konnte mir alles weitere über die Monate erarbeiten. Interessant war auch, dass andere Mitarbeiter sagten, sie hätten sich zu Beginn auch so eine Einführung gewünscht. Manche haben auch gleich die Chance genutzt ein wenig zuzuhören und ihr Wissen über manche Ecken aufzufrischen

Inzwischen kenne ich mich in der Codebase recht gut aus und kann sowohl Back- als auch Frontend Aufgaben prima erledigen.

Viele Grüße

Marthog

Ich habe mich noch nie in ein Projekt vollstaendig eingearbeitet, aber schonmal ein bisschen im Quellcode von Firefox, Linux undClang gelesen und das ist echt heftig, weil man tausend verschiedenen Kram hat und vom meisten einfach keine Ahnung.
Am besten ist es wohl, wenn man erstmal versucht, ein Teilgebiet ueberhaupt nahzuvollziehen.
In die Grundlagen zu Versionskontrollsystemen kann man sich gut an einem Tag einarbeiten.
Ansonsten solltest du mal fragen, was es fuer Dokumentationen gibt, aber erwarte nicht so viel, denn oft machen Firmen gar keine und manchmal muss man damit rechnen, dass man ziemlich komplexe Dokumente bekommt.

@Anfängerz Klingt gut Ich werd wohl schauen, ob ich ähnliches irgendwie hinkriege.
Fühle mich bisl doof, weil ich es alleine zumindestens in der letzen Stunde des heutigen Tages so gar nicht hinbekommen habe.
Hab wild bisl durch die mehreren hundert files des Projekts geklickt, um irgendwo einen Anfangspunkt zu finden, bin aber nicht wirklich fündig geworden.

Man kommt sich einfach wie der größte Trottel vor, wenn man von ner IDE hockt und nur doof im Code rumklickt, haha.

@Marthog Ja, das hab ich versucht, allerdings hat sich bis jetzt kein Teilgebeit eingrenzen lassen.
Dass das Projekt auf der Hybris-Plattform basiert kommt echt noch erschwerend dazu. Viele Files sind auto-generated oder von der Hybris-Plattform selber.
Jede Files hat gefühlte 20 Imports aus Hybris, etc.
Allerdings sollte die Firma als Hybris-Partner Zugang zu den entsprechenden Dokus haben, die werde ich mir auf jeden Fall mal reinziehen!

Ich werd morgen mal nach einer Doku irgendeiner Art fragen, hoffentlich gibts da irgendwas hilfreiches.

hustbaer

Unsure schrieb:

Aber ist es realistisch nach sowas wie Dokumentationen oder technisches Fachkonzept oder irgendwas zu fragen? Ist es üblich, dass sowas existiert?

Ganz unterschiedlich, manche Firmen haben gar nix, andere extrem viel. Frag einfach vorsichtig - also nicht nach dem Motto "muss es geben, wer keine Doku hat ist doof" sondern ganz normal ala "habt ihr da was, und wenn ja, wo?".

Unsure schrieb:

Musstet ihr Euch schonmal in grössere, bestehende Projekte einarbeiten?

Ja.

Unsure schrieb:

Wie lief das ab?

Stück für Stück.
Ich war dabei aber nicht als Praktikant angestellt, sondern "permanent". Daher bin ich, wenn ich 'was nicht wusste, einfach fragen gegangen. Bzw. hab mich selbst durch-debuggt.
War in meinem Fall relativ einfach möglich, da ich das System vollständig auf meinem Dev-PC laufen lassen konnte, und es auch nicht auf externe Teile ala SAP zugegriffen hat.

----

Nach einer Einführung zu fragen wie Anfängerz vorgeschlagen hat, finde ich schonmal gut. Ansonsten einfach fragen wie du tun sollst damit du dich selbst reinfindest. Also z.B. ob und wie du da im Falle des Falles reindebuggen kannst.

Und wenn es für dich OK ist dich Stück für Stück reinzuarbeiten, dann würde ich Scheuklappen empfehlen. Also nur die Teile genauer angucken/reindebuggen die nötig sind um den Teil zu verstehen an dem du gerade 'was machen sollst. Sonst siehst du viel zu viele Dinge auf einmal und letztenendes bleibt nix hängen. (EDIT: Manchmal kann es natürlich auch nötig sein etwas breiter zu gucken/suchen. Also z.B. dass man, wenn man Komponente X braucht, gucken muss, wo und wie Komponente X überall verwendet wird. Um zu verstehen was das Ding macht/wozu es gut ist/was man gefahrlos damit machen kann und was nicht etc. Das merkt man aber dann, und dann macht mans halt. Wichtig ist nur nicht gleich "breit" anzufangen, weil es sonst halt einfach viel zu schnell viel zu viel wird.)

Das ganze Projekt lokal auf dem PC ausgecheckt zu haben und dann mit Find-In-Files draufzuhauen funktioniert oft auch sehr gut wenn man bestimmte Stellen sucht. (Also z.B. wenn du nen Klassen- oder Funktionsnamen hast, und dann Stellen suchst die damit 'was machen. Oder wenn du wissen willst wie eine bestimmte Klasse oder Funktion verwendet wird - einfach Beispiele suchen. Etc.)

ps: Neben Find-In-Files sind auch "go to definition" und "find references" extrem wichtige Werkzeuge dafür. Und falls z.B. sowas wie ne Doxygen Doku existiert, kannst du die auch mal bauen und reingucken - inklusive aller möglicher Graphen (Vererbung, Aufrufhierarchie, ...).

Mechanics

Unsure schrieb:

Musstet ihr Euch schonmal in grössere, bestehende Projekte einarbeiten? Wie lief das ab?

Klar. An unserer Software arbeiten 30 Entwickler seit 20 Jahren (gut, waren am Anfang weniger). Hab mindestens ein halbes Jahr gebraucht, um halbwegs reinzukommen. Also, bis ich "das meiste" kannte und überall mitreden konnte. Kenne jetzt auch nach Jahren nicht alles im Detail und würde auch nicht alles im Detail verstehen, in einigen Bereichen würden meine Mathekenntnisse auch nicht ausreichen, in andere müsste ich mich sehr intensiv einarbeiten.
Konnte aber schon in der ersten Woche recht produktiv mitarbeiten. Bei mir läuft es meist übers Debuggen, so komm ich am schnellsten rein. Hab auch gleich konkrete Projekte bekommen und mir wurde auch gezeigt, wo ich da ansetzen kann. Habe dann den Kollegen konkretere Fragen gestellt, wenn ich nicht weitergekommen bin.
Ich untersuche auch öfter irgendwelche 3rd party Bibliotheken, von denen ich an sich auch keine Ahnung habe. Vor allem Qt hab ich schon zig tausend mal durchdebuggt, mittlerweile kenn ich das aber auch sehr gut und wir haben das auch schon halb umgebaut. Gibt aber auch Bibliotheken, die wir eher als Blackbox betrachten und da kaum mal reinschauen, aber wenn mal was nicht funktioniert, dann muss man sich das halt auch mal antun.

Unsure schrieb:

Ist es üblich, dass sowas existiert?

Bei uns nicht. Und da eure Firma oder zumindest das Entwicklerteam anscheinend noch kleiner ist, vermute ich, dass ihr sowas auch nicht habt. Sowas würde ich eher in wirklich großen Firmen erwarten. Teilweise haben wir irgendwelche uralten Klassen mit 20-30 000 Zeilen Code pro Klasse, mit denen sich höchstens 1-2 Leute wirklich auskennen. Die sind dann vollgespickt mit irgendwelchen Abkürzungen und Begriffen, mit denen niemand was anfangen kann. Das sind dann irgendwelche Fachbegriffe aus irgendwelchen VDA Normen aus den 90ern oder 80ern und entspricht eigentlich nicht der Denkweise der Entwickler. Da komm ich immer noch öfter durcheinander. Ich habe recht konkrete Vorstellungen von dem, was ich will, ich kann damit technisch was anfangen. Für die entsprechenden Klassen muss man das aber irgendwie ganz anders formulieren. Und da niemand außer dem ursprünglichen Entwickler weiß, für was diese Abkürzungen eigentlich stehen, ist es auch nicht einfach, sie sich zu merken und auseinanderzuhalten. Traut sich aber auch niemand, sowas umzubauen. So viel zum Thema Doku.

Kenne ich auch. Ich hatte Situationen, wo ich am Anfang überhaupt nicht wusste, wie ich anfangen soll.
Wichtig ist, sich ein Konzept zu erarbeiten und auch professionelles Debbuging zu erlernen, um zu gucken, wie was funktioniert.
Wenn du z. B. eine neue Funktion einbaust, baue genau an den neuen Stellen oder vll. auch vorher, Breakpoints ein und gucke, wie sich das verhält. Führe nicht einfach dein Programm aus und gucke, was es tut, sondern baue bei neuen Stellen immer gleich Breakpoints ein und steppe das durch. Habe ich von meinem alten Chef gelernt. - Er war ein Arschloch.

Tyrdal

Einfach eine Aufgabe suchen! Wenn man ein Problem lösen muss hat man auch eine Stelle an der man anfangen kann.

Danke erstmal an alle für den Input

@hustbaer Wie lange hat das dann gedauert, bis du dann einen guten Überblick über das Projekt hattest?

Generell, um mal die Vorschläge hier zu kommentieren und auch als Update meiner Situation:

Ich muss sagen ich komme ehrlich gesagt zur Zeit nur sehr schwer voran.
Ich stell mich sicherlich auch doof an, aber es gibt halt einfach ein paar Faktoren, die es einem auch nicht einfach machen:

Das ganze Projekt ist ein Webshop. D.h ich kann das Projekt nicht einfach auf dem Rechner ausführen, um zu schauen, was es tut. Schließlich läuft das Ganze eig. auf einem Server.
Des weiteren kompiliert das Programm in dem aktuellen Stand auch überhaupt nicht. Muss noch mal jemanden fragen, ob das überhaupt so sein sollte.

Die größte Problematik, die ich habe das Projekt zu verstehen, ist diese unglaubliche Klassen-Verworrenheit.
Das Programm ist hauptsächlich in Java, daher gezwungene OOP.
Konkret bedeutet das, dass ich mir zB 60 Zeilen Code anschauen will, um zu verstehen, was getan wird, und in diesen 60 Zeilen etwa 20-30 unbekannte Klassen verwendet werden.
Fange ich dann bei der ersten Klasse an, indem ich Goto->Deklaration mache, lande ich in einem Art rekursiven Prozess, denn diese Klasse hat meistens wieder etliche unbekannte Klassen in Verwendung. Spätestens wenn man 15 Tabs mit verschiedenen Klassen aufhat hat man den Durchblick wieder verloren.

Die Sache ist auch ... das Ziel auf das ich hinarbeite, ist am Ende in der Lage zu sein, Bugtickets anzuschauen, erahnen zu können wo das Problem liegt und eine Lösung vorzuschlagen.
Das heißt ich kann mich nicht auf ein Teilgebiet des Programmes konzentrieren, sondern müsste im Prinzip einen Überblick über die ganze Funktionalität haben, aber auch nicht im Grobem, sondern auch im Feinen, da Bugs nunmal Bugs sind und selten auf der Hand liegen.

Ich bekomme demnächst Zugang zu der Hybris Wiki. Diese ... Plattform? ist mir eh noch ein riesen Mysterium. Ich kann mir momentan gar nicht vorstellen, wie dies funktioniert.
Im Code zu sehen ist, dass es definitiv als SDK fungiert, etliche Klassen erben von vorgegeben Hybris-Klasse, etliche machen auch gar nichts anderes als das, etc.
Allerdings nehm ich an, dass Hybris auch als Art Software auf dem Server läuft, etc.
Desweiteren kommen Dinge wie SAP, PIMs, Hybris als DB selbst, Fredhopper, und weitere Schnittstellen dazu.
Dann weiß ich garnicht, wie das Frontend des Shops funktioniert, soweit ich gesehen habe ist das in CSS umgesetzt. Und irgendwie wird ja aucch Frontend mit Backend kommunizieren wollen, etc.

Ich denke ich werde am Ende nicht drumrum kommen jemandem Zeit zu rauben und ihn neben mich setzen zu lassen, damit er mir überhaupt mal grob erklärt, welcher Teil der Software was macht, etc.

Aber ich hab das mulmige Gefühl, dass ich dort nicht weiter kommen werde. Fast jede kleine Funktionalität, zB automatisierter Email Versand, etc. ist mit viel Bedacht umgesetzt, zB gibt es immer abstrakte Überklassen und dann 5-6, die davon erbeben, immer eigends definierte Exceptions, sehr verworrenes Zusammenspiel von etlichen Klassen, etc.
Im Endeffekt hat sich jemand länger Gedanken gemacht, um ein gewisses Ziel umzusetzen, das für mich bis auf sehr grobe Vorstellen nicht mal nachvollziehbar ist.

Naja, das schlimmste was passieren kann, ist dass mich wer dumm anmacht warum ich nichts produktives tue und mir vorwirft, dass das eig. alles zu erarbeiten sei.
Was solls, die Vorraussetzungen sind schon iwie blöd. Will damit wie anfangs schon gesagt aber auf garkeinem Fall jemandem einen Vorwurf machen!

Antoras

Ein Praktikum ist nicht dazu da produktiv zu sein - es ist dazu da um zu lernen. Wenn das bei deiner Firma anders ist, dann ist das schlecht. Aber wenn dir noch niemand gesagt hat was du alles lernen sollst bzw. was du alles fertig bekommen sollst, dann solltest du möglichst sofort gucken, dass das nachgeholt wird.

Keine Ahnung wie deine Situation ist und wie voll der Terminplan deiner Kollegen ist, aber die meisten Entwickler helfen gerne dabei Fragen zu beantworten. Zur Not über die interne Mailingliste nachfragen (wird es wohl geben?), dann können sich deine Kollegen das Beantworten deiner Fragen auf einen Termin legen, der ihnen passt.

Ich habe zu Beginn meines Studiums angefangen mich in ein großes OpenSource Projekt einzuarbeiten (besteht aus mehreren Millionen Zeilen Code), da habe ich im ersten halben Jahr gefühlt auch nicht mehr erreicht als gerade einmal grob eine Übersicht über das Projekt zu bekommen. Hatte zwar keinen Leistungsdruck, aber den solltest du wie gesagt bei einem Praktikum auch nicht haben.

Wenn du in einem Semester lernst wie du so ein großes Projekt baust, wie du mit der TestSuite umgehst, wie du die Versionsverwaltung, den Bugtracker und die Dokumentationstools benutzt, wie du genug Übersicht über das Projekt erlangst um die Stellen zu finden wo Bugs zu fixen/neue Features zu implementieren sind und wie du vernünftig mit deinem Team/deinen Kollegen kommunizierst dann würde ich sagen war das Praktikum erfolgreich. Zumindest aus deiner Sicht. Ein Arbeitgeber in der IT-Brache sollte wissen, dass Praktikanten nicht dazu eingestellt werden um irgendjemandem Arbeit abzunehmen. Und wenn du nach deinem Praktikum weiterhin für deinen Arbeitgeber arbeiten möchtest, dann war das Praktikum auch für deinen Arbeitgeber erfolgreich.

Puhh.. sowas is immer schwierig, und die Motivation ist anfangs immer mies.. bis man bisschen Anschluss gefunden hat! Kenn ich!

Als ich mich um Stellen beworben habe, und ich bei denen als Entwickler in bereits großen bestehenden Projekten hätte mit arbeiten müssen, hab ich das schon für mich gechancelt.. sowas mag ich gar nich:( Vorallem langweile Business Anwendungen.. die vollgepackt sind mit 3rd Party Komponenten und man selbst weniger "selber" mehr macht.. aber das is auch ein anderes Thema:)
Naja manchmal gehts haut auch nich anders....

Toi toi toi.. sowas mag niemand:)

Ich braucht auch immer gut ein halbes Jahr um mich in ein Projekt einzuarbeiten und dann auch wirklich produktiv mitarbeiten zu können. Je nach Doku fällt dies dann leichter oder schwerer. Eine lupenreine Dokumentation die auch aktuell ist, habe ich in 15 Jahren als Entwickler nie gesehen. Zudem war es immer Code wo mehrerer Programmierer ihren Teil zum Produkt beigetragen hatte und das merkt man auch bei Code lesen. Je mehr OOP drin war, desto weniger ist das ganze auch menschenlesbar, da geht dann ohne Doku meist nicht viel, oder nur sehr mühsam.

Praktikanten empfand ich immer als Klotz am Beim. Die haben mir immer mehr Arbeit gemacht als sie von Nutzen waren. Sorry, ich bin nur ehrlich.

Wie dem auch sei, mach dich nicht verrückt, dass du da nicht groß helfen kannst. Das ist völlig normal als Praktikant. Ich habe auch mal so angefangen, war dann recht passable und habe nach 15 Jahre dann den Job komplett an den Nagel gehängt und mache jetzt was total entspanntes ohne jeglichen Druck und mit viel Anerkennung.

hustbaer

NullBockException schrieb:

Toi toi toi.. sowas mag niemand:)

Würd' ich nichtmal sagen. Ich persönlich find's anstrengend, weil ich immer das Gefühl habe dass das alles viel zu viel ist als dass man es überblicken könnte. Wobei mir auch die gegenteilige Erfahrung die ich mehrfach gemacht habe nicht sehr hilft. Ich kenne aber Leute die das "spannend" finden.

Ich finde Einarbeiten in fremde Sourcen ist eine Qual, wenn das Projekt schlecht aufgesetzt ist. D.h.

- Für jede Änderung muss ich ne Megatoolkette durchlaufen
- Einfaches Testen kleinerer änderungen ist so nicht möglich
- Selbst die einfachste Funktionalität ist super duper OOP gekapselt, endet dann in Blüten wie

namespace1::namespace2::namespace3::MyObjectCaller->getHandler(namespace1::DeviceSetupSystem::globalFunctionEnabler()->IsAvailable())->callData();

BOAR ALTER ICH HASSE DAS SO Das dauert Ewigkeiten bis man den Scheiss durchblickt.

Noch schlimmer ist die Steigerung der Schwierigkeit durch "intuitive Abkürzungen"

ns1::ns2::ns3::MyObjC->getHandler(ns1::DevSetupS::gFuncEnabler()->avail())->call();

ZumKotzen schrieb:

- Selbst die einfachste Funktionalität ist super duper OOP gekapselt, endet dann in Blüten wie

namespace1::namespace2::namespace3::MyObjectCaller->getHandler(namespace1::DeviceSetupSystem::globalFunctionEnabler()->IsAvailable())->callData();

Nichts, gegen OO. Was du beschreibst, ist ein Code-Smell!

http://de.wikipedia.org/wiki/Gesetz_von_Demeter

das Kapseln und Wrappen von alles und jedem ist nicht immer Jux und Trollerei, sondern kann zwangsläufige Folge von Ungewißheit beim Entwickeln sein.

wenn dem Entwickler keine fertige Spezifikation vorliegt, sondern inkrementell vorgegangen wird und Funktionalität nach und nach aufgebaut wird, fischt der Entwickler im Trüben darüber, was verallgemeinerbar implementiert soll und daher gekapselt werden muß und was nicht.

um sich zu ersparen, irgendwann die 300 Quelltext-Dateien an 250 Millionen Tausend und 37 Stellen ändern zu müssen, weil er aus Unwissenheit über Anforderungen, die er zu dem Zeitpunkt noch gar nicht kennt, eine bestimmte Sache zu früh festverdrahtet hat, neigt man dann dazu, lieber zu viel zu kapseln als zu wenig.

das ist der große Vorteil einer fertigen Spezifikation - da kann man von Anfang an abstrahieren und nur das wirklich Nötige kapseln. Der große Nachteil ist, daß es gar nicht so leicht ist, sicherzustellen, daß die Spezifikation widerspruchsfrei ist. Und wenn sich nach 2 Jahren x 10 Mann Implementationsarbeit ein grundlegender Widerspruch in der Spezifikation ans Tageslicht arbeitet, dann kann die Karre wirklich am dampfen sein.

Ethon

Es ist vollkommen normal keine Spezifikation zu haben da sich Anforderungen ständig ändern.

leider. Man stelle sich mal einen Architekten oder Bauleiter vor, der während des Baus ständig geänderte Baupläne bekäme und vorher nicht wüßte, wie hoch und breit das Gebäude mal werden soll. Das würden viele vermutlich entweder gar nicht oder nur gegen horrende Bezahlung mitmachen. Aber in der Softwareentwicklung hält man das vielerorts für normal und die Entwickler machen es nolens volens mit.

Ethon

Das liegt in der Natur der Sache und deswegen entwickelt man auch agil.
Mit einem guten Scrum ist das absolut kein Problem.