In ein Projekt einarbeiten
-
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.
-
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, ...).
-
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.
-
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!
-
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.
-
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 wienamespace1::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!
-
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.
-
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.
-
Das liegt in der Natur der Sache und deswegen entwickelt man auch agil.
Mit einem guten Scrum ist das absolut kein Problem.
-
großbuchstaben schrieb:
wenn dem Entwickler keine fertige Spezifikation vorliegt
Sowas kannst du eigentlich vergessen. Gibts nur bei klar abgegrenzenten winzigen Auftragsprojekten. Sowas würde ich aber auch nicht (mehr) entwickeln wollen. Bei allen anderen Projekten können sich die Anforderungen ständig ganz massiv ändern, das ist ganz normal.
Unsure schrieb:
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.
Normalerweise schon. Sowas wird normalerweise trotzdem lokal in einer entsprechenden Umgebung ausgeführt. Musst halt deine Kollegen fragen, wie die das machen.
Und normalerweise erwartet man von Praktikanten schon, dass sie produktiv arbeiten. Die können sogar oft ziemlich produktiv neue Sachen entwickeln. Was dann am Ende daraus wird und wie man das integriert (und ob man das integriert) ist eine andere Frage. Aber oft haben Firmen schon viele Ideen, die sie gern mal ausprobieren würden, wobei es aber zu teuer und zu riskant wäre, einen erfahrenen Entwickler darauf anzusetzen. Deswegen dürfen das oft Praktikanten machen. Sind aber oft sehr interessante Projekte. Auch wenn das am Ende nicht integriert wird, gewinnt man am Ende oft interessante Erkenntnisse. Deswegen werden Praktikanten oft auch entsprechend betreut. Also trau dich ruhig, deine Kollegen anzusprechen.
-
Mechanics schrieb:
großbuchstaben schrieb:
wenn dem Entwickler keine fertige Spezifikation vorliegt
Bei allen anderen Projekten können sich die Anforderungen ständig ganz massiv ändern, das ist ganz normal.
das ist normal, weil es für normal gehalten wird. In anderen Branchen ist es normal, daß erst eine Spezifikation hergestellt wird, und dann angefangen wird. Der Implementierer hat dann mehr Verläßlichkeit und Planbarkeit.
