mikrocontroller.net

Forum: PC-Programmierung Vorlagen für Software-Architektur


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.
Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in 
C++Builder, die dann plötzlich größer werden als gedacht.
Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn 
die dafür nötigen Programmstrukturen nicht berücksichtigt waren.

Ich frage mich ob es hierzu nicht so etwas wie freie 
Software-Architektur-Templates gibt, die Grundlegende Features von Haus 
aus berücksichtigt haben. Also nicht nur die Gui, sondern auch die 
dahinter nötigen Strukturen für "übliche" Features.
Was ich immer wieder mal bräuchte wäre z.B. ein MDI-Editor-Template wo 
Funktionen wie Undo/Redo berücksichtigt sind. Die Grundstruktur sollte 
verschiedenste Typen berücksichtigt haben... manchmal mache ich 
Text/Datenbasierte Tools, manchmal viel Grafisch ähnlich einem 
Bildeditor, manchmal gemischt... Für Undo/Redo ist also mehr nötig, als 
nur verschiedene Stände eines Texts wegzuspeichern.


Als Beispiel...:
Mal angenommen ich mache mir irgendein kleines Tool in C++Builder um 
Daten zu sortieren und zuzuordnen, wie es mit Excel o.ä. nicht so gut 
möglich wäre.
Dazu braucht es ja nicht viel - vielleicht ein paar Buttons wie "Datei 
Öffnen, Datei Speichern, Daten Verarbeiten, ..." und eine 
Anzeige-Listbox für die Daten.
Sowas ist schnell zusammengeclickt, mit Intelligenz gefüllt und sehr 
praktisch.
Dann fängt das eigentliche Problem erst an - mit der Zeit kommen immer 
neue Ideen, was man auch noch einbauen könnte und je mehr das Tool kann, 
desto wichtiger wird es auch noch so Schnickschnack wie Undo/Redo zu 
haben, was ja normalerweise tief in die Programm & Datenstruktur 
eingreift. Manchmal kommen dann noch andere exotische Wünsche dazu, das 
kann man nie wissen.

Ich kann mir prinzipell schon so eine Software-Architektur überlegen die 
das kann, aber um das wirklich gut und flexibel zu machen ginge viel 
Zeit udn Lehrgeld ins Land. Ich bin mir sicher, dass sich da schonmal 
jemand mehr und vielleicht auch bessere Gedanken gemacht hat und würde 
da lieber drauf aufbauen.

Wer kennt freie Projekte in diese Richtung?
Wer weiß wo es gute Infos gibt, die auf die Interne Softwarearchitektur 
solcher Programme (Editoren wie Texteditoren, Grafikeditoren, 
CAD-Systeme, ...) ausgerichtet sind?

Und bevor jemand die Idee einwirft - nein, Projektplanung im Voraus für 
die Tools ist leider ausgeschlossen! Es ist ja immer nur ein kleines 
Tool, für das nicht viel Zeit zur Verfügung steht und eh selten 
gebraucht wird...

schönen Gruß,
Alex

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine SW-Architektur gibt es nicht von der Stange. Was es aber gibt sind 
PATTERN. Die sind genau dafür da, um gleiche Probleme auf die gleiche 
Art zu lösen.
Trotzdem können die nicht fertig in Code gegossen sein, weil die immer 
auf die konkrete Anwendung passen müssen.

Allein dein Undo/Redo Beispiel hängt doch in größtem Maße von den Daten 
ab. Handelt es sich um Text oder Vektorgrafik oder einen Audioeditor.
Da gibts doch keine Datenstruktur die für alles passt.

Was du aber siehst, auch ein "kleines Tool", welches gut wartbar und 
erweiterbar sein soll, benötigt eine saubere Architektur und ist im 
Endeffekt aufwändig.

"Mal schnell" wird immer mit einbußen erkauft. Da gibt es leider keine 
Abkürzung.

Eventuell solltest du mal von deinem C++Builder weg zu etwas modererem 
wie C# inkl. Visual Studio. In den Libs dort sind natürlich auch schon 
viele viele Standardfunktionalitäten verborgen so dass man nicht mehr 
alles selbst tun muss.

: Bearbeitet durch User
Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in
> C++Builder, die dann plötzlich größer werden als gedacht.
> Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn
> die dafür nötigen Programmstrukturen nicht berücksichtigt waren.

