Softwareentwicklung für die Schmalspur

Für allgemeine Fragen zur Programmierung, welche nicht! direkt mit Lazarus zu tun haben.

Softwareentwicklung für die Schmalspur

Beitragvon Marsmännchen » 9. Okt 2016, 20:45 Softwareentwicklung für die Schmalspur

Liebe Leute,

ich werkel gerade an einem kleinen Projekt herum. Die Welt geht nicht zugrunde, wenn das nicht perfekt wird und ich werde das auch überleben. Trotzdem merke ich, wie mit meinen drei Hauptklassen die Komplexität schon ein Niveau erreicht, dass ich Mühe habe, die Übersicht zu behalten. Das betrifft nicht nur die Fähigkeiten meiner Klassen, sondern auch, was ich als nächstes implementieren muss/sollte/möchte (schließlich bauen die Sachen ja aufeinander auf).
Ich habe mich auch schon ein wenig mit UML und solchen Softwareentwicklungssachen beschäftigt. Da bin ich noch nicht sehr weit, aber ich schrubbel mir schon das eine oder andere UML-Diagramm zusammen (die ich niemanden zeigen werde: zu peinlich) und benutze ToDo-Listen und -Kommentare. Mein Problem mit Softwareentwicklungsliteratur und entsprechenden Wikipediaeinträgen ist, dass es sich bei mir eben um ein kleines, überflüssiges Projekt eines kleinen überflüssigen Hobbyprogrammierers handelt! Ich habe nicht vor, Word oder Gimp neu zu entwickeln. Vieles von diesen Softwareentwicklungsdingsen erscheint mir völlig overdressed für meine Bedürfnisse.
Wie seht ihr das? Wie läuft das bei euch? Habt ihr vielleicht Tipps für eine abgespeckte (Hobby-)Variante der Softwareentwicklung?

... vielleicht werde ich auch einfach nur älter :roll:
Ich mag Pascal...
Marsmännchen
 
Beiträge: 291
Registriert: 4. Mai 2014, 20:32
Wohnort: Berlin
OS, Lazarus, FPC: Ubuntu 16.04, FPC 3.0.2, Lazarus 1.6.4 | 
CPU-Target: 64bit
Nach oben

Beitragvon pluto » 10. Okt 2016, 13:33 Re: Softwareentwicklung für die Schmalspur

