Sotwareentwicklung eher Ingenieursdisziplin oder solides Handwerk?

V

vop

Erfahrenes Mitglied
Hi Entwickler

Ich habe mich mal etwas näher mit diesem Link beschäftigt http://www.clean-code-developer.de/

Einer der Punkte, zu der mich eure Meinung interessieren würden, ist die Frage, ob ihr Softwareentwicklung eher als ein solides Handwerk betreibt oder versteht oder ob für euch vor allem der Ingenieurs-Character wichtig ist.

Also wenn ich übertrieben schwarz-weiß-malen würde wären die Extreme:
Erst programmieren, dann mal sehen
vs.
Erst mal ausführlich planen, bevor überhaupt ans Programmieren gedacht wird.

Wie handhabt ihr das?
 
Zuletzt bearbeitet:
Moin,

auch Ingenieurstätigkeiten sind sicherlich handwerklich solide :p ......

Ich habe es mal an der Uni so gelernt, dass ein gutes Software-Engineering in etwa wie folgt zusammensetzt :
50% Planung
15% Codierung
35% Test

Das würde sich in der Praxis sicher auch gut bewähren, wird aber vermutlich nur selten so angewendet. Ich denke mal, dass es in vielen Firmen eher jeweils 1/3 ist ....

Gruß
Klaus
 
Hi vfl_freak

Ja, gelernt ist gelernt...
Nur wie handhabst du das selbst?

Mein Problem ist, dass ich die meiste Zeit in einem 1-Personen-Team sitze. Da weicht man leider allzu oft vom gelernten ab.....
 
Moin,

dass ist hier bei uns leider genau so und nur allzu wahr.
Habe manchmal das Gefühl, hier mit "0|80|20" zu arbeiten, da unser Chef nicht bereit ist, sich im Vorfeld Gedanken über Dinge zu machen (Vorplanung ist nun wirklich nicht sein Ding ...), die da irgendwann unweigerlich kommen .... dann wird halt aufwendig um- und zurückgebaut :-(

Gruß
Klaus
 
Das hängt natürlich auch etwas von den jeweiligen Anforderungen ab. Wenn man ein zusätzliches Modul zu einer vorhandenen Software (die man gut kennt) entwickelt, ist der erforderliche Planungsaufwand sicherlich etwas niedriger.

Wenn man jedoch etwas komplett neues entwickeln soll, muss dem Planungsbereich in jedem Fall ein wesentlich höherer Anteil eingeräumt werden.

Zum Beispiel sollte das Datenbankdesign, das Benutzerinterface und der Datenfluss im Vorfeld möglichst vollständig durchdacht sein, wenn man sich später nicht unnötigen Doppelaufwand aufhalsen will.
 
Ich glaube irgendwie braucht man doch immer beides, oder?
Also ich finde beide Seiten haben ihre Berechtigung.
Aber man kann sich auch zu Tode Planen und UML-Diagramme designen. Bei meinen Kollegen, welche im embedded Bereich Programmieren, fällt mir immer auf, dass da einige so viel "auf dem Blatt" (bzw. mit UML-Tools) programmieren und mit Design Patterns rumhandieren, dass das Ergebnis zwar "schön" codiert ist, aber für den embedded Bereich erstens zu langsam als auch zu speicherfressend.
Andererseits gibt es Quick & Dirty Programmierer, die hacken einfach drauf los, die sind zwar schnell fertig, aber wenn jemand anderes als sie selbst den Code editieren soll dann stoßt er auf ein Code-Chaos, das sämtliche Schichtenmodell-Gedanken komplett ignoriert.
Meine Devise:
Wenn ich was neues mache, mit einer neuen Technolgie oder in einem neuen Gebiet, muss ich erstmal etwas wild drauflosprogrammieren zum testen, was überhaupt geht. Ich kann nicht in einem Gebiet groß planen, wenn ich mit dessen Eigenschaften noch garnicht so vertraut bin.
Danach folgt ein grobes Konzept. Für mich ist es ein Muss bei größeren Projekten (also sprich die die ich auf Arbeit mache, privat mache ich nur kleine Tools für die lohnt sich der Doku-Aufwand nicht, ist auch unnötig in dem Fall find ich)
Es sollte bevor man anfängt zu programmieren klar definiert sein was das Programm alles können muss, und welche Erweiterungsmöglichkeiten für die Zukunft vielleicht jetzt schon voraussehbar sind. Dann sollten die einzelnen Schichten klar definiert werden und die Schnittstellen untereinander. das ist das wichtigste finde ich. Ein gutes Design schließt Möglichkeiten für Tests bereits mit ein, das macht die Tests dann auch wesentlich einfacher und sicherer. Insofern würde ich sagen sinnvoll wäre
10% Vorstudien
20% Planung
50% Programmierung
20% Test
...naja besser nur 45% Programmierung und 5% Pufferzeit, die wird eigentlich immer benötigt :)

gruß
Ringelsocke

40
 
Hallo!
Im meinem Studium haben wir verschiedene Softwareentwicklungsmethoden vorgestellt bekommen und haben auch zwei kleinere Projekte (die jeweils über ein halbes Jahr gingen) (mehr oder weniger) mit einer solchen Methode imgesetzt: Das erste Projekt wurde mit Hilfe des Wasserfall-Modells umgesetzt, das zweite nach den Prinzipien der agilen Softwareentwcklung.

1. Projekt:
Durchlaufen des kompletten Programms mit Lastenheft, Pflichenheft, OOA, OOD, ... Geplant war das Projekt sicher nicht schlecht, nur hat diese Planung einen sehr großen Teil eingenommen. Meiner Meinung nach einen zu großen :). Ich habe mir dabei immer die Frage gestellt, ob man bei wirklichen Projekten überhaupt die Zeit hat, soviel zu planen... Dementsprechend kurz viel dann auch die Implementierungsphase aus, Test und Integration viel gleich weg :)

2. Projekt:
Im Vergleich zum ersten Projekt sehr wenig Planung. Im Grunde belief sich diese auf das Erstellen eines Backlogs und der Klärung einiger anderer Sachen. Anschließend ging es los mit der Entwicklung mit Hilfe von Scrum. Hierbei waren erste Ergebnisse schnell ersichtlich.

Da diese beiden Projekte beide im Studium waren, muss man sich sicher die Frage stellen, wie realistisch die Erfahrungen davon sind. Ich für meinen Teil muss sagen, dass mir das zweite Projekt besser gefallen hat und wir auch produktiver waren. Jedoch denke ich dass eine gewisse Planung notwendig ist, damit eine gute Architektur eingehalten wird und die Software wartbar und erweiterbar bleibt.

mfg flo
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück