In ein Projekt einarbeiten
-
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.
-
Unsure schrieb:
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.
Hört sich an, als würdest du bei "Bugs jagen" an irgendwelche Krimis denken ^^ Kann schon sein, dass es ab und zu so läuft und man auch manchmal Kollegen fragen muss, was die sich schon wieder gedacht haben, ich würd das ganze aber eher neutral sehen. Bugfixing ist eigentlich auch nicht wirklich was für Praktikanten, würde ich sagen. Wenn man sich auskennt, kann man einfache Bugs in paar Minuten fixen. Wenn man sich nicht auskennt, ist es hauptsächlich Zeitverschwendung, weil man sich erst vielleicht tagelang zusammenreimen muss, was zig andere eh schon wissen. Auch Praktikanten kann man produktiver einsetzen. Und an schwierige Bugs werden die wahrscheinlich eh nicht rangelassen. Wir haben in unserem 3D Kernel auch Bugs, die wir seit Jahren kennen, aber die hat jetzt auch noch keiner fixen können, da würden wir sicher keine Praktikanten ranlassen. Der hätte danach auch nicht viel zu erzählen.
Ja, bei der ganzen Java Enterprise Entwicklung gibts viele Standards. Da hilft es schon sehr viel, wenn man die Standard Patterns und Vorgehensweisen kennt, dann kommt man in die meisten Projekte sehr schnell rein.
-
Mechanics schrieb:
Wir haben in unserem 3D Kernel auch Bugs, die wir seit Jahren kennen, aber die hat jetzt auch noch keiner fixen können
Wie kann man nur so dumm sein und sowas verraten in Anbetracht der Tatsache das hier einige Leute wissen wo du arbeitest.
-
Selbst wenn... JEDER 3D Kernel hat Bugs, auch Acis und Parasolid
Das dürfte jetzt für niemanden eine Offenbarung sein.
-
Naja, du hast vermutlich recht, ja.
Aber was ich so mit bekomme haben die Jungs trotz dem ständigen "Oh mein Gott was ist denn jetzt schon wieder los"-Getue irgendwie Spaß daran, kaputte Dinge und Probleme zu fixen.
Lustig ist, dass gerade die Leute, die wirklich breites Wissen über das ganze Projekt haben ständig von Kollegen heimgesucht werden und irgendwas gefragt werden.
Zu der ganzen Java Enterprise Web-Entwicklungs Sache gibt es ja tatsächlich jede Menge im Internet.
Aber ich komme mir immer so doof vor, wenn ich im Internet nen Tutorial über sonst was lese, während alle um mich rum arbeiten.
Aber im Endeffekt wäre das wohl bei meinem aktuellen Wissenstand das sinnvollste.
-
Unsure schrieb:
Aber ich komme mir immer so doof vor, wenn ich im Internet nen Tutorial über sonst was lese, während alle um mich rum arbeiten.
Aber im Endeffekt wäre das wohl bei meinem aktuellen Wissenstand das sinnvollste.Mach auf einem Bildschirm oder einer Bildschirmhaelfte das Tutorial, auf der anderen den Sourcecode auf. Dann sieht es so aus, als wuerdest du nur mal ein Detail nachschlagen.
-
Unsure schrieb:
Aber was ich so mit bekomme haben die Jungs trotz dem ständigen "Oh mein Gott was ist denn jetzt schon wieder los"-Getue irgendwie Spaß daran, kaputte Dinge und Probleme zu fixen.
Das macht ja auch Spass. Ich verbringe auch einen recht großen Teil meiner Zeit freiwillig mit dem untersuchen von Problemen. Nur würde ich das nicht unbedingt mit "Detektivarbeit" vergleichen. Mir macht es u.a. Spass, weil ich mich so in irgendwas neues einarbeiten kann, oder mir zumindest etwas interessantes anschauen, womit ich sonst nichts zu tun hätte.