Bei meinem neuesten Projekt, habe ich eine Tolle Erfahrung gemacht, mal sehen ob sie mir weiter helfen wird, bei weiteren Projekten. Zunächst mal grob zum Projekt:
Ich habe 5 Arduino Module(Arduino Nano'S) die sind mit einem USB Hub verbunden, der ist am PC zur Zeit angeschlossen. auf den Nanos läuft je ein angepasstes Serielles interface.

Auf der PC Seite laufen 6 Programme, 1 Server und 5 Clients, die einen recht unterschiedlichen Funktions Umfang haben.

Nur ein Beispiel:
Wenn die Musik auf dem Banana PI Pausiert wird, wird Automatisch der Eingang vom Audio Umschalter geändert auf dem PC Eingang, vorher war es der Banana PI Eingang, dieser Weg wird ungefähr genommen:
Programm 1: Eine MPD Client, der die Info zum Server sendet.
Programm 2: Die Arduino API(Bestehen aus unzähligen klassen).
Programm 3: Ein eigener Client, empfängt die Info das die Musik z.b. Pausiert wird. Dann Sendet der ein Kommando an den Sever, der es weiter verteilt an alle Clients auch an den Arduino Client, der wiederum sendet es an den Audio Umschalter.

Ich denke mir hat geholfen, immer in kleinen Schritten vorzugehen und es gleich richtig zu machen und nicht den einfachen weg zu gehen(weil der geht in der Regel nicht). Grobe Notizen habe ich mir schon gemacht, aber das meiste habe ich nicht sehr genau aufgeschrieben.

Es ist aber auch eine Erfahrung die man mit der Zeit macht. Außerdem musst du dir unbedingt die Zeit nehmen, die du brauchst.
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6454
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 17.1 Rebecca | 
Nach oben

Beitragvon AndreasMR » 10. Okt 2016, 18:20 Re: Softwareentwicklung für die Schmalspur

Hallo Marsmännchen,

beruflich bin ich es gewohnt, Software nach Vorgaben eines Lastenheftes, Pflichtenheftes und Technischen Designs zu entwickeln. Bei kritischen Anwendungen folgt nach dem Lastenheft eine Risikoanalyse, deren Maßnahmen in der Regel zu 1/3 zusätzlicher Forderungen im Pflichtenheft und Technischen Design führen. Wenn ich auch an den beiden letztgenannten Dokumenten mitgearbeitet habe, dann ist die Programmidee in meinem Kopf bereits so weit gereift, dass ich konkrete Vorstellungen habe, wie die GUI aussieht, welche Datenstrukturen erforderlich snd, welche Klassen, Objekte, Methoden etc. benötigt werden. Ebenso, welche Algorithmen einfließen werden.
Meistens entsteht parallel zu diesen Dokumenten ein detaillierter Testplan, den die Anwendung und der Code bestehen müssen.

Wenn es dann an die Entwicklung geht, kenne ich zum einen die diskutierten und favorisierten Möglichkeiten der Umsetzung - ich habe aber auch ein Gefühl entwickelt, welche erlaubten Möglichkeiten am effizientesten zur Lösung führen, die zum einen die ganzen Forderungen aus den eingangs erwähnten Dokumenten erfüllen - zum anderen aber auch den definierten Test bestehen.

Alles, was mal funktioniert hat, wird versioniert eingefroren. Erst wenn doch mal Anpassungen erforderlich werden, wird dieser Code wieder überarbeitet und zugehörige Tests wiederholt.

Auf diese Weise habe ich überschaubar wenige Baustellen, an denen ich arbeite. Bei einer ausreichenden Planungstiefe sind die Baustellen so angelegt, dass je Tag mindestens eine davon geschlossen werden kann.

Bei Auftragsentwicklungen ist damit dann auch das Reporting recht überschaubar. Die Anzahl an technischen Schulden, d.h. Dinge, die gerade (noch) nicht abschließend gelöst werden können, und beispielsweise simuliert oder ignoriert werden, versuche ich möglichst gering zu halten. Technische Schulden in einer zu frühen Projektphase lösen zu wollen, resultiert in einem erheblichen Aufwand. Verpasst man aber den richtigen Zeitpunkt, dann steigt der Aufwand (inkl. Testen) ebenfalls wieder drastisch an. Mit ein wenig Gefühl entwickelt man ein Gefühl, wann der richtige Zeitpunkt gekommen ist, einzelne technische Schulden zu lösen.


Ich kenne aber auch den anderen Weg. Einfach drauf los programmieren und die Forderungen reifen mit dem Fortschritt der Entwicklung. Mit steigender Funktionalität steigen auch die Forderungen des Kunden. Bei größeren Anwendungen ist es sehr häufig so, dass die programmtechnische Umsetzung ganz anders ausgesehen hätte, wenn alle Forderungen von Anfang an bekannt gewesen wären.


Beste Grüße

Andreas
Ubuntu 14.04 LTS / Raspbian / Windows: Lazarus ab 0.9 bis 3.0
AndreasMR
 
Beiträge: 71
Registriert: 4. Aug 2015, 14:29
OS, Lazarus, FPC: Linux, Raspbian, Windows | 
CPU-Target: 64/32 Bit
Nach oben

Beitragvon Marsmännchen » 10. Okt 2016, 20:02 Re: Softwareentwicklung für die Schmalspur

Ihr Lieben,

danke für die Rückmeldungen. Ich habe auch schon Bücher über Software-Engeneering gesehen, so mit Lastenheften und so. Ist harter Stoff für jemanden, der noch mit der Sprache / IDE selbst ringt. Aber mir scheint, es ist tatsächlich zu einem großen Teil Erfahrungssache! Mir passiert es momentan noch dauernd, dass ich nach einer Weile proggen merke, dass mein Design nicht stimmt / nicht optimal ist und dann fange ich an, in dem bereits funktionierenden, ausgetesteten Code rumzuschrauben (Implementierung eines Eventhandlings). Tja, was ist besser: immer wieder am Code rumschrauben bis er passt oder den alten ausgetesten Code mitschleppen, auch wenn man weiß, dass man es hätte besser machen können...
Ich mag Pascal...
Marsmännchen
 
Beiträge: 291
Registriert: 4. Mai 2014, 20:32
Wohnort: Berlin
OS, Lazarus, FPC: Ubuntu 16.04, FPC 3.0.2, Lazarus 1.6.4 | 
CPU-Target: 64bit
Nach oben

• Themenende •

Zurück zu Programmierung



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried