Forum: PC-Programmierung Arbeitsablauf Programmierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von HauSi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hey,
ich wollte von euch wissen wie Ihr an die Programmierung an sich ran 
geht.

Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr 
Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch 
vorschweben.

Würde mich sehr über praktische Kenntnisse die man im HomeSchooling 
nicht so sehr lernt  freuen :)

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Gerüchten zufolge hängt es von vielen Faktoren ab, wie man an eine Sache 
herangeht. Etwa der Sprache, der Art der Projekte, der übergeordneten 
Organisation, etc., pp.

von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Reden wir von einem 10 Zeiler, welcher 100 Mal "Hello world" schreibt ?

Den lassen wir erst mal weg. Das Programm hat also erst mal eine 
Funktionalitaet. Die bildet man erst mal schnell ab. Dann muessen auch 
Debug Strukturen her, und nachher soll das Ganze auch noch bedienbar 
sein.

Ja nachdem wer etwas zu sagen hat beginnt man anders wo. Wenn die 
Funktionalitaet eher Trivial ist, also die Bediener hohes Gewicht haben, 
beginnt man mit der Bedienung und eher nichts hinten dran.

Wenn die Wartbarkeit ein Thema ist, schafft man wartbare Strukturen zu 
Beginn weg.

Wenn die Funktionalitaet aufwendig ist, die Bedienung eher einfach, 
beginnt man mit der Funktinalitaet.

Wenn man offene Fragen hat ueber die Verwendete Technologie loest man 
diese zuerst mit ein paar Testmustern.

Wenn der Geldgeber aufsaessig ist, bedient man den zuerst. Der Will 
immer etwas, dh einen Fortschritt, sehen.

: Bearbeitet durch User
von imonbln (Gast)


Bewertung
2 lesenswert
nicht lesenswert
HauSi schrieb:
> ich wollte von euch wissen wie Ihr an die Programmierung an sich ran
> geht.

Das Hängt immer von der Kultur im Unternehmen ab. Nicht umsonst sagt man 
"Culture eats strategy for breakfast!" und da Software Entwicklung ein 
sehr manueller Prozess ist. Hängt das oft von den Menschen, ab welche an 
den Prozess beteiligt sind.

Grundsätzlich gibt es in der Planung der Software zwei Ansätze "Top 
Down" oder "Bottom Up", welcher für dein Projekt sinnvoll ist, hängt von 
dem Umfeld, in den du arbeitest ab.

Beim Top Down Ansatz planst du das ganze Projekt durch, gerne wird hier 
UML oder ähnliches verwendet, um Ergebnisse zu produzieren. Der Ansatz 
wird gerne in großen Firmen genutzt oder in Sektoren wo man Sehr stark 
mit Safty Requirements zu tun hat. Der Nachteil von dem Ansatz ist, dass 
man nur sehr spät auf Änderungen reagieren kann, sein es Änderungen am 
Markt unvorhergesehene Probleme oder ähnliches. Der Auftraggeber bekommt 
nur selten eine Möglichkeit Steuernd einzugreifen. Der Vorteil die 
Software ist Gut Beschrieben und Zertifizierungen sind meistens leicht 
möglich.

Beim Bottom Up Ansatz, versucht man in schneller Folge kleine werte zu 
schaffen, welche sich in einem Lego Prinzip zu einem Komplexen Konstrukt 
vereint. Diese Strömung wird zum Beispiel im Agilen zelebriert und gerne 
von Start-ups gelebt. Große Konzerne versuchen das zwar zu Kopieren, 
scheitern aber oft an ihren internen Prozessen und Silos der 
Zuständigkeiten. Der Vorteil von einer Bottom Up Entwicklung ist, das 
relativ schnell Feedback vom Auftraggeber eingesammelt werden kann und 
man sehr schnell auf eine neue Situation reagieren kann. Der Nachteil 
ist, dass man leicht technische Schuld aufbaut und es zu einer Situation 
kommen kann, in der man sein Projekt restrukturieren muss, um weiter 
zukommen. Man entwickelt also eine ganze Menge Code, der nur eine 
Zwischenlösung ist.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
HauSi schrieb:
> Hey,
> ich wollte von euch wissen wie Ihr an die Programmierung an sich ran
> geht.
>
> Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr
> Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch
> vorschweben.