Ja, das ist in der Entwicklung ein ständiges Problem. Genannt auch
"schleichender Featurismus" ( 
http://www.catb.org/jargon/html/C/creeping-featurism.html ). Wenn ein 
Feature unbedingt noch rein soll, muss man dann halt ggf. viel Code 
neuschreiben oder umstrukturieren.

Alex schrieb:
> Ich frage mich ob es hierzu nicht so etwas wie freie
> Software-Architektur-Templates gibt, die Grundlegende Features von Haus
> aus berücksichtigt haben.

Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn 
dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und 
tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung 
mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu 
kriegen, die man gerade nicht gebraucht hat. Aber Vorsicht: Ich denke 
recht negativ, was Softwareentwicklung betrifft. Wir sind am Ars*h.

Alex schrieb:
> Was ich immer wieder mal bräuchte wäre z.B. ein MDI-Editor-Template wo
> Funktionen wie Undo/Redo berücksichtigt sind. Die Grundstruktur sollte
> verschiedenste Typen berücksichtigt haben... manchmal mache ich
> Text/Datenbasierte Tools, manchmal viel Grafisch ähnlich einem
> Bildeditor, manchmal gemischt... Für Undo/Redo ist also mehr nötig, als
> nur verschiedene Stände eines Texts wegzuspeichern.

Ohne jetzt zu wissen, worauf du anspielen willst: Event Sourcing wäre da 
zB ein Stichwort zum Googlen. Zu solchen Mustern kann man sich 
entscheiden oder auch nicht: Nachträglich ist sowas nicht mehr 
einzubauen. Wenn man es nicht braucht, hat man eine unnötig komplexe, 
schwer zu debuggende Programmarchitektur umsonst zusammen mit jeder 
Menge Glue-Code. Juchhe!
Um Planung wirst du nicht herum kommen...

Alex schrieb:
> Als Beispiel...:
> Mal angenommen ich mache mir irgendein kleines Tool in C++Builder um
> Daten zu sortieren und zuzuordnen, wie es mit Excel o.ä. nicht so gut
> möglich wäre.
> Dazu braucht es ja nicht viel - vielleicht ein paar Buttons wie "Datei
> Öffnen, Datei Speichern, Daten Verarbeiten, ..." und eine
> Anzeige-Listbox für die Daten.

Da hätte ich jetzt eher an ein Plugin für Excel o.Ä. gedacht. Wäre im 
Workflow um einiges angenehmer. Ist dann natürlich nur eine Lösung für 
die eine bestimmte Umgebung. Aber dafür eine brauchbare.

: Bearbeitet durch User
Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das Henne-Ei Problem lässt sich nicht vermeiden. Erst nachdem die 
Software real eingesetzt wird, lässt sich die Struktur ausarbeiten.

Zu diesem Thema gibt es nur 2 brauchbare Leitfäden. Frederick Brooks, 
The Mythical Man-Month und Eric Raymond, The Cathedral and the Bazaar.

Brooks kam zu der Erkenntnis: "plan to throw one away; you will, 
anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert.

Autor: Irgendwer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> kleinere PC-Tools(Softwareprojekte) in
> C++Builder

Der C-Builder bringt doch eigentlich etliche Komponenten für Editoren 
mit.
Sich eine Buttonliste Basteln und diese mit den entsprechenden 
Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer 
Minute.
void Form1::Button1Click(...)
{
  RichEdit1->Undo();
}

Softwarearchitektur ist was ganz anderes...

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Danke schon mal für die Rückmeldungen!

Cyblord -. schrieb:
> Eine SW-Architektur gibt es nicht von der Stange. Was es aber gibt sind
> PATTERN. Die sind genau dafür da, um gleiche Probleme auf die gleiche
> Art zu lösen.
> Trotzdem können die nicht fertig in Code gegossen sein, weil die immer
> auf die konkrete Anwendung passen müssen.

Klar gibt es nicht eine perfekt passende Vorlage für alle meine 
Probleme.
Mein wunsch wäre eher aus einer Menge an Vorlagen die am besten 
passenste zu nehmen, meine Funktionen dort einzubauen und von dem 
Standpunkt aus dann weiter zu machen.

Cyblord -. schrieb:
> Allein dein Undo/Redo Beispiel hängt doch in größtem Maße von den Daten
> ab. Handelt es sich um Text oder Vektorgrafik oder einen Audioeditor.
> Da gibts doch keine Datenstruktur die für alles passt.

Deswegen hoffe ich ja, dass sich schonmal jemand schlaueres als ich 
darüber Gedanken gemacht hat und eine gute Allgemein nützliche Methode 
gefunden hat. Die komplexesten Programme die mir so einfallen sind 
CAD-Editoren - die haben jetzt nicht unbedingt mehr Grund-Features für 
den Editor, aber die Struktur
ermöglicht trotzdem alles mögliche wie Text, Grafik, Daten.
Sich in die ganzen Pattern einzulesen und funktionsfähig zu 
implementieren, dass die auch zusammenspielen ist ja auch nicht wenig 
Arbeit und ich hoffe da einfach auf Wiederverwendbarkeit etwas 
bestehenden...

Cyblord -. schrieb:
> Eventuell solltest du mal von deinem C++Builder weg zu etwas modererem
> wie C# inkl. Visual Studio.

Habe ich mir vor ~15 Jahren zum ersten Mal angesehen, aber für meine 
Anwendungen überwiegen einfach die Vorteile vom C++Builder... möchte ich 
jetzt nicht weiter drauf eingehen.

Heiko L. schrieb:
> Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn
> dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und
> tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung
> mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu
> kriegen, die man gerade nicht gebraucht hat. Aber Vorsicht: Ich denke
> recht negativ, was Softwareentwicklung betrifft. Wir sind am Ars*h.

Bin da auch eher Pessimist (erfahrener Realist). Springender Punkt bei 
meinem Problem ist denke ich, dass es nur ein Tool bleiben darf, wo es 
ruhig Grenzen geben darf. Bei den Grund-Features die so ein Template 
mitbringen würde, würde ich dann auch bleiben. Dann hätte ich evtl. 
schon mehr als ich jetzt habe, denn dann würde ich wenigstens mit den 
Features starten und diese nicht erst nach Jahren des Jammerns mal 
einbauen.

Heiko L. schrieb:
> Event Sourcing wäre da zB ein Stichwort zum Googlen.
Ja, danke - in die Richtung soll es gehen. Ich stehe jetzt halt vor der 
Entscheidung solche Dinge im Nachhinein einzubauen oder mein Projekt 
gleich auf eine Version 2.0 in irgendein Template einzubauen.

Heiko L. schrieb:
> Da hätte ich jetzt eher an ein Plugin für Excel o.Ä. gedacht. Wäre im
> Workflow um einiges angenehmer. Ist dann natürlich nur eine Lösung für
> die eine bestimmte Umgebung. Aber dafür eine brauchbare.

Excel ist keine Option, da ich auch viel Grafisch (mit Bildbearbeitung 
o.ä.) mache... oft startet es primitiv mit Zahlen und wenn das Tool sich 
als brauchbar erweist wird es durch komplexere Grafiken & Anzeigen 
erweitert. Da ist Excel das falsche Pferd.

Sisyphusarbeit schrieb:
> Brooks kam zu der Erkenntnis: "plan to throw one away; you will,
> anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert.

Brooks ist echt gut :). Hatte nur immer mal wieder die Zusammenfassung 
gelesen - er hat leider viel zu oft recht. Ändert leider nur nicht viel 
an der gängigen Praxis ;).

