Professionelle Softwareentwicklung
-
OK, danke für eure Antworten. Waren auf jeden Fall interessant zu lesen.
Wirklich wissen tu ich jetzt aber immer noch nicht, wie ich mich in der Hinsicht verbessern kann!
Einfach nur indem ich möglichst viel Praxis sammle?Mal ein paar Worte wie es derzeit in der Arbeit läuft: Ich bekomme in der Arbeit meine Aufgaben zugewiesen, also quasi Teilprojekte, die ich dann ausprogrammiere. Ich schreibe auf einem Zettel brav mit was der Chef so will, erstelle dann das Grundgerüst der Programmlogik / Klassen / Zusammenhänge auf dem Zettel, und mach mich dann an die Programmierung meiner Ideen. Ein paar Tage später kommt der Chef her und meint, dies und jenes hat er sich anders vorgestellt. Laut meiner Mitschrift ist dem aber nicht so, aber was solls, ich programmiers halt um. Nach 2 Wochen Programmierarbeit kann es dann schon mal vorkommen, dass auf einmal *alles* anders sein soll, oder dass er in einer Nacht und Nebel Aktion an den Sourcecodes seiner Mitarbeiter Dinge ändert, die seiner Meinung nach so nicht stimmen. Natürlich funktioniert das dann alles nicht mehr so wie gedacht, denn meist denkt sich ein Mitarbeiter ja was dabei wenn er gewisse Dinge einprogrammiert (a la "viele Köche verderben der Brei").
Durch die gesammte Herumwurschtelei ist der Source Code am Ende echt zum Kotzen(v.a. weil der Chef in seinen Nacht und Nebelaktionen auch mal gern so tolle Dinge wie goto einbaut, oder Variabelen wie s1, s2, s3 erstellt, wo keine Sau weiß für was die gut sind), und ich denke mir jedes Mal "oh mein Gott was ist da wieder passiert". Wiederverwendbarkeit=Null, Übersichtlichkeit=Null, usw..., aber ich weiß echt nicht wie ich das ändern soll. Bei privaten Projekten oder Uniprojekten sind meine Programme sehr ordentlich erstellt und zur Freude der Profs ist der Sourcecode quasi selbsterklärend. In der Arbeit ist das nicht so, ganz einfach weil alle paar Tage so massive Änderungen gemacht werden müssen, das zum Schluss nur Müll rauskommen kann.
-
Also, dass sich die Spec. ändert, ist normale Härte.
Das es teilweise keine/kaum Spec. gibt ebenso.Das andere in dem eigenen Code rumwursten ist auch normal.
Allerdings sollten die nicht darin rumpfuschen wie du sagst (s1, s2,s3 Variablenbenennung und goto ist ein absolutes no-go).Bei sowas würden Code-Conventions und Code-Reviews z.B. etwas helfen.
Falls es diese aber noch nicht bei euch gibt wirds schwierig diese einzuführen, zumal der Chef ja selber ein Pfuscher zu sein scheint.
-
Sauber entwickelt wird nur noch im Embedded-Bereich
-
Wenn es der Chef selber ist hast du kaum Möglichkeiten Agile Methoden mit Reviews einzuführen. Dann müsste er nämlich sein tun verteidigen und etwas genauer drüber nach denken was er wann warum ändert. Auch der Chef müsste noch lernen.
(Euer Chef scheint ja seinen eigenen Leuten nicht zu Vertrauen das sie wissen was sie tun -.-)
-
Glutamat schrieb:
Das ganz normale Chaos also ... na dann scheint es die perfekte Softwareentwicklung wohl eh nicht zu geben.
Die gibt es nicht... Ich hab beides schon gemacht.
Intensiv durchgeplant, insbesondere bei größeren Projekten ist das aus meiner Sicht sinnvoll.
Aber ich hab auch schon direkt losprogrammiert. Ich hatte ne Idee und hab die "direkt mal umgesetzt".Es gibt keine exakten Regeln nach denen man ein Softwareprojekt umsetzt...
Oder vielleicht gibts die und ich kenne sie nur nicht
-
Entwicklung selbst ist halt einfach dann sauber, wenn man es gut ändern und erweitern kann. Das ist schon Mal der erste Schritt.
Um das in einem Projekt zu gewährleisten, müssen die einzelnen Leute erstmal so programmieren und für die Planung zur Kollaboration muss man die Bereiche gut abtrennen, mit denen jeder zu tun hat und die Schnittstellen klar definieren.
Dann bastelt jeder sein eigenes Zeug und es ist sicher gestellt, dass es mit den anderen Dingen zusammenpasst.
So viel zur Kollaborationsplanung. Und wenn man sicher sein will, dass man das richtige Projekt entwickelt, muss man natürlich vorher eine ausführliche Anforderungsanalyse machen, damit man sich auch sicher ist, dass Kunde nachher zufrieden ist.
Ich finde, das sind die Kernelemente. Viele UML-Diagramme sind imo unnötig, weil sie einem nur in Einzelfällen selbst helfen. Zur Dokumentation sind sie im Nachhinein teilweise sehr hilfreich und daher ist es in Ordnung sie auch live mitzubasteln (an den Stellen, wo man nicht mehr allzu große Änderungen in nächster Zeit erwartet). Alles in UML vorzuplanen macht aber imo keinen Sinn. Zumindest nicht für jede einzelne Klasse. Nur da, wo Verbindungen zu anderen Bereichen bestehen.
Projektplanung ist spannend, aber man sollte auch nicht zu viel planen. Das, was nötig ist, kann man planen, damit man später weniger Stress hat, aber einzelne Leute sollte man auch autonom walten lassen.
-
Glutamat schrieb:
...oder dass er in einer Nacht und Nebel Aktion an den Sourcecodes seiner Mitarbeiter Dinge ändert, die seiner Meinung nach so nicht stimmen. Natürlich funktioniert das dann alles nicht mehr so wie gedacht, denn meist denkt sich ein Mitarbeiter ja was dabei wenn er gewisse Dinge einprogrammiert (a la "viele Köche verderben der Brei").
Durch die gesammte Herumwurschtelei ist der Source Code am Ende echt zum Kotzen(v.a. weil der Chef in seinen Nacht und Nebelaktionen auch mal gern so tolle Dinge wie goto einbaut, oder Variabelen wie s1, s2, s3 erstellt, wo keine Sau weiß für was die gut sind), und ich denke mir jedes Mal "oh mein Gott was ist da wieder passiert". Wiederverwendbarkeit=Null, Übersichtlichkeit=Null...Das geht schon deutlich über das "normale Chaos" hinaus.
-
Das wuerde ich auch sagen. Die Zustaendigkeiten sollten schon geklaert sein, so dass man seinen Code auch verantworten kann.
@Glutamat
Ich will dir Mut machen, deine Bedenken in einem 4 Augengespraech mit deinem Chef klarzumachen. Wenn er dich nicht versteht oder sich auf nichts einlassen will, dann such dir einen anderen Chef. Langfristig fuehrt das sonst nur zu einer "Frustexplosion". In der Softwarebranche sollte es moeglich sein einen Job zu finden der Spass macht.
-
holzeimer schrieb:
Langfristig fuehrt das sonst nur zu einer "Frustexplosion". In der Softwarebranche sollte es moeglich sein einen Job zu finden der Spass macht.
Es heißt nicht ohne Grund das Softwareentwickler entweder ein Burnout oder Sarkasmus entwickeln.
-
OK danke für die AW.
Ich weiß, dass die Herumpfuscherei im Code echt blöd ist, aber die Sache ist die: Ich bin Student und das ist mein Nebenjob und ich verdiene ca. doppelt so viel wie andere Studenten.
Vieraugengespräch hab ich natürlich schon gesucht, manche Dinge sieht er auch ein, geändert hat sich allerdings rein garnichts.Aber spätestens nach der Uni wechsle ich, Geld hin oder her.
-
Kannst auch deine eigenes Unternehmen aufmachen, mit geklautem, oder selbst erarbeitetem Know How und wirst dein eigener und anderer Leute Wurschtelchef. Wenn es gut läuft, kannst du deine Erfahrungen und spannende Profi-Tipps bloggen.
-
nachtfeuer schrieb:
geklautem, oder selbst erarbeitetem Know How
Wo ist Unterschied?
