Programmieren im Kleinen vs. Programmieren im Großen

[Markus Richter]

Hi Leute,

ich beschäftige mich gerade mit "Software Engineering" und hab da noch
irgendwie ein Verständniss-Problem.

Es ist ständig die Rede davon das sich das "Programmieren im Kleinen"
vom "Programmieren im Großen" unterscheidet und das die Methoden die
beim ersteren verwendet werden im zweiten Fall einfach nur zu Chaos führen.

Was meine Frage jetzt ist: In was unterscheidet sich das denn so direkt?

Grundlage meiner Frage ist das, das selbst das größte Problem doch erst
mal in möglichst kleine Teilprobleme zerlegt werden muß bevor ich
überhaupt dran gehen kann eine Lösung dafür zu programmieren. Und die
einzelnen Teilprobleme die sich nach der Zerlegung ergeben kann ich doch
mit den gleichen Methodiken behandeln wie ich das bei einem kleinen
Problem auch mache. Oder verstehe ich da was falsch. Die Logik dahinter
ist doch immer das selbe: Ich habe ein Problem das ich in Teilprobleme
zerlege. Diese Teilprobleme löse ich und füge die Lösungen zu einer
Gesamtlösung zusammen.
Diese Logik ist doch bei kleinen Problemen die selbe wie beim
komplexesten Problem...

Ciao Markus

[Ingo Moch]

Hallo Markus,

Post by Markus Richter
Es ist ständig die Rede davon das sich das
"Programmieren im Kleinen" vom "Programmieren
im Großen" unterscheidet und das die Methoden
die beim ersteren verwendet werden im zweiten
Fall einfach nur zu Chaos führen.
Was meine Frage jetzt ist: In was unterscheidet
sich das denn so direkt?
Grundlage meiner Frage ist das, das selbst das
größte Problem doch erst mal in möglichst
kleine Teilprobleme zerlegt werden muß [...]
Diese Logik ist doch bei kleinen Problemen die
selbe wie beim komplexesten Problem...

Ich glaube Du verdrehst da was, denn eigentlich
argumentierst Du es selbst schon.

Wenn kleinere Projekte eine Groesse aben, die
man "in einem Stueck" im Kopf verarbeiten kann,
muss man da auch nichts mehr zerlegen.

[Markus Richter]

Hi Ingo,

Post by Ingo Moch
Ich glaube Du verdrehst da was, denn eigentlich
argumentierst Du es selbst schon.
Wenn kleinere Projekte eine Groesse aben, die
man "in einem Stueck" im Kopf verarbeiten kann,
muss man da auch nichts mehr zerlegen.

Naja, ich gebe halt das wieder was in den Büchern steht. Allerdings
bestätigt mich die Tatsache das du es genauso siehst in der Annahme das
die meisten die solche Bücher schreiben einfach nur sehr wichtige *gg*
Dampfplauderer sind die eigentlich ein und dasselbe nur mit
verschiedenen Wörtern beschreiben.

Ciao Markus

[Robert Kochem]

Post by Markus Richter
Naja, ich gebe halt das wieder was in den Büchern steht. Allerdings
bestätigt mich die Tatsache das du es genauso siehst in der Annahme das
die meisten die solche Bücher schreiben einfach nur sehr wichtige *gg*
Dampfplauderer sind die eigentlich ein und dasselbe nur mit
verschiedenen Wörtern beschreiben.

Ich glaube du hast nur die falsche Perspektive. Alle Projekte, die in ein
(respektive dein) Hirn "am Stück" hineinpassen gehören in die Kategorie
"winzig", egal was du für ein Genie bist.
"Programmieren im großen" meint normalerweise Team-Programmierung mit
mindestens drei Beteiligten, die dann ein Projekt bearbeiten, das einer
alleine nicht bewältigen könnte.

Robert

[Markus Richter]

Hi Robert,