Irgendwer schrieb:
> Sich eine Buttonliste Basteln und diese mit den entsprechenden
> Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer
> Minute.void Form1::Button1Click(...)
> {
>   RichEdit1->Undo();
> }
>
> Softwarearchitektur ist was ganz anderes...

Da sind meine Programme leider schon vielfach komplexer... Funktion ist 
von Gui getrennt und die Undo-Methode einzelner Vcl Komponenten bringt 
mir leider nichts.

schönen Gruß,
Alex

Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Bei den Grund-Features die so ein Template
> mitbringen würde, würde ich dann auch bleiben.

Ja, welche wären das denn? Wenn du dir diese Frage klar beantworten 
kannst, dürften sich viele Probleme schon von selbst gelöst haben. Und 
die Wahl an potentiellen Templates hätte brauchbare Kriterien.

Alex schrieb:
> Excel ist keine Option, da ich auch viel Grafisch (mit Bildbearbeitung
> o.ä.) mache... oft startet es primitiv mit Zahlen und wenn das Tool sich
> als brauchbar erweist wird es durch komplexere Grafiken & Anzeigen
> erweitert. Da ist Excel das falsche Pferd.

Das war dein Beispiel. Grundsätzlich kann ich sonst nur Cyblord 
beipflichten: Es wird ziemlich dünn, wenn du einfach nur Undo/Redo haben 
willst. Du müsstest schon wissen, welche Features du brauchst - sonst 
nützt dir auch ein App-Template nichts.

