Vorgehensweise eines kleinen Software-Projekts
-
Aua hört sich traurig an
Leider hast du recht, das merkt man auch nach gerade mal 5 Monaten in der Ausbildung. Sogar mein Lehrer sagt, dass meistens das Spiralmodell, also programmieren -> testen -> reparieren -> erweitern -> testen etc. angwandt wird.
Doch ich meinte, wie ihr eigene Software in eurer Freizeit programmiert, wie ihr dort vorgeht. Ich denke viele werden auch da drauf los programmieren, ich auch - bis jetzt. Doch einige werden doch sicher mit einem Plan vorangehen. Sicher nicht so ausführlich wie in der Ausbildung gelernt, doch so, dass es hilft bevor man programmiert.
Wenn ich ein Programm umsetzen will fällt mir immer erst nach der Hälfte des Programmcodes auf, das alles totaler Schwachsinn ist. Welche Dinge kann ich vorher abklären um soclhe Situationen zu vermeiden?
-
Kevni schrieb:
... Wenn ich ein simples Konsolenprojekt machen möchte, dass mir zum Beispiel den Inhalt aller Dateien eines Haupt- und dessen Unterordner mit einer von mir festgelegten Zeichenkette durchsucht und die Funde mit Dateiname und Zeile ausgeben soll (ist ein Übrungsprojekt für mich), wie gehe ich da ran bevor ich überhaupt nur meine IDE starte?...
Für sowas würde ich keine Zeit mit irendwelchem Konzeptionskram verschwenden. Wenn das eine Auftragsarbeit wäre, würde ich die Anforderungen schriftlich und verbindlich festhalten und dann loslegen.
-
Kevni schrieb:
wie gehe ich da ran bevor ich überhaupt nur meine IDE starte?
Indem Du erstmal Kaffee aufsetzt. Das sind nur ein paar Zeilen Code, was willst Du da planen
Die ganzen Modelle aus dem theoretischen Unterricht kann man imo für kleine und mittlere Projekte vergessen. Im privaten Bereich sowieso.
-
Ich denke, gerade jene, die die Modelle nicht wirklich anzuwenden wissen, kritisieren die Modelle.
Klar, wenn Chef sagt: "Schreib mir mal eine Erweiterung. Bis morgen muss das fertig sein.", dann hat der Chef von Tuten und Blasen keine Ahnung, weil dadurch wird Schrott-Code entwickelt. Der Code kann nicht durchdacht sein, sondern ist mal schnell hingerotzt und wenn das von Version zu Version mitgeschleppt wird, hat man irgendwann ein Problem. Die Firma wird früher oder später schließen (das sehe ich gerade bei der Firma, bei der ich meine Ausbildung gemacht habe).
Größere Firmen verwenden aufjedenfall Dokumentationen und solche Entwicklungs-Modelle. Unser Prof erzählt jedenfalls immer eigene Erlebnisse, die er in der Wirtschaft erlebt hat und wie man hier und dort bei der Modellierung noch optimieren kann, was wo Sinn macht etc.L. G.
Steffo
-
Ähem, deine Vorposter bezogen sich auf die vom OP gepostete Aufgabe:
Inhalt aller Dateien eines Haupt- und dessen Unterordner mit einer von mir festgelegten Zeichenkette durchsucht und die Funde mit Dateiname und Zeile ausgeben
Was soll man da groß Entwicklungsmodelle anwenden? Das ist in wenigen Zeilen erledigt.
-
MisterX hat da ziemlich allgemein geredet.
Und: Gerade bei (komplizierteren) Algorithmen macht es Sinn ihn zuerst zu modellieren und wenn es nur eine einfache Zeichnung ist, die nicht wirklich einem Standard entspricht. Wenn es aber darum geht, den Algorithmus allgemeinverständlich zu dokumentieren, sollte man natürlich Standards verwenden.Liebe Grüße
Steffo
-
MisterX hat da ziemlich allgemein geredet.
Dann mach doch klar worüber du sprichst.
Ich wiederspreche dir ja gar nicht, nur ist die Aufgabe, die der OP sich selbst gestellt hat, keine schwierige. Sie erfordert keine komplizierten Algorithmen, keine Modellierung, etc.. Von daher: Einfach anfangen und gut ist's.
-
Kevni schrieb:
Morgen,
mich würde mal interessieren wie ihr bei der Erstellung kleiner Software-Projekten vorgeht.
Es kommt darauf an, was man unter klein versteht.
Erfahrene Programmierer können entsprechende Konzepte für ein "kleines" Softwareprojekt in der Regel ohne größere Planung umsetzen.
Weniger erfahrene Programmierer verlieren womöglich binnen kürzester Zeit den
Überblick und verzetteln sich.Die Frage, zu welcher der beiden Kategorien man gehört, ergibt sich eigentlich
relativ schnell.
-
Steffo schrieb:
Und: Gerade bei (komplizierteren) Algorithmen macht es Sinn ihn zuerst zu modellieren und wenn es nur eine einfache Zeichnung ist, die nicht wirklich einem Standard entspricht. Wenn es aber darum geht, den Algorithmus allgemeinverständlich zu dokumentieren, sollte man natürlich Standards verwenden.
Zähl' mal ein paar sinnvolle und praxistaugliche Modellierungen für Algorithmen auf.
-
Steffo schrieb:
...Und: Gerade bei (komplizierteren) Algorithmen macht es Sinn ihn zuerst zu modellieren und wenn es nur eine einfache Zeichnung ist, die nicht wirklich einem Standard entspricht...
Schon klar, "Kritzelmodellierung" macht wohl jeder. Aber wer hält sich schon an die Lehrbuchmethoden? Und welcher Kunde würde das bezahlen wollen? Und wer gibt einem die Zeit für sowas?
Sowas geht mMn nur bei den großen Brocken und macht nur dort Sinn. Seien wir doch mal ehrlich, wenn man sein Handwerk eine zeitlang ausgeübt hat, weiss man bei gut 75% der Fälle was zu tun ist und programmiert das Zeug einfach runter.
-
Cpp_Junky schrieb:
Seien wir doch mal ehrlich, wenn man sein Handwerk eine zeitlang ausgeübt hat, weiss man bei gut 75% der Fälle was zu tun ist und programmiert das Zeug einfach runter.
Genauso ist es.
Und wenn man mit einem bisher unbekannten Problem konfrontiert ist, wird die Lösung nicht auf magische Weise besser, nur weil man vorher ein paar Bildchen malt. Die besten Lösungen ergeben sich dann durch Try & Error und ständiges Refactoring. Also auch sehr sprachbezogen und unter Einbehaltung vieler Prinzipien, Muster und Idiome für eine bestimmte Sprache.
Das vergessen die Modellbauer auch ganz gerne und halten alle Sprachen für mehr oder weniger hässliche Ausprägungen von UML oder ähnlichen Zeitvernichtungstools.
Bei großen Projekten und Teams lasse ich mir separate Entwufsphasen gefallen. Hier geht es aber um kleinern und mittleren Kram.
-
Und weiter gehts.
Steffo schrieb:
Ich denke, gerade jene, die die Modelle nicht wirklich anzuwenden wissen, kritisieren die Modelle.
Warum kann man nicht in einer Programmiersprache modellieren?
-
Ich habe in den letzten 12 Jahren in vier IT-Firmen entwickelt und selten konnte ich ein Projekt großartig planen, das kam auch vor aber meist musst du mit Code zugrechtkommen der irgendein oder manchmal an mehrere Vorgänger dir hinterlassen haben.
Das irgendwas von Grund auf neu zu entwickeln kostet dem Chef viel zu viel Geld, auch wenn das Frickeln irgendwann viel teurer wird als eine anfängliche Neuentwicklung ist großartige Planung oder Unittests etc. nur in wenigen Projekten wirklich zu finden.
Entwickeln heißt mit jedem Scheiß klar kommen und bloß nicht zu viel Zeit mit irgendwas zu verplempern, du sollst ackern und fertig werden und nicht lange planen oder lernen. Die Zeit für Planung und Einarbeitung in neue Projekte musst du dir immer erst "freikämpfen". Das ist von Firma zu Firma zwar unterschiedlich, aber eines hast du in dieser Branche gerantiert nicht und das ist Zeit.
Die IT-Branche ist eine der stressigsten die es gibt, nicht weil man entwicklen muss sonder weil alles immer von heute auf morgen passieren soll und man immer als etwas faul dargestellt wird wenn man da erstmal sich einarbeiten und planen will.
-
Hi,
cih weis nicht genau, ob's ein Vorteil oder eher Nachteil ist, wenn der Chef auch was von Informatik versteht. Aber er hat dann vermutlich mehr Verständnis für gewisse nötige Dinge.
Bei mir ist der Chef kein Informatiker, und wenn der mir irgend eine vage Vorstellung was er gerne hätte ins Ohr gekaut hat, dann taucht er mit Sicherheit spätestens nach 1-2 Stunden auf und fragt "sieht man schon was?".
Oder wie er es mal anders ausgedrückt hat, meine wichtigste Aufgabe ist, herauszufinden was er will.Da ich aber ansonsten recht viel Freiheiten habe was ich wie machen will, nehme ich das halt in Kauf. Also wird als erstes eine Maske gemacht und ein bisschen Mäusekino engebaut und dann erst mal ausgelotet, ob's in die richtige Richtung geht. Und wenn dann klar ist, in welche Richtugn das ganze gehen soll, werden dann die Formulare anschließend mit Leben gefüllt.
Vorher, wo ich noch auf Projektstellen bei der Uni angestellt war, wars noch abartiger. Da mussten wir alle viertel bis halbes Jahr ins Ministerium und vorweisen was das Programm neues kann. Also lag die Primäraufgabe darin, eine gegebene Aufgabe mit möglichst vielen neuen Masken und Formularen zu erfüllen, auf dass man Weiterentwicklung zeigen und eine Anschlussfinanzierung bekommen konnte.
Das Gegenstück war meine erste Abschlussarbeit, damals noch als Ingenieurökonom für allgemeinen Maschinenbau.
Damals habe ich das Prohjekt von zwei Enden gleichzeitig aufgerollt. Zum einen am Anfang die unterste Schicht entwickelt, die über Bios-Abfragen die Tastatur auswertete und direkt in den Bildschirmspeicher schrieb (reine Dos-Anwendung ohne irgendwleche Hilfsmittel direkt in C) bis hin zu einer abstrakteren Schnittstelle mit Linien, Rahmen, Textausgaben, Abfragen, Auswahlboxen...
Den Rest habe ich dann "von oben" gemacht. Lauter einzelne kleine Zettelchen mit C-ähnlichem Pseudocode, die jeweils eine Sache in meist 3-7 Einzelschritte auflösten. Und die wurden dann auf dem nächsten Zettelchen wieder in 3-7 Einzelschritte aufgelöst...main { Erfassen Berechnen Ausgeben } Erfassen { Maske zeichnen erstes Eingabefeld anspringen while ( nicht fertig ) { in passendes Eingabefeld springen Eingabe entgegennehmen } Daten abspeichern Bildschirm löschen } ...Am Ende hab ich dann die einzelnen Zettelchen alle genommen und Schritt für Schritt einen nach dem anderen abgearbeitet. Und wie alle Zettelchen abgearbeitet waren lief das Programm. Würde mein Cheffe aber heute aus der Haut fahren, wenn ich erst tage- oder wochenlang Zettelchen mahlen wollte. Weiß auch nicht, ob ich heute noch die dafür nötige Disziplin hätte.
Das andere Gegenstück ist ein kleines Datenbank-Tool, das ich ursprünglich dem Borland-Datenbankexplorer nachempfunden hatte, weil ich noch irgend etwas an zusätzlicher Funktionalität brauchte. Am Anfang konnte man damit nur Tabellen einsehen und einfache SQL-Abfragen abschicken. Im Laufe der Zeit ist da immer mehr dazu gekommen, so dass es mittlerweile mein wichtigstes Werkzeug ist um in allen möglichen Daten runzustochern und rumzuwerkeln. Jedesmal wenn irgend eine Möglichkeit fehlte, die ich aber brauchte, wurde sie drangestickt. So ist es immer genau das geblieben was ich brauche und optimal auf diesen Zwdck zugeschnitten, aber als reines Rucksackprogramm wirklich nicht sauber entwickelt. Aber es erfüllt die von mir in es gestellten Erwartungen und hat vor allem als für mich als wichtigstes einen Stapelspeicher aller jemals damit eingegebenen SQL-Befehle einschließlich der Datenbank auf die sie angewendet wurden sowie des jeweiligen Datums und einer Suchfunktion dafür.
Wenn mein Chef jetzt kommt uns fragt "Du hast doch da im Janur mal... " dann brauch ich blos zu gucken, was um die Zeit so gelaufen ist und hab 'ne reelle Chance zu verstehen was er meint und ihm weiterhelfen zu können.Gruß Mümmel