In ein Projekt einarbeiten
-
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.
-
Das ist doch auch ein Vorteil, wenn es möglich ist, sich an neue Anforderungen anzupassen. Wenn du anfängst ein Auto zu bauen und mittendrin sagt dir jemand, wär cool, wenn das auch fliegen könnte, dann ist das nicht möglich. Bei der Softwareentwicklung schon. Wir fangen an, ein Feature für einen Kunden zu implementieren. Sind schon ganz gut dabei, dann reden wir mit einem anderen Kunden, und er könnte was ähnliches gebrauchen. Aber eben nicht genau das gleiche, deswegen kommen neue Anforderungen hinzu. Damit kann ich durchaus leben.
-
Mechanics schrieb:
Wenn du anfängst ein Auto zu bauen und mittendrin sagt dir jemand, wär cool, wenn das auch fliegen könnte, dann ist das nicht möglich. Bei der Softwareentwicklung schon.
ja, weil die Entwickler es mitmachen (müssen). Cool
-
Ich kenne das aus der Elektronik auch so, dass ich erst alle Unterlagen erstelle(Funktionsbeschreibung, Schaltplan, Verdrahtungsplan, Stückliste, Messprotokoll und je nach Aufgabe noch mehr) und erst dann fange ich an das zu bauen. Ich habe auch in der Softwareentwicklung gearbeitet und solch ein Durcheinander habe ich noch nie irgendwo erlebt. Als Facharbeiter würde ich sagen, dass es sich in 90% der Fälle "Pfusch am Bau" handelt.
Die Schuld trägt nicht der Entwickler, denn der bekommt einfach gar keine Zeit alles ordentlich zu machen. Bei größeren Firmen mag dies anders sein, aber die meisten programmieren nun einmal in kleinen bis mittleren Klitschen und Arbeitszeit ist nun einmal fast immer alles. Da bessert man dann lieber in Folgeaufträgen aus, als es gleich richtig zu machen. Dieses Ausbessern muss natürlich schnell geschehen und am Ende ist immer der Entwickler schuld.
Eine echt miese Branche.
-
Ein Problem ist aber auch, dass viele Firmen nicht bereit sind, fuer Software viel Geld auszugeben. Die denken, das geht schnell und billig, lassen sich das dann hinklatschen und denken, sie waeren fertig damit. Dass sie damit letztendlich viel mehr ausgeben, rechnet sich aber keiner von denen aus.
-
Arbeitet niemand von euch in einem funktionierenden, agilen Umfeld?