PS:
Alex schrieb:
> Da sind meine Programme leider schon vielfach komplexer... Funktion ist
> von Gui getrennt und die Undo-Methode einzelner Vcl Komponenten bringt
> mir leider nichts.

Eben wegen solchen Sachen.

: Bearbeitet durch User
Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Ändert leider nur nicht viel an der gängigen Praxis ;)

Tja, die modernen Softwareentwicklungsmethoden sind ein Rückschritt. 
Ausgerechnet die drei wichtigsten Punkte ignorieren die modernen 
Methoden.
- Nachdem die Hälfte implementiert ist, fällt auf: Ein anderer Ansatz 
ergäbe nur 1/10 des Aufwandes
- Nach ein paar Jahren haben sich so viele zusätzliche Anforderungen 
angesammelt, die ursprünglichen Designentscheidungen passen einfach 
nicht mehr
- Die Dokumentation ist ein genau so wirres Chaos, wie der Programmcode.

Wahrscheinlich braucht man da eine ganz andere Denkweise. Das wirklich 
wertvolle ist die Dokumentation der Erfahrungen. Historisch gewachsener 
Programmcode hat weniger als gar keinen Wert. Das zentrale Ziel sollte 
eine konsistente, übersichtliche Dokumentation sein, aus der sich 
jederzeit eine neue, funktionierende Architektur entwickeln lässt.

> dass sich da schonmal jemand mehr Gedanken gemacht hat

Na klar, James Watt, Thomas Edison, Werner Siemens… Aber die kamen zu 
der Lösung: Für Erfindung, Konstruktion, Begutachtung, Leitung, 
Produktion und Qualitätssicherung braucht es unterschiedliche 
Charaktere, unterschiedliche Organisation und unterschiedliche 
Ausbildung.