Post by Robert Kochem
Ich glaube du hast nur die falsche Perspektive. Alle Projekte, die in ein
(respektive dein) Hirn "am Stück" hineinpassen gehören in die Kategorie
"winzig", egal was du für ein Genie bist.
"Programmieren im großen" meint normalerweise Team-Programmierung mit
mindestens drei Beteiligten, die dann ein Projekt bearbeiten, das einer
alleine nicht bewältigen könnte.

Das sich hier dann etwas in der Verwaltung des ganzen ändert
(Versionsverwaltung,...) sehe ich ein, aber rein von der Programmierung
her (aus Sicht eines Programmierers dieses Teams) ändert sich doch
nichts wenn die Planung und Verwaltung vorher anständig gemacht wurde, oder?

Ciao Markus

[Robert Kochem]

Post by Markus Richter
Das sich hier dann etwas in der Verwaltung des ganzen ändert
(Versionsverwaltung,...) sehe ich ein, aber rein von der Programmierung
her (aus Sicht eines Programmierers dieses Teams) ändert sich doch
nichts wenn die Planung und Verwaltung vorher anständig gemacht wurde, oder?

Die Planung - also unter anderem die Einteilung in Komponenten und die
Definition der Interfaces gehören meiner Meinung nach schon zur
Programmierung. Außerdem müssen die teile am Ende auch wieder
zusammengesetzt und zusammen getestet werden. In der Theorie sollte das
problemlos gehen (wegen der vorher definierten Interfaces). In der Praxis
sieht es leider oft anders aus.

Robert

[Markus Richter]

Hi Robert,

Post by Robert Kochem
Die Planung - also unter anderem die Einteilung in Komponenten und die
Definition der Interfaces gehören meiner Meinung nach schon zur
Programmierung. Außerdem müssen die teile am Ende auch wieder
zusammengesetzt und zusammen getestet werden. In der Theorie sollte das
problemlos gehen (wegen der vorher definierten Interfaces). In der Praxis
sieht es leider oft anders aus.

Was aber doch an einer nicht genauen Umsetzung des definierten Zustandes
bzw. eine nicht genau genug definierte Ausgangslage zur Umsetzung
hindeutet. Also ist doch entweder schon die Basis falsch nach der
entwickelt werden soll (Planungsfehler; Schnittstelle funktioniert auch
theorethisch auf einem Blatt Papier nicht) oder aber der Code der
entwickelt wurde (es wurde sich nicht an die geforderten Sachen gehalten
und eigenmächtig irgendwas anders programmiert o.ä.).

In beiden Fällen sehe ich nicht den direkten Zusammenhand wieso das bei
einem großen Problem anders sein soll als bei einem Kleinen. Die Planung
wie etwas zusammenarbeitet muß ich doch bei diesem und beim anderen
machen. Wenn ich das nicht überblicke und deswegen Fehler mache, dann
ist doch nicht die Projektgröße dran schuld, sondern nur die Unfähigkeit
das ich das Problem dann eben nicht überblicken kann und noch weiter
unterteilen muß.

Ciao Markus

[Thomas Michel]

Post by Markus Richter
Naja, ich gebe halt das wieder was in den Büchern steht. Allerdings
bestätigt mich die Tatsache das du es genauso siehst in der Annahme das
die meisten die solche Bücher schreiben einfach nur sehr wichtige *gg*
Dampfplauderer sind die eigentlich ein und dasselbe nur mit
verschiedenen Wörtern beschreiben.

Nun ich gebe Dir in gewisser weise Recht, in anderer aber nicht. Weiso
das? Ganz einfach, viele von Büchern über Software Design sind
inhaltlich mehr oder weniger Bücher die eine große Ladung Bullshit Bingo
enthalten.