Kommt ganz auf das Programm an. Oft (öfter als ich eigentlich zugeben 
sollte) kommt VHIT-Programmierung (vom Hirn ins Terminal) zum Einsatz.
Allerdings muss ich oft Dinge prototypisch ausprobieren, weil es keine 
klaren Anforderungen, sondern eher Ideen gibt und man dann damit etwas 
spielen muss. Es ist eben in meinem Fall selten die Entwicklung einer 
komplett durchspezifierten Software. Das sieht in anderen Bereichen ggf. 
ganz anders aus.

von Crazy H. (crazy_h)


Bewertung
1 lesenswert
nicht lesenswert
Ich geh jetzt mal von einem Programm für einen Mikrocontroller aus:
- Grundgerüst (Prozessortyp, Treiber und Treiber definitionen)
- Wenn ein Display angeschlossen ist oder Status-LEDs diese zum Laufen 
bringen
- Funktionen für die einzelnen Hardwarekomponenten erstellen (Sensoren, 
Aktoren, ...)
- den ganzen Mist im Main vereinen :-D

von A. S. (achs)


Bewertung
3 lesenswert
nicht lesenswert
Losprogrammieren

ja, ich weiß, sollte man nicht machen. Ist aber die Essenz der ganzen 
tollen Projektideen der letzten 20 Jahre.
Entweder bist Du noch ein Programmier-Anfänger, dann ist die 
Programmiererfahrung wichtiger als Konzepte, die Du noch nicht 
durchblicken kannst.
Oder Du bist ein Profi, dann kennst Du die wichtigsten Konzepte und 
kannst Deine Gedanken besser direkt formal ordnen

1) Ablaufdiagramme (z.B.: Nassi-Sheydermann)
Die waren vor den ersten Hochsprachen sinnvoll, da der (Assembler-)Code 
schlechter zu lesen war, bzw. viele Instruktionen brauchte, die in einem 
Kästchen oder Pfeil dargestellt werden.

Heute ist das Unsinn, die Darstellung in der (bekannten) 
Programmiersprache, mit Chromacoding, Faltung, Token-Browsing etc. ist 
deutlich aussagekräftiger.

2) Scrum, XP, ...
die sagen praktisch nichts anderes, als relativ schnell einen Prototypen 
zu bauen und den sukzessive zu erweitern. Es ist einfach wichtig, 
schnell zu sehen, wie es sich anfühlt. Niemand glaubt heute, dass zu 
beginn eines Projektes jemand die Anforderungen aufnehmen kann

3) UML, Matlab-Simulink-Stateflow und Co
Entweder ist es die Programmierung oder es dient dazu, das Problem mit 
anderen zu erörtern, die Lösung zu entwickeln. Es ist aber etwas 
anderes, das Problem zu erarbeiten oder zu Programmieren. Natürlich 
sollte man das Problem zuerst einmal irgendwie verstehen. Wenn dazu UML 
gut ist, OK. Bleistiftzeichnungen oder Power-Point, ein Besuch beim 
Kunden oder ein Video des Prozesse, alles OK.

4) Eine falsch Architektur kann das Projekt gefährden oder teuer machen
Ja. Das ist so. Das Problem ist nur, dass man die richtige Architektur 
meist erst entwerfen kann, wenn man das Problem durchdrungen hat. Und 
das ist meist erst, wenn man zumindest ein erstes System rund laufen 
hat. Darum ist hier sogar der Rat: Das erste System direkt für die Tonne 
kreieren. Das Antipattern ist es, bereits für die ersten Daten und 
Methoden alle Eventualitäten zu berücksichtigen. Das geht meist (wenn 
nicht immer) in die Hose. Stattdessen schlank und straight 
programmieren, und sich nicht scheuen, immer wieder zu refakturieren, 
sprich: Code auch wegzuschmeißen.

Also ja, mach mit Bleistift überlegungen. Und versuche das Problem/die 
Aufgabe zu verstehen, konkret: Testfälle und deren Kriterien zu 
formulieren. Und dann leg los, wie es am besten passt.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
HauSi schrieb:

> Wie plant Ihr euer Programm, plant Ihr es überhaupt?

Je innovativer ein Projekt für die Beteiligten ist,
desto mehr wird Projektplanung zum Mythos. Planen
lässt sich nur, was weitgehend verstanden worden ist.


> Schreibt ihr Struktograme, Ablaufpläne, zeichnet Ihr
> Klassenhierarchien die euch vorschweben.

Das ist ein anderes Thema -- nämlich das Thema
"Dokumentation".