In der Softwareentwicklung sammeln sich halt diejenigen, die mit dieser 
Lösung nicht einverstanden sind. Oder kennst du einen Kodierer, der 
einen Fließbandjob machen würde? Oder einen Entwickler, der sich auf die 
Konstruktion von Datenstrukturen beschränken will?

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heiko L. schrieb:
> Alex schrieb:
>> [...]
>> Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn
>> die dafür nötigen Programmstrukturen nicht berücksichtigt waren.
>
> Ja, das ist in der Entwicklung ein ständiges Problem. Genannt auch
> "schleichender Featurismus" (
> http://www.catb.org/jargon/html/C/creeping-featurism.html ). Wenn ein
> Feature unbedingt noch rein soll, muss man dann halt ggf. viel Code
> neuschreiben oder umstrukturieren.
>
> Alex schrieb:
>> Ich frage mich ob es hierzu nicht so etwas wie freie
>> Software-Architektur-Templates gibt, die Grundlegende Features von Haus
>> aus berücksichtigt haben.
>
> Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn
> dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und
> tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung
> mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu
> kriegen, die man gerade nicht gebraucht hat. [...]
> [...]
>> [...]


Interessant fände ich, begründete Bewertungen von Methoden wie "Agile 
Softwareentwicklung" (im folgenden mit ASE abgekürzt) und ähnlichen 
Ansätzen im Kontrast zu den oben erwähnten Problemen.

Es scheint mir insgesamt so zu sein, dass der Prozess der 
Anforderungsdefinition bei ASE effektiv ein Teil des Auftrags wird. Mehr 
nicht.
Ein Old-School-Entwickler (mal ganz wertfrei gemeint) wird eine 
komplette Anforderungsspezifikation voraussetzen bevor er ein Angebot 
macht und mit der Arbeit beginnt.
In den letzten Jahren (bis Jahrzehnten) aber verstärkt sich der Anteil 
an Auftraggebern, die mit sehr unscharfen Anforderungen Projekte 
anstossen wollen - da ist ASE sozusagen das Gegenmittel, gegen das 
Verlangen nach der kostenlosen Anforderungsanalyse und 
Angebotserstellung.
Der Auftraggeber mag ASE hingegen so sehen, dass er vor allem schnelle 
Umsetzungen seiner (in welchem Maß auch immer unscharfen) Vorstellungen 
bekommt und in gewisser Weise eine Art Mikromanagement betreibt ohne das 
das ausdrücklich so benannt wird.
So kann man das sehen, denke ich, oder was meint Ihr?

Mag dazu jemand was sagen?

Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Alter Wein in neuen Schläuchen. Früher waren auch niemandem die 
Anforderungen klar. Früher hatten die Old-School-Entwickler auch einen 
Prototypen zusammen gekloppt. Ist damals genauso im Chaos versunken wie 
die agile Software.

Das Problem an der Agilen Softwareentwicklung - sobald die Anforderungen 
klar sind, muss man den konfusen Prototypen wegwerfen und eine sinnvolle 
Architektur ausarbeiten. Das dauert halt 6 Monate.

Diese Agilen Consultingfirmen sind Scharlatane. Die erzählen den 
Managern, sie könnten diese 6 Monate einsparen, sie bräuchten nur deren 
teuren agilen Schulungen buchen.

PS. Selbst die blindesten BWLer haben inzwischen gemerkt - Agile 
Softwareentwicklung wird ein Fass ohne Boden. Und was machen diese 
Scharlatane? Die erzählen den BWLern, sie müssten nur teure Schulungen 
zum Thema Mikroservices buchen.

Autor: Tomas T. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Alex schrieb:
> Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in
> C++Builder, die dann plötzlich größer werden als gedacht.

Poste doch erstmal ein paar Beispiele deiner Sourcen...

Autor: USB H. (hubber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte früher auch sehr oft das Problem mit dem schleichenden 
Featurismus (ich glaube euch einfach mal, dass das Wort echt ist). Ich 
habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht.
Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten 
Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit 
Sub-Modulen. Mein Vorbild war damals der Editor Atom mit seinen 
Packages. Ein Package ist dort ein sehr autarkes Modul, ich habe das 
noch etwas mehr auf die Spitze getrieben. Oft nimmt das sogar schon 
API-Ähnliche Züge an. Ich habe meistens ein größeres Feature, bspw. für 
die Toolbar, die dann Methoden hat wie addButton(), oft hat die 
Toolbar-Klasse dann sogar noch ein Sub-Module, bspw. Button.

Ich habe damit wirklich sehr gute Erfahrungen gemacht und kann es 
wirklich jedem empfehlen.

Autor: USB H. (hubber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich noch vergessen habe:
Ich unterscheide zwischen zwei Arten von Modulen, die APIs (z.B. 
Toolbar) und die Module, die den Atom-Packages ähneln. Das Programm soll 
auch dann noch laufen, wenn so ein Modul weggenommen wird, auf dieses 
Modul wird nicht wirklich zugegriffen, höchstens am Anfang initiiert. So 
ein Package arbeitet für sich und greift nur auf API-Klassen zu, nicht 
aber auf andere Packages (außer Sub-Packages).
Die Packages greifen auf die unverzichtbaren API-Klassen zu, die kann 
man natürlich nicht einfach wegnehmen.

: Bearbeitet durch User
Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Es scheint mir insgesamt so zu sein, dass der Prozess der
> Anforderungsdefinition bei ASE effektiv ein Teil des Auftrags wird. Mehr
> nicht.
> ...
> Mag dazu jemand was sagen?

Ja. Iterative Verfahren sind immer die Notlösung, wenn man das 
gewünschte Resultat nicht a-priori bestimmen kann. Dem tragen ja 
offenbar auch einige Prozess-Adaptionen zB beim Wasserfallmodell 
Rechnung: Der Unterschied besteht im Grunde nur noch darin, ob man die 
Iterationen vertikal oder horizontal orientiert aufmalt. Es schreit 
einem nur so entgegen: Du könntest versuchen irgendetwas lückenlos zu 
durchdenken und würdest mit absoluter Gewissheit scheitern. Die Hybris 
menschlichen Geistes. Die Mathematik liefert das Paradebeispiel einer 
jahrtausende lange Geschichte des Scheiterns an noch den simpelsten 
logischen Formen. Der Zahlbegriff, Kantors Mengenlehre, das 
Hilbert-Programm - um nur einige zu nennen.
Wir stehen ideengeschichtlich nicht in der Moderne. Wir haben gelernt, 
dass alles, wenn überhaupt, nur "irgendwie" wahr ist. Den Ideen nur 
mutmaßlich, in Bezug auf einen Kontext, Realität zukommt.
Softwareentwicklung ist der Versuch, einen Marathon zu laufen, obwohl 
klar ist, dass man sich schon nach zwei, drei Schritten auf die Schn*uze 
legen wird. "Agil" sagt quasi "Wir schauen dann mal weiter". 
Uneingeschränkt besser für den Kunden wird es dadurch nicht: "Die 
Freiheit von der eigenen Vergangenheit wird mit Unterordnung unter das 
unmittelbar Vorfindliche erkauft." Wo zur Verbesserung angesetzt wird, 
weiß sogar Wikipedia "ständiges Refactoring" als Merkmal agiler 
Entwicklung anzugeben - umsonst ist sowas nicht. Es trägt der 
Unfähigkeit Rechnung, sich bei einer Begriffsentwicklung nicht schon 
nach zwei Sätzen in Widersprüche zu verwickeln und - aus Not getrieben - 
die beiden Sätze restlos auszutilgen, bis vom Begriff nur noch eine 
leere Worthülse übrig bleibt, die im dialektischen Hin- und Her eben nur 
genau das besagt, was jemand meint - in feiner Abgrenzung zu dem, was 
er denn sagt. Verstehen ist also groß in Mode: Der Kunde ist in 
aller Regel unmündig, hat keine Ahnung, was er will und ist zu 
positiv-transzendenter Setzung einer Idee unfähig: eine 
Anforderungsdefinition verstünde er in ihrer Folge nicht.

Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Kunde ist in aller Regel unmündig, hat keine Ahnung, was er will

"Wenn ich die Menschen gefragt hätte was sie wollen, hätten sie gesagt, 
schnellere Pferde." – Henry Ford

Wir haben seit 100 Jahren ein iteratives Verfahren, in dem das Automobil 
ständig verändert wird. Warum eigentlich? Wieso braucht Fords Lösung 
seit 100 Jahren ein ständiges Refactoring?

Hat Henry Ford doch nicht verstanden, was sein Kunde will? War Ford 
nicht in der Lage die Wünsche seiner Kunden umzusetzen? Hat Fords Lösung 
die Wünsche seiner Kunden verändert?

Gibt es überhaupt irgend einen Bereich, in dem wir Menschen oder die 
Evolution oder die Götter oder sonst wer kein ständiges Refactoring 
betreiben? Wie kann sich ein Produkt der Evolution aus dem ständigen 
Refactoring befreien. Und wieso wollen wir ausgerechnet in der 
Softwareentwicklung das  ständige Refactoring vermeiden?

Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sisyphusarbeit schrieb:
> Gibt es überhaupt irgend einen Bereich, in dem wir Menschen oder die
> Evolution oder die Götter oder sonst wer kein ständiges Refactoring
> betreiben? Wie kann sich ein Produkt der Evolution aus dem ständigen
> Refactoring befreien. Und wieso wollen wir ausgerechnet in der
> Softwareentwicklung das  ständige Refactoring vermeiden?


Eine interessante Idee wäre ein Tool, welches einfach jeden Tag 1-2 
Dateien, Module oder gar Projekte - zufällig ausgewählt - aus dem GIT 
löscht. Artificial Evolution: Was gut war, wird ähnlich noch einmal neu 
geschrieben werden. Fortschritt kennt nur ein Gesetz, welches das der 
Negation ist.
Leider ist die Mutationsrate bei angewandten genetischen Algorithmen 
nicht infinit.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:

> Interessant fände ich, begründete Bewertungen von
> Methoden wie "Agile Softwareentwicklung" (im
> folgenden mit ASE abgekürzt) und ähnlichen Ansätzen
> im Kontrast zu den oben erwähnten Problemen.

Agile Methoden sind in kundigen Händen eine gute
Sache; allerdings haben sie auch eigene Gefahren.


> Es scheint mir insgesamt so zu sein, dass der Prozess
> der Anforderungsdefinition bei ASE effektiv ein Teil
> des Auftrags wird. Mehr nicht.

Herrlich.

"Der Beweis von Andrew Wiles ist lediglich die Arbeit
eines Mathematikprofessors, in der der Fermatsche Satz
bewiesen wird. Mehr nicht."

:)


> Ein Old-School-Entwickler (mal ganz wertfrei gemeint)
> wird eine komplette Anforderungsspezifikation
> voraussetzen bevor er ein Angebot macht und mit der
> Arbeit beginnt.

Ja.


> In den letzten Jahren (bis Jahrzehnten) aber verstärkt
> sich der Anteil an Auftraggebern, die mit sehr unscharfen
> Anforderungen Projekte anstossen wollen - da ist ASE
> sozusagen das Gegenmittel, gegen das Verlangen nach der
> kostenlosen Anforderungsanalyse und Angebotserstellung.

Kann man so sehen, ja.


> Der Auftraggeber mag ASE hingegen so sehen, dass er vor
> allem schnelle Umsetzungen seiner (in welchem Maß auch
> immer unscharfen) Vorstellungen bekommt und in gewisser
> Weise eine Art Mikromanagement betreibt ohne das das
> ausdrücklich so benannt wird.
> So kann man das sehen, denke ich, oder was meint Ihr?

Das ist, denke ich, nicht falsch, greift aber zu kurz.

Der Kernpunkt sind die "unscharfen Vorstellungen" von den
Anforderungen.

Software dient einem Zweck; die meiste Software ist
in einen übergreifenden Arbeitsprozess eingebunden.
Der Arbeitsprozess und die Software sind aufeinander
abgestimmt.

Neue, verbesserte Software erfordert in der Regel auch
einen neuen Arbeitsprozess, der auf genau diese neue
Software abgestimmt ist. Diesen Arbeitsprozess KANN der
Auftraggeber aber noch gar nicht kennen, weil es ja die
zugehörige Software noch gar nicht gibt!

Das ist ein grundlegendes Henne-Ei-Problem. Alle Klein-
geister, die die Auftraggeber grundsätzlich für dumm,
faul und inkompetent halten, übersehen, dass sie Dinge
vom Auftraggeber wissen wollen, die er PRINZIPBEDINGT
noch nicht wissen KANN.

Agile Methoden sind hier mMn kein ganz falscher Ansatz,
weil sie die
1. gemeinsame
2. schrittweise
Erarbeitung von Produktwissen in den Vordergrund stellen.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sisyphusarbeit schrieb:

> Wir haben seit 100 Jahren ein iteratives Verfahren,
> in dem das Automobil ständig verändert wird. Warum
> eigentlich?

Weil Firmen, die nichts verkaufen, weil alle alten
Bedürfnisse befriedigt und keine neuen geweckt wurden,
Pleite gehen, und weil Staaten, in denen die Firmen
reihenweise pleite gehen, keine Steuern einnehmen und
auch Pleite gehen.

Echte Notwendigkeiten spielen nur indirekt eine Rolle.

Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Agile Methoden sind hier mMn kein ganz falscher Ansatz,
> weil sie die
> 1. gemeinsame
> 2. schrittweise
> Erarbeitung von Produktwissen in den Vordergrund stellen.

"Produktwissen" - ich musste es nachschlagen
   
Produktwissen
ist die Menge der im Gedächtnis gespeicher­ten Informationen (interner „Informations­stock“), die eine Produktgruppe betreffen (Informationsverhalten). Dazu gehören Kenntnisse über die relevanten Marken (Evoked Set), die Eigenschaften dieser Marken und die Bedeutung von Produktei­genschaften. Produktwissen wird durch die Informationsbeschaffung und -Verarbeitung sowie durch direkte Erfahrungen mit Pro­dukten erworben. Die Wirkungen des Produktwissens auf das Informationsverhalten von Konsumenten sind uneinheitlich. Einerseits kann ein eher niedriger Informationsstand zu relativ star­ker Informationsnachfrage bei bestimmten Kaufentscheidungen führen, andererseits führt die Vertrautheit mit einer Produkt­gruppe zu besseren Fähigkeiten, größere diesbezügliche Informationsmengen verar­beiten zu können.
http://www.wirtschaftslexikon24.com/e/produktwissen/produktwissen.htm

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Gab hier über Nacht ja einige philosopische Ergüsse - bringt aber keinen 
weiter.

Tomas T. schrieb:
> Poste doch erstmal ein paar Beispiele deiner Sourcen...

Das geht nicht weil es Firmeneigentum ist.

USB H. schrieb:
> Ich habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht.
> Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten
> Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit
> Sub-Modulen.

Meinen Code versuche ich natürlich auch modular zu halten aber so 
wirklich streng bin ich da nicht. Ist sicher eines der Probleme ;).
Ich kenne den Atom Editor jetzt nicht genauer. Kannst du das evtl. mal 
als kleines Pseudocode-Beispiel zeigen wie die Klassen dann 
zusammenhängen oder so?

schönen Gruß,
Alex

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.