Aber es gibt eben die Unterschiede zwischen den von Dir zitierten
kleinen und großen Projekten. Es ändert sich schon ab dem Moment sehr
viel, wenn aus einem 1 Mann Software Projekt ein Zwei Mann Projekt wird,
da es eine gewisse Größe überschreitet. Ich will gar nicht von Projekten
mit der Größe >10 Mann reden. Viele Mechanismen kann man einfach nicht
mehr so handhaben wie bei einem 1 Mann Projekt. Klar ist es noch so,
dass man z.B. einen Reis auf ein Fesnter noch genauso malt, aber die
kommunikation der Schnittstellen der einzelnen Module untereinander, die
Dokumentation der einzelnen Module, die planung der Zeit die benötigt
wird für die Module (Projektplanung / Test / Integration etc. ) ist
irgendwann ein sehr wichtiger Teil, und diese Mechanismen werden halt
bei großen Projekten komplexer als bei einem 1 Mann Projekt...

Gruß

Thomas

[Markus Richter]

Hi Thomas,

Post by Thomas Michel
Nun ich gebe Dir in gewisser weise Recht, in anderer aber nicht. Weiso
das? Ganz einfach, viele von Büchern über Software Design sind
inhaltlich mehr oder weniger Bücher die eine große Ladung Bullshit Bingo
enthalten.

Na wenigstens habe ich nicht als einziger diesen Eindruck. ;-)

Post by Thomas Michel
Aber es gibt eben die Unterschiede zwischen den von Dir zitierten
kleinen und großen Projekten. Es ändert sich schon ab dem Moment sehr
viel, wenn aus einem 1 Mann Software Projekt ein Zwei Mann Projekt wird,
da es eine gewisse Größe überschreitet. Ich will gar nicht von Projekten
mit der Größe >10 Mann reden. Viele Mechanismen kann man einfach nicht
mehr so handhaben wie bei einem 1 Mann Projekt. Klar ist es noch so,
dass man z.B. einen Reis auf ein Fesnter noch genauso malt, aber die
kommunikation der Schnittstellen der einzelnen Module untereinander, die
Dokumentation der einzelnen Module, die planung der Zeit die benötigt
wird für die Module (Projektplanung / Test / Integration etc. ) ist
irgendwann ein sehr wichtiger Teil, und diese Mechanismen werden halt
bei großen Projekten komplexer als bei einem 1 Mann Projekt...

Wie in meiner Antwort auf das andere Posting schon gesagt, das sich in
der Verwaltung des ganzen etwas ändert sehe ich ein und das bedingt
schon die Komplexität. Allerdings kann ich deiner Ausführung nicht
folgen das sich bei komplexen Problemen bspw. die Kommunikation zwischen
den Modulen verändern soll im Gegensatz zu einem kleineren Problem. Ich
habe nach wie vor 2 Module die miteinander kommunizieren, genauso wie
bei einem kleineren Problem. Wo also sollte die Kommunikation schwerer
bzw. komplexer werden als bei einem kleinen Problem?

Genauso der Test. Der nimmt doch auch nur zeitmäßig zu. Wenn die
Anforderungen klar sind, die Dokumentation des ganzen im Vorfeld
passiert ist und die Testteams nicht aus dummen Leuten besteht, dann ist
doch auch hier die Komplexität beim Test nicht mehr, weil nach wie vor
einzelne Funktionen und Ihre Zusammenarbeit getestet werden. Die Zeit
die dafür beansprucht wird nimmt mit Komplexität zu, aber das wars dann
doch auch schon. Oder sehe ich hier auch was falsch?

Außerdem ging es mir ja nicht darum das die Komplexität der Mechanismen
zunimmt, sondern um die Tatsache das die meisten Bücher behaupten das
die Mechanismen die bei einem kleinen Problem funktionieren bei einem
großen nicht mehr funktionieren würden und umgekehrt. Wenn dies der Fall
ist, dann behaupte ich jetzt einfach mal ganz frech, ist in der
Planungsphase schon was schief gelaufen und es sind wichtige Sachen
nicht gut genug spezifiziert usw. Ansonsten könnte ich den gleichen
Mechanismus für alle Probleme nutzen. Ich löse ja abstrakt gesehen auch
alle Probleme (durch Zerteilung) gleich.

Ciao Markus