Ich vertrete die Außenseitermeinung, dass bei kleinen
Projekten die Dokumentation relativ gesehen wichtiger
wird als bei großen -- die Komplexität sinkt nämlich
nicht im selben Maße wie die Zahl der Beteiligten. Bei
sehr kleinen Projekten muss jeder Beteiligte eine recht
große Komplexität bewältigen; das verführt viel stärker
dazu, "einfach zu machen", als wenn man sich immer mit
mehreren anderen Kollegen abstimmen muss. In größeren
Projekten entsteht einiges an Dokumentation "nebenbei".


Konkret: Festgestellte Fehler, gewünschte Änderungen
und vorgenommene Modifikationen protokolliere ich kurz
in Textform (ASCII-Files); komplizierte Algorithmen
bekommen eigene Texte zur Herleitung, Erklärung und
Beschreibung. Um die Modularisierung zu veranschaulichen,
verwende ich manchmal eine Art Blockschaltbild.

von Martin V. (oldmax)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Es kommt immer darauf an, Programm vorgegeben oder eigene Idee. Ich hab 
mal für absolute Anfänger ein Buch geschrieben und im Netz bei 
MakerConnect.De kostenlos verfügbar gemacht.
https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf
Hier wird beschrieben, wie ein Programm Schritt für Schritt entsteht. 
Das Ergebnis ist ein Visual Basic Programm, welches die Variablen eines 
Assemblerprogrammes erfaßt, in das entsprechend verwendete Format 
wandelt und zur Anzeige bringt. Vorausgesetzt, das Assemblerprogramm ist 
als Listing vorhanden. Man kann auch Trigger setzen und im Programm 
positionieren, umm einen bestimmten Programmteil zu prüfen. Die 
zugehörigen Variablen werden dann farblich gekennzeichnet. Nun ja, wenn 
du dich da mal kurz reinliest, so in etwa kann ein Programm entstehen. 
Aber das ist nicht zu verallgemeinern. Ich habe jahrelang Maschinen 
programmiert. Das ist etwas ganz anderes. Oft muß ein Programmabschnitt 
erst mal analysiert werden, um mit vorhandener und erweiterter 
Peripherie Funktionsabläufe sicher zu ändern. Manche Änderungen brachten 
den Bedienern enorme Informationsvielfalt, ohne auch nur einen Cent in 
neue Peripherie zu stecken. Lediglich vorhandene Systeme wurden zur 
Visualisierung herangezogen. So haben wir Monitore in EX-Räumen vor die 
Fenster außerhalb des Raumes gesetzt und die Anzeige auf den Monitoren 
in einer sehr großen Schrift angezeit. Die Lesbarkeit war sogar für 
halbblinde wie mich noch aus einer Entfernung von über 10 m ohne Brille 
gegeben.
Was will ich damit sagen, Programmieren ist das eine, beherrschen von 
verschiedenen Systemen und Programmiersprachen das andere. Eine gute 
analytische Fähigkeit gepaart mit Kombinationsgabe, und es gibt so gut 
wie keine Probleme mehr. Na ja, von dem was hier steht trifft auf mich 
vielleicht 60-70 % zu. Ich mußte dann leider aufhören zu lernen, weil 
ich  beim Staat unkündbar angestellt wurde und erst, wenn ich Platz in 
einer 3 Liter Dose habe, ist er mich los.
Gruß oldmax

