In ein Projekt einarbeiten
-
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?
-
Ethon schrieb:
Arbeitet niemand von euch in einem funktionierenden, agilen Umfeld?
Haha, guter Witz.Software ist so "schwierig", weil ein Programm gleichzeitig der Plan und das fertige Erzeugnis ist. Programmcode ist die Spezifikation. Das verwirrt die Leute und die halten Softwareentwicklung dann für Magie, die nur mit ganz viel Hoffnung und langen Verzögerungen mal zu einem akzeptablen Ergebnis führt. Schwammige Anforderungen führen zu inakzeptablen Ergebnissen. Inakzeptable Ergebnisse fördern das Vorurteil, dass Softwareentwicklung zwangsläufig chaotisch verläuft. Die Annahme, dass die Entwicklung chaotisch verläuft, führt zu schwammigeren Anforderungen.
Eine systematische Herangehensweise würde vielleicht helfen. Sorry, aber "Software Engineering" ist gescheitert und "Agile" ist nur ein Buzzword, um Schulungen zu verkaufen.
-
Also die arbeiten da bei uns mit Jira und ja, Scrum Bords wo jede 2 Wochen Sprints 2 Wochen lange Sprints mit den entsprechenden Tickets eingeplanet werden.
Gibt halt sozusagen die Business-Seite des Shops, mit Anforderungsmanagement, die dann das ganze an die entwickelnde Seite weiter gibt, wo auch wieder ein Anforderungsmanger sitzt und entscheidet, ob der Vorschlag überhaupt umgesetzt werden soll, etc.
Dann gibts immer die Entscheidung zw Bug oder Weiterentwicklung, Release-Termine, Hotfixes, bla bla.Ist schon eig. alles ziemlich solide und kommunikativ aufgebaut dort, freut mich auch da ich da eine Menge mitnehmen kann. Ist auch alles sehr persönlich kommuniziert, die laufen halt dann eifnach die 10 Meter zum Arbeitsplatz vom Kollegen und besprechen eins der Themen, die halt so anstehen.
Dann wird das Besprochene meistens ins Ticket kommuniziert, damit der Rest auch weiß was abgeht und ansonsten wird halt enorm viel telefoniert.Ich würd in dem Projekt echt gerne produktiv werden, weil es mir denke ich sehr viel Spaß bereiten würde, irgendwelche Bugs auf der Spur zu sein, dies das zu evaluieren und auszugrenzen, dann man den und jenen dazu befragen, etc.
So wie es gerade halt ist, ist es allerdings sehr ... bedrückend. Man sitzt vor dem Projekt, hilft niemandem bei irgendwas und versucht sein bestes, auch nur ein Bruchteil des Wissens zu erlangen, das jeder andere um einen rum schon hat.
Da ich mit Webdevelopment leider nichts am Hut habe ist mir auch die komplette Struktur eines EJB (Enterprise JavaBean ) Webprojektes gar nicht vertraut.
Es scheint aber als würde das ganze einem relativ bekannten ... Design-Muster folgen, das man so für Enterprise Java-Websiten benutzt.Würde mir dazu echt gerne ein Buch kaufen, um einfach mal wesentlich besser die Grundstruktur zu verstehen.
Bin allerdings noch am suchen, was sich da als Lektüre eignet.
