Professionelle Softwareentwicklung
-
Hallo!
Wie wird eigentlich professionell Software entwickelt?
Klar hatte ich auf der Uni Fächer wie Software Engineering (OOA, OOD, UML, ...), aber bei den meisten Projekten, sowohl bei einem Praktikum auf der Uni, als auch bei einem Nebenjob in einem Software Unternehmen, hatte ich das Gefühl, dass da mehr zusammen gestöpselt wird als wirklich durchdachte Software erstellt wird. Also man programmiert ein Grundgerüst, testet, der Chef schaut was er dann noch will, ich programmiers dazu, nächste Iteration, ..., Abbruchbedingung ist meist ein Datum und nicht eine wirklich perfekt getestete Software.
Gerne hätte ich mal ein Projekt von vornherein sinnvoll durchgeplant, und erst dann ausprogrammiert. Leider hatte ich noch nie das Vergnügen!Gibt es eine solch perfekte Planung nicht oder hab ich bis jetzt einfach nur in Unternehmen gearbeitet, wo mehr probiert als geplant wird?
Kennt ihr diesbezüglich vielleicht Bücher? Würd gerne in Zukunft selber etwas professioneller an die Sache rangehen. Und wenn möglich mir auch einen Arbeitgeber suchen, der das genauso sieht.
LG
-
-
Glutamat schrieb:
Leider hatte ich noch nie das Vergnügen!
Wahrscheinlich bist du zu jung, aber so wie du es beschreibst wird Software seit Jahrzehnten nicht mehr entwickelt (es gibt natürlich Ausnahmen, z.B. Software für Militärische/Weltraum/Flugzeug Geschichten)
-
Glutamat schrieb:
Gerne hätte ich mal ein Projekt von vornherein sinnvoll durchgeplant, und erst dann ausprogrammiert. Leider hatte ich noch nie das Vergnügen!
Gibt es eine solch perfekte Planung nicht oder hab ich bis jetzt einfach nur in Unternehmen gearbeitet, wo mehr probiert als geplant wird?
Das klingt nach Wasserfallmodell. Und das Wasserfallmodell funktioniert bekannterweise nicht wirklich gut.
Probieren ist gut. Googel mal ein wenig nach Dingen wie SCRUM und XP.
-
Was heißt schon professionell?
Frag deinen Prof. mal, ob er schon ein paar Jahre "richtige" Software für einen Kunden mit begrenztem Budget entwickelt hat.
In der freien Wirtschaft gilt nur eins, mit minimalem Aufwand, die geforderte Funktion zu implementieren. Wenn das einem nach Lehrbuch gelingt, schön für ihn.
-
holzeimer schrieb:
Was heißt schon professionell?
Frag deinen Prof. mal, ob er schon ein paar Jahre "richtige" Software für einen Kunden mit begrenztem Budget entwickelt hat.
In der freien Wirtschaft gilt nur eins, mit minimalem Aufwand, die geforderte Funktion zu implementieren. Wenn das einem nach Lehrbuch gelingt, schön für ihn.
Mir wurde auch viel von Projektmanagement und gut geplanten Vorgängen eingetrichtert. Aber deine Aussage trifft den Nagel auf den Kopf, denn anders sieht es nicht aus bei der Arbeit als Software-Entwickler. Meistens reicht die Zeit/das Budget nicht mal für eine Dokumentation aus ...
@Glutamat
Es gibt sehr viel kommerziellen Lesestoff zu diesen Themen. Und ich für meinen Teil habe einiges davon gelesen (was du vermutlich auch schon hast). Aber diese "professionelle" Arbeitsweise anzuwenden wirst du im wahren Leben wohl kaum finden. Da kann ich diesen Lektoren, Professoren, Seminarleitern, ... nur sagen "Wacht auf und schaut mal in der Realität vorbei. Dann könnt ihr gerne versuchen die Lehrbuchvarianten wieder für voll zu nehmen...".
-
Das ganz normale Chaos also ... na dann scheint es die perfekte Softwareentwicklung wohl eh nicht zu geben.
Welche Bücher empfehlt ihr dann als alltagstauglich? Wenn schon die Uni Theorie nicht realistisch ist, gibts zumindest Bücher die einem wirklich was für die Praxis bringen?
-
shadow schrieb:
Meistens reicht die Zeit/das Budget nicht mal für eine Dokumentation aus ...
Eine... äh, eine was? Was ist denn eine Dokutation? Da muss ich doch gleich mal meinen Chef fragen!
-
Glutamat schrieb:
Das ganz normale Chaos also ... na dann scheint es die perfekte Softwareentwicklung wohl eh nicht zu geben.
Nach meiner Meinung kannst du tendenziell von folgenden ausgehen: Um so kleiner das Entwicklerteam ist, und um so höher die Lebenszeit eines Projektes ist, um so weniger Planung wird durchgeführt.
Ich habe Projekte erlebt, wo 20-30 Softwareentwickler in ca. 5-Mann Teams gearbeitet haben, wo ohne Planung und ohne gute Koordination die Entwicklung eher schwer war (Konkret wurde mit UML, Konzepten, Arbeitsvorgaben etc. hantiert), in den kleineren Firmen mit maximal 3-4 Entwicklern war die Planung wenn nur sehr marginal (gegen Null) vorhanden.
Im aktuellen Projekt (3 Personen) ist es schon eine kleine Revolution gewesen das ich einen Wiki für allgemeine Dinge angelegt habe, ein Bugtrackingsystem und eine Programmierrichtlinie eingeführt habe - Mehr gibt es nicht (Weder UML noch irgendwelche programmierspezifische Dokumentation)! Dennoch ist der Code sogar noch relativ sauber, was wohl auch daran liegt das der Chef gegen Zeitdruck ist, und auch Zeit für das Aufräumen von Code vorhanden ist.
Glutamat schrieb:
Welche Bücher empfehlt ihr dann als alltagstauglich? Wenn schon die Uni Theorie nicht realistisch ist, gibts zumindest Bücher die einem wirklich was für die Praxis bringen?
Ich habe noch kein Buch erlebt das mich auf die Praxis der Softwareentwicklung wirklich vorbereiten konnte. Chaos ist eher die Realität, die ich erlebt habe.
-
Bei uns wird nach scrum entwickelt, jede Abteilung hat so ihre Daily Standups mit Reviews und Sprints.
Dokumentation ist zum Teil da ^^ (Ich kann es nicht richtig beurteilen da dass im Ermessen des Teams ist)
Ein Document Management sowie Wiki ist da, und ein das Task Tracking gehört zur täglichen Arbeit.
(Firmengröße > 300 Mann in 3 Ländern).Wir entwickeln aber auch keine Kundenwünsche, sondern Wahre die dann bei Saturn & Media Markt in der Theke steht.
-
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.