von Falsche Flagge (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Crazy H. schrieb:
> Ich geh jetzt mal von einem Programm für einen Mikrocontroller aus:


Ich nicht. Allein schon deshalb, weil die Frage in der Rubrik 
"PC-Programmierung" gepostet wurde.

von W.A. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
HauSi schrieb:
> Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr
> Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch
> vorschweben.

Als erstes werden die Testszenarien definiert, damit das Programm in 
jeder Phase der Entwicklung verifiziert werden kann.

von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
Egon D. schrieb:
> Planen lässt sich nur, was weitgehend verstanden worden ist.

Das ist die zentrale Erkenntnis. Die leider viele nicht verstehen, und 
sich fragen, warum ein Architekt das 11te Einfamilienhaus so viel 
genauer hinkriegt als ein softwerker die 11te Automatisierung. Oder den 
BER.

von Christoph M. (mchris)


Bewertung
0 lesenswert
nicht lesenswert
>Egon D. schrieb:
>> Planen lässt sich nur, was weitgehend verstanden worden ist.

>Das ist die zentrale Erkenntnis. Die leider viele nicht verstehen, und
>sich fragen, warum ein Architekt das 11te Einfamilienhaus so viel
>genauer hinkriegt als ein softwerker die 11te Automatisierung. Oder den
>BER.

Der Wunschtraum der Projektleitung ist aber, dass ein Projekt planbar 
sein soll.

Lustigerweise glauben ja viele an das V-Modell und das damit alles 
planbar sei .. allerdings gibt es im V-Modell viele verdeckte Schleifen, 
nicht anderes meinen als: funktioniert's nicht, mach's noch mal besser 
...

von W.S. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
HauSi schrieb:
> Wie plant Ihr euer Programm, plant Ihr es überhaupt?

Ja natürlich plant man das.

Aber das WIE ist sehr unterschiedlich:

Bei manchen Vorhaben arbeite ich zu allererst die Algorithmen und das 
generelle Procedere aus, bevor ich auch nur eine Zeile Code schreibe.

Bei anderen Projekten gehe ich von der anderen Seite heran: da schreibe 
ich zu allererst die Headerfiles (bei C) oder die Interfaces (bei 
Pascal), dann die zugehörige Funktionalität. Das ist die Version von 
ganz unten, also von den Lowlevel-Treibern, die dann auch separat 
getestet werden können

Und bei noch anderen Projekten (für den PC) mache ich zu allererst das 
grafische UI.

Und bei noch anderen Projekten ist die eigentliche Hardware-Entwicklung 
zu allererst (also was da wie funktionieren soll), dann die 
gestalterischen Fragen (Gehäuse usw.) und dann erst der ganze 
Software-Kram.

Kurzum: es hängt vom Projekt ab, aber eines ist klar: das "in die Tasten 
hauen" für den Quellcode kommt ganz zuletzt, wenn es neu ist. Bei 
anderen Quellen hab ich ein Portfolio an Lösungen angesammelt, die sich 
ganz einfach bewährt haben und die schlichtweg übernommen werden. Da 
gibt es allenfalls ne Anpassung.

> Schreibt ihr Struktograme, Ablaufpläne,
> zeichnet Ihr Klassenhierarchien die euch
> vorschweben.

So eng sehe ich das nicht. Natürlich macht man gelegentlich so seine 
Aufzeichnungen, Pläne, Zustandsdiagramme, Skizzen, Ablaufpläne usw., 
aber das ist nur um die Gedanken klarer zu fassen. Viel wichtiger ist 
es, Interfaces festzulegen. Also die Schnittstellen zwischen einzelnen 
Funktionsgruppen - und das exakt und vollständig. Nur damit kriegt man 
ein Gesamtprojekt so aufgeteilt, daß man es auf mehrere Leute (oder 
zeitlich versetzt für sich selbst) aufteilen kann.

Aber bedenke mal eines: Ich bin einer, der Geräte konzipiert, die sich 
anschließend auch verkaufen lassen - und nicht bloß ein simpler 
Programmierer.

W.S.

von was (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also zunächst mal werden für die nächsten X Wochen etliche Meetings 
geplant, damit die ganzen Product Owner und Scrum Master beschäftigt 
sind.

Währenddessen machen die erfahrenen Entwickler ihr Ding.

Am Ende setzen sich dann alle zusammen und die Entwickler drehen das 
fertige Produkt so hin, dass die Product Owner und Scrum Master 
hinterher glauben gewollt zu haben, was sie bekommen.

von Maxe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Je innovativer ein Projekt für die Beteiligten ist,
> desto mehr wird Projektplanung zum Mythos. Planen
> lässt sich nur, was weitgehend verstanden worden ist.
Das gilt aber nur fuer die Zeitplanung. Die technische Planung ist fuer 
innovative Projekte um so wichtiger und auch aufwendiger. Zumindest wenn 
man kein Zufallsergebnis will. Fuer Routineaufgaben kommt man eher ohne 
detaillierte Vorausplanung aus.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Maxe schrieb:
> Die technische Planung ist fuer
> innovative Projekte um so wichtiger und auch aufwendiger.

naja, dass innovative kann man nicht planen. Man kann dann Innovationen 
umsetzen, wenn man sie verstanden hat.

Man kann bei Innovationen höchstens Minimal- oder Maximalprinzip 
anwenden, also Minimal: das Ziel möglichst schnell und billig irgendwie 
erreichen (frickeln)
oder Maixmal: Ein Budget X zur Verfügung stellen und das verforschen.

was schrieb:
> Am Ende setzen sich dann alle zusammen und die Entwickler drehen das
> fertige Produkt so hin, dass die Product Owner und Scrum Master
> hinterher glauben gewollt zu haben, was sie bekommen.

Die selbstreflexion hat kein Owner oder Master. Egal, was Du ihnen am 
Ende andrehst, sie haben das Gefühl, dass sie es mit ihren 
Projekt-Management-Tools (und den damit geknechteten) quasi nach ihrem 
Ebenbild erschaffen haben.

von Maxe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> naja, dass innovative kann man nicht planen. Man kann dann Innovationen
> umsetzen, wenn man sie verstanden hat
Beispiel Corona-App. Da muss man sich schon genau ueberlegen, welche 
Daten man erfasst/verarbeitet, was zentralisiert auf den Servern liegen 
soll, welche Projektbeteiligten noetig sind, wie man den Code prueft 
usw. Bevor auch nur die erste Zeile Code geschrieben war, mussten diese 
Dinge weitgehend geklaert sein, ja, geplant sein.

Beim 20ten Messgeraete-GUI ist das anders. Es muss auch definierte 
Anforderungen geben, aber vieles ist schon implizit klar.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:

>>Egon D. schrieb:
>>> Planen lässt sich nur, was weitgehend verstanden
>>> worden ist.
>
>>Das ist die zentrale Erkenntnis. Die leider viele nicht
>>verstehen, und sich fragen, warum ein Architekt das
>>11te Einfamilienhaus so viel genauer hinkriegt als ein
>> softwerker die 11te Automatisierung. Oder den BER.
>
> Der Wunschtraum der Projektleitung ist aber, dass ein
> Projekt planbar sein soll.

Dann soll sich die Projektleitung auf reine Bauprojekte
beschränken, auf solche trifft das weitgehend zu -- der BER
ist eben die Ausnahme, die die Regel bestätigt...

Entwicklungsprojekte bergen halt ein Entwicklungsrisiko
in sich.


> Lustigerweise glauben ja viele an das V-Modell

<hinterhältige_Falle>

Was ist denn DAS V-Modell?

</hinterhältige_Falle>


> und das damit alles planbar sei

Vieles aus dem Dunstkreis des V-Modells ist durchaus
sinnvoll, aber es gehört halt immer noch Sachverstand
dazu, zwischen den weitgehend bekannten Dingen, die
TATSÄCHLICH planbar sind, und den neuartigen und
unbekannten Dingen zu unterscheiden -- bei letzteren
muss erstmal das Kernproblem erkannt, formuliert und
dann Wissen aufgebaut werden.


> .. allerdings gibt es im V-Modell viele verdeckte
> Schleifen, nicht anderes meinen als: funktioniert's
> nicht, mach's noch mal besser ...

Genau.
Solche Modelle sind Stadtpläne -- keine Kochrezepte.
Was man tun und in welche Richtung man gehen muss,
hängt stark davon ab, wo man gerade steht...

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
Maxe schrieb:

> Egon D. schrieb:
>> Je innovativer ein Projekt für die Beteiligten ist,
>> desto mehr wird Projektplanung zum Mythos. Planen
>> lässt sich nur, was weitgehend verstanden worden ist.
>
> Das gilt aber nur fuer die Zeitplanung. Die technische
> Planung ist fuer innovative Projekte um so wichtiger
> und auch aufwendiger.

Jein.

Ich stimmte Dir zu in der Aussage, dass reichlich geistige
Vorarbeit zu leisten ist -- aber ich scheue mich (aufgrund
sehr schlechter Erfahrungen), diese geistige Arbeit "Planung"
zu nennen: Das Ergebnis der Planung ist ein ausgearbeiteter
Plan, und ein Plan ist verbindlich und daher einzuhalten.

Genau das funktioniert aber nicht.

Ich kenne das so, dass man denkt und diskutiert und macht,
und als Ergebnis entsteht eine Landkarte, die einige Bezirke
enthält, die man schon ganz gut kennt, und dazwischen auch
weisse Flecken zeigt, über die man nix weiss. An dem Punkt
lassen sich VORLÄUFIGE Arbeitsschwerpunkte benennen, die man
in der nächsten Zeit verfolgt.
In der nächsten Runde ist die Lage wieder so ähnlich -- nur,
dass die Landkarte jetzt etwas anders aussieht.


> Fuer Routineaufgaben kommt man eher ohne detaillierte
> Vorausplanung aus.

Das hängt SEHR stark von der Art der Routineaufgabe und der
Anzahl der Beteiligten ab.

von Nunyagu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrung ist dass die wesentliche Kernidee sich in einer hoch 
abstrakten Scriptsprache wie Python in 100 bis 200 Zeilen Code 
formulieren lässt.
Das hat den Vorteil dass man sich nur auf die eigentliche Funktionalität 
konzentrieren kann. Änderungen am Code und das auffinden von Fehlern im 
Algorithmus sind ebenfalls einfacher.
Python ist ideal um sehr schnell Prototypen zu erstellen.

Danach erfolgt noch einiges an Denkarbeit und es entstehen schon die 
ersten konkreten Ideen wie so ein Programm strukturiert sein sollte.

Danach kann man beginnen das ganze in C++/Rust/C# oder was auch immer zu 
schreiben. Der Anfang ist dann besonders einfach weil man die 
Scriptsprache als eine Art Vorlage nutzen kann.

von Nunyagu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man kann Python dabei wie eine bunte Knetmasse sehen die kinderleicht zu 
formen ist. Oder man betrachtet es als Lego :D

An so einem Objekt Ideen immer wieder umwerfen und abändern ist 
besonders leicht und genau das ist am Anfang eines Projektes wichtig da 
man noch ergründen muss wie es am besten geht.

Formen mit Knete oder Lego auszuprobieren ist natürlich einfacher als 
Metalle in CNC Maschinen zu fräsen. Maut man eine Maschine aus Metall 
ist man auch weniger dazu geneigt mit neuen Ideen zu experimentieren 
weil das dann viel Arbeit bedeutet und man komplizierte Vorgänge erneut 
durchlaufen muss.

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
Nunyagu schrieb:
> Man kann Python dabei wie eine bunte Knetmasse sehen die kinderleicht zu
> formen ist.

Ja, diese Python-Knete nutze ich auch sehr intensiv. Praktisch alle
Teile einer Software, bei denen ich mir anfangs bzgl. der Algorithmik,
der Datenstrukturen oder der Implementierung noch unsicher bin, werden
erst einmal quick & dirty in Python umgesetzt und dann so lange hin und
her gebogen, bis ich überzeugt bin, die optimale Lösung für das
jeweilige Teilproblem gefunden zu haben.

Auf dem Weg dahin besteht die Möglichkeit, die Software(teil)protoypen
und die von ihnen gelieferten Ergebnisse Kollegen vorzustellen und mit
ihnen darüber zu diskutieren, was meistens zu weiteren wertvollen
Erkenntnissen führt.

Das Prototyping erspart einem zwar keine Irrwege, aber diese Irrwege
können zeitlich in viel kürzerer Zeit bewältigt werden als bei einer
direkten Implementierung in der Zielsprache (hier meist C++).

Jeder Irrweg fördert auch das Verständnis des Problems. Deswegen ist es
von Vorteil, wenn in gegebener Zeit möglichst viele davon beschritten
können.

Danach sind zwar nicht alle, aber doch die meisten Unsicherheiten
ausgeräumt, was die Erstellung eines detaillierten Projektplans
erleichtert, der dann i.Allg. auch sehr viel besser einhaltbar ist als
ohne (oder mit nur eingeschränkter) Prototyping-Phase.

Die Umsetzung der Python-Prototypen in C++ ist ein weitgehend
mechanischer Prozess, da es für die meisten Python-Datentypen und
Kontrollstrukturen C++-Äquivalente gibt (C++ hat sich diesbezüglich in
den letzten Jahren stark weiterentwickelt). Die Implementierung der
nicht prototypisierten Teile verläuft meist ebenfalls ziemlich
geradlinig, da bei diesen die Art und Weise der Umsetzung ja schon vorab
kaum mit Unsicherheiten behaftet war.

Da stellt sich natürlich die Frage, warum man überhaupt noch eine
C++-Implementierung macht und nicht gleich das Python-Programm verkauft.
Gründe dafür können sein:

- Python-Code erleichtert – verglichen mit kompiliertem C++-Code – das
  Reverse-Engineering, was bei kommerzieller Software ein großer
  Nachteil ist.

- Die Ausführung des Python-Codes ist zu wenig performant.

- Der C++-Compiler deckt manchmal Fehler oder Schlampereien auf, die in
  der Python-Implementierung unentdeckt bleiben.

- Auf der Zielplattform ist Python nicht verfügbar.

- Firmen- oder Kundenrichtlinien geben (oft ohne nachvollziehbare
  Begründung) die Implementierung in einer bestimmten Sprache vor.

: Bearbeitet durch Moderator
von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Niemand glaubt heute, dass zu beginn eines Projektes jemand die
> Anforderungen aufnehmen kann

Naja, könnte man schon. Nämlich genau dann, wenn sowohl auf Kundenseite 
als auch auf Seiten des Software-Lieferanten Leute sitzen, die wirklich 
Ahnung von der Sache haben und vernünftig beschreiben können was 
gebraucht wird.

Insbesondere in größeren Firmen hat man aber auf Lieferantenseite 
Vertriebler oder Projektmanager, die keine Ahnung haben, schon gar nicht 
von Software. Und auf Kundenseite fehlt diese Ahnung ebenfalls oft, etwa 
wenn man zwar Software braucht (z.B. um eine Maschine anzusteuern), aber 
es dort in der Firma niemanden gibt der Software entwickelt.

Es könnte allles so toll sein, wenn man einmal mit Profis arbeiten 
dürfte ;-)

von Martin V. (oldmax)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Wem sagst du das? Habe viele Jahre diese Versäumnisse an Anlagen 
aufgebügelt. Der Hammer war ein Lagerprogramm einer namhaften Firma, 
welches Bestandslisten nach Fachnummern sortiert ausgegeben hat. Der 
Grund, der beauftragende Ingenieur hat versäumt, im Pflichtenheft darauf 
hinzuweisen, das eine Sortierung nach Lagerartikel stattzufinden hat. Es 
war mein erstes Pascal-Programm, den Lagerbestand aus einer 
Sicherungsdiskette auszulesen und Sortierung nach Wunsch sowie 
verschiedene Suchfunktionen zu liefern. Dabei war nicht das Programm das 
Problem, sondern die eigenartige Ablage der Datensätze. Da ich das mehr 
oder weniger privat zu Hause gemacht habe, hat es fast 4 Wochen 
gedauert, bis es fertig war. Als es damals mit den Worten "sowas machen 
unsere Elektriker" der Firma bei ihrer Preisforderung für ein paar 
Anpassungen ihrer Software vorgeführt würde, gaben die kleinlaut zu, das 
natürlich eine Sortierung nach Artikel im Programm vorhanden, aber 
aufgrund des fehlenden Eintrags im Pflichtenheft nicht freigeschaltet 
war.
Aber das ist schon laaaaange her.
Gruß oldmax

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin V. schrieb:
> aber
> aufgrund des fehlenden Eintrags im Pflichtenheft nicht freigeschaltet
> war.

Das mache ich sogar heute noch GENAU SO. Der Grund ist ganz einfach. Die 
Funktion ist mit wenig Aufwand zu integrieren, wenn man sich von vorne 
herein darauf einstellt, das sie verlangt wird.

Dann wird einfach der Button "ausgeblendet" und das war's.

Irgendwann bei den Präsentationen fällt irgend einen ein, das sie die 
Funktion brauchen. Dann verweise ich auf das Pflichtenheft, den sehr 
großen Aufwand und je nachdem wie sympathisch mir die Leute sind, und 
wie sich mich behandelt haben, setzt ich dann ein Nachschlags-Preis 
fest.

Und wenn die auch mal mir ein Fehler verzeihen dann gibt es sie sogar 
gratis.

Ein guter Programmierer sieht immer zu, das er im Voraus denkt und weiß 
was der Kunde will. Er macht Vorschläge beim Vorab Gespräch.

ABER je arroganter der Auftragsgeber rüber kommt, je teurer wird es für 
ihn. Das sollten die Auftragsgeber sich merken. Ist vermutlich auch der 
Grund warum die aktuell berühmteste APP 20 Mio. gekostet hat, und jede 
Menge Bugs hat. ;)

Nur ein Rat kann ich jeden Entwickler geben. Lasst euch das Design 
absegnen. Die Funktionen der Software sind nicht wichtig, aber das sie 
gut aussieht. Klingt bescheuert, ist aber bei mir 30 Jährige Erfahrung. 
Besonders bei den Leuten die was zu sagen haben, aber keine Ahnung von 
der Praxis.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.