www.mikrocontroller.net

Forum: PC-Programmierung Wie große Programme programmieren?


Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich als Hobbyprogrammierer kann kleine Programme sehr gut ohne Planung 
programmieren. Das funktioniert aber bei großen Programmen nicht. Wie 
plane ich große Programme jetzt richtig? Gibt es etwas mit 
Erfolgsgarantie?

Im Moment scheitern alle großen Programme an "Ver-Spaghetti-sierung". 
Ich bitte jeden darum, der schonmal ein großes Programm geschrieben hat, 
zu posten:
- wie viele Zeilen hat das Programm?
- welche Sprache?
- wie wurde das Programm geplant?
- wurde der Plan eingehalten?
- ...

Ich möchte gerne auch große Programme schreiben können! (über 1000 
Zeilen)

Gruß, Feadi

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ad 1) ca. 1.8 Millionen
ad 2) C++
ad 3) vor 20 Jahren. Die Entwickler haben darüber geredet welche
      Subsysteme es geben soll, welche Aufgaben diese haben und
      wie die Teile zusammenarbeiten sollen (Schnittstellen).
ad 4) Im grossen und ganzen ja. Natürlich hat es im Lauf der
      Zeit Änderungen gegeben. Neue Dinge an die vorher keiner
      gedacht hat, sind dazugekommen. Andere Dinge haben nicht
      so funktioniert wie angedacht und es mussten neue Konzepte
      überlegt und ausprobiert werden. Es kamen Erweiterungen
      dazu. Das GUI wurde zwischendurch 2 mal modernisiert, etc.
      Aber die Grundbasis ist heute im Wesentlichen immer noch
      dieselbe.

> Gibt es etwas mit Erfolgsgarantie?

Nein.
Na ja. Stimmt nicht ganz. Klar kann man die Spezifikation
so detailiert schreiben, dass das Pgm dann auch 100%
genau diese Spez einhält. Nur: Niemand garantiert, dass
die Spez. nicht in sich widersprüchlich ist und 2.tens
kann sich ausser dem DoD und den Luftfahrtfirmen und vielleicht
noch JPL keine normale Softwarefirma den Aufwand leisten.
Grauzonen gibt es in jedem Projekt. Mir ist auch noch kein
Projekt untergekommen in dem sich nicht während der Entwicklung
die Anfoderungen noch etwas ändern. Sollte nicht so sein, ist
aber so in der Praxis.

> Im Moment scheitern alle großen Programme an
> "Ver-Spaghetti-sierung".

Dagegen hilft nur
* modularer Aufbau
* konsequente Aufgabenteilung der Module
* Disziplin
* Disziplin
* Disziplin


Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

An dieser Stelle würde mich auch noch interessieren, wie man so grosse 
Projekte sinnvoll testen kann. (Sowohl Prinzipien, als auch konkrete 
Verfahren)

Gruss

Michael

Autor: oimelx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das allerwichtigste ist sauber zu definieren: Was soll eigentlich 
umgesetzt werden. Im professionellen Bereich wird so etwas in der Regel 
durch ein "Pflichtenheft" realisiert.
Häufig ist es jedoch trotzdem so, dass sich Anforderungen während der 
Programmierung, oder nach Fertigstellung ändern. Gerade im Bereich der 
kaufmännischen Software ist dies "normal".
Für diese Probleme heisst das Zauberwort meiner Erfahrung nach : 
Modularisierung.
Gerade wenn Projekte größer werden ist dies mit "Spagetticode" nicht 
mehr zu handhaben. Deshalb muss man sich überlegen: Was gehört 
funktionell zusammen?
Ein wichtiges Werkzeug zur Kapselung ist die objektorientierte 
Programmierung. Vereinfacht kann man sagen, dass diese Art der 
Programmierung  der Arbeitsweise des Gehirns recht nahe kommt. Wenn man 
eine Schachtel Zigaretten von a nach b transportieren will, ist es nicht 
relevant um welche  Marke es sich handelt. Auch die Anzahl der 
Zigaretten ist unwichtig. Man muss in diesen Moment auch nicht wissen, 
wie eine einzelne Zigarette entnommen werden kann. Es wird nur das 
Objekt "Zigarettenschachtel" bewegt. Das nennt man Abstraktion. Alles 
was mit der Schachtel zu tun hat, wird zusammengefasst und kann im Code 
als eine Einheit benutzt werden. Änderungen an der Schachtel werden nur 
im Modul vorgenommen, der restliche Code bleibt davon weitestgehend 
unbeindruckt.
Den Spass der Abstraktion kann man noch weiter treiben, mit der 
sogenannten "Service orientierten Architektur". Beispiel: Eine Firma 
will ihre interne Software umbauen. Modularisieren wir wieder: Was wird 
sich niemals ändern?
Eine Firma hat Kunden. Die müssen angelegt, gespeicher, bearbeitet und 
gelöscht werden. Abgelegt werden die Daten in einer Datenbank. Alle 
diese Funktionen schreibt man nun so, dass sie unabhängig von allen 
anderen Softwarefunktionen (zB. Lieferanten) funktionieren und fügt sie 
in einem sogenannten "Service" zusammen. Häufig erhält dieser nun noch 
eine Webschnittstelle per "SOAP". Über diese kann man die komplette 
Funktionalität in fast jeder beliebigen Programmiersprache wieder 
einbinden  (über das Internet theoretisch überall auf der Welt) und mit 
anderen Services zusammenfügen (zB. Bestellungen). Bei disziplinierter 
Umsetzung einer solchen Strategie ist jede Anforderungsänderung durch 
das "Lego-artige" zusammensetzen gut handhabbar. (Prominente Anwender 
von Webservices sind zB. ebay, google, amazon, fedex etc. Komplette Ebay 
funktionen können zB. nach registrierung bei ebay in eigener Software 
genutzt werden.) Kurz noch zu Softwaretests: Es gibt zahlreiche 
Frameworks mit denen sich mehr oder weniger komfortable Unit-Tests bauen 
lassen. Im Prinzip schreibt man für jedes Stück Code unmittelbar eine 
Testroutine. So wächst neben der Software auch der komplette 
Softwaretest. Damit erreicht man das nach jeder kleinen Änderung 
automatisiert der KOMPLETTE Anwendungstest in wenigen Sekunden 
durchlaufen werden kann. Fehler sind so viel einfacher zu finden. 
Wikipedia liefert zu allen Stichpunkten sehr gute Einstiegspunkte. Hoffe 
ich hab mich nicht zu umständlich ausgedrückt und es war ein bisschen 
hilfreich.
Gruß
oimelx

Autor: Sigma N. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oimelx

Das Beispiel mit der Zigarettenschachtel ist genial. So gut hat mir das 
auch noch keiner erklärt, wie das mit den Objekten verhält. Als alter 
Basic-Fan hatte ich immer meine Schwierigkeiten, den Sinn solchen 
Vorgehens
zu erkennen.

Gruß Sigma N.

Autor: pittbull_nt@yahoo.com (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigma N. wrote:
Als alter
Basic-Fan hatte ich immer meine Schwierigkeiten, den Sinn solchen
Vorgehens
zu erkennen.

das machste früher oder später automatisch. auch mit sprachen, die nicht 
direkt oo unterstützen ;)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> An dieser Stelle würde mich auch noch interessieren, wie man so grosse
> Projekte sinnvoll testen kann. (Sowohl Prinzipien, als auch konkrete
> Verfahren)

Ganz konkret.
Das System mit dem ich die letzten 20 Jahre verbracht habe, war
eine Art CAD System. Ein Modul davon ist klarerweise der
Graphikkern. Seine Aufgabe ist es die komplette Graphikstruktur
zu halten und zu verwalten.
Eine Szenerie besteht aus einem Objekt. Ein Objekt kann ein
einzelnes graphisches Objekt oder eine Gruppe von anderen
Objekten sein. Dadurch spannt sich, ausgehend von der Szenerie
als Wurzel, ein kompletter Baum von Objekten auf, wobei in den
Endknoten graphische Objeke sitzen und die Baumebenen dazwischen
eine Hierarchie bilden.
Graphische Objekte wiederrum bestehen aus einer Sammlung von
Primitiven. Jedes Primitiv besteht aus Punkten, die zu Kanten
zusammengeasst werden, welche wiederrum in Schleifen organisiert
sind die wiederum Flächen bilden.
In dieser Struktur können auch Querverweise existieren, wenn
ein Objekt seine räumliche Position an die Position eines
anderen Objektes koppelt, oder zb. ein dynamisches Mass sich
bei einer Größenänderung eines anderen Objektes verändern muss.

Teil der DLL, die sich um die komplette Datenstruktur kümmert
ist ein Prüfmodul, dass die komplette Datenstruktur auf Fehler
untersucht. Dort wird abgeprüft, ob Pointer noch auf
gültigen Speicher verweisen, ob die Hierarchieverkettung gültig
ist (Vorwärts - Rückwärtsverkettung) und noch viele andere Dinge.
In einem Debug-Build wird vor jeder Operation, die irgend etwas
in der Datenstruktur verändert, diese Prüfroutine aufgerufen.
Danach wird die Operation durchgeführt und nachdem diese ab-
geschlossen ist, wird wieder geprüft ob die Datenstruktur noch
in Ordnung ist.

Durch diese ständige Prüfung läuft zwar das Pgm 3 mal so langsam
wie die Auslieferversion, dafür ist aber seit Jahren kein
Showstopper in den Funktionen dieses Moduls vorgekommen. Falls
tatsächlich mal ein Fehler in einer neu hinzugekommenen
Funktionalität war, so haben ihn die Prüfroutinen gefunden.
Wenn es tatsächlich mal Fehler unentdeckt bis zur Testmannschaft
geschafft haben, so wird als erstes die Prüfroutine erweitert
bis dieser Fehler zuverlässig detektiert werden kann. Erst dann
wird der Fehler korrigiert. Ich bin mir sehr sicher, dass zur Zeit
kein wirklich schwerwiegender Fehler in diesem Modul enthalten
ist, der zb. einen Absturz verursachen würde. Leichtere Fehler
werden wahrscheinlich noch drinnen sein, geschätzt aber sicher
weniger als 50 oder 60.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das nicht öde, 2 Dekaden mit ein und demselben Projekt zu 
verbringen? - oder habe ich das was falsch verstanden ?

Ansonsten Danke für die interessanten Infos zum modularen Testen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist das nicht öde, 2 Dekaden mit ein und demselben Projekt zu
> verbringen? - oder habe ich das was falsch verstanden ?

Absolut nicht. Ganz im Gegenteil.
Das Projekt bleibt ja nicht stehen, sondern entwickelt
sich weiter. Und mit jeder Ergänzung stösst man die Tür für
weitere Entwicklungsrichtungen auf.
Es ist fast wie ein Kind, das du von seiner Geburt weg
in seiner Entwicklung verfolgst und aktiv begleitest.
Und klar: natürlich gibt es Durststrecken, die fad sind.
Aber dann kommt wieder ein Moment, der das alles aufwiegt:
Wenn das Pgm Dinge kann, die du (und dein Kunde) nie
für möglich gehalten hättest.
Und ja: natürlich gibt es in jedem Programm Code-Stellen
die einfach 'nicht stimmen'. Ich kann das schlecht beschreiben,
aber der Code in einigen Bereichen sieht einfach falsch aus.
Das ist mehr ein Gefühl in der Bauchgegend; wie bei einem
Bild, bei dem die Farbkomposition irgendwie falsch zu sein
scheint.
Und irgendwann gehst du's dann an und arbeitest an dem Teil.
Durch die Modularisierung geht das auch relativ gut. Das Modul
hat seine Schnittstellen nach aussen, die du nach Möglichkeit
gleich lässt. Aber intern bleibt kein Stein auf dem anderen.
Und plötzlich lichtet sich die Dunkelheit. Eins passt zum anderen,
und dann stehst du mit einer neuen Struktur da, die einfach nur
schön ist. An solchen Tagen (oder Wochen) gehst du dann abends
mit einem Lächeln nach Hause.



Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe hier ein Zitat aus 
http://www.mikrocontroller.net/articles/Diskussion... :
"Im Nachhinein ist es naturgemäß immer schwer Änderungen einfließen zu 
lassen, wenn das nicht bei der Planung bedacht wurde."

Trifft das wirklich zu, oder plant man da nicht richtig?


Ich hätte gerne noch ein Beispiel zur Modularisierung vom Programmen in 
C++.

Gruß, Feadi

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Thema interessiert mich auch, kennt jemand ein gutes Buch indem 
anhand eines Projektes das ganze exemplarisch exerziert wird? Am besten 
wäre natürlich c/c++. Hab bisher noch kein Programmierbuch gefunden das 
das anhand eines Beispiels macht... alle Programmierbücher enden wenn 
die Syntax erklärt wurde

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hätte gerne noch ein Beispiel zur Modularisierung vom Programmen
> in C++.

Also bei objektorientierter Programmierung.
Dort sind Objekte im wesentlichen deine Module.
Eine gute Methode für einen ersten Entwurf ist zb.
Geh deine Aufgabenstellung noch mal durch und achte darauf
welche Hauptwörter drin vorkommen. Diese Hauptwörter sind
erste Kandidatenm für die Objekte die du brauchen wirst.
Wenn eines dieser Objekte komplex ist, dann überlege dir
woraus sich dieses Objekt zusammensetzt. Die dabei benutzten
Hauptwörter sind wiederum Kandidaten für Objekte.

Ein Beispiel:
Dein Freund und du wollen Schach spielen. Dazu schreibst
du ein Pgm, dass euch dabei die Arbeit abnimmt. Es
geht also nicht darum, dass das Pgm selbst Schach spielt
sondern es soll nur die Züge entgegennehmen, eine Anzeige
updaten, prüfen ob die Züge gültig sind, ev ein
Protokoll ausdrucken, die Figuren bewegen. Kurz und
gut: es soll das Schabrett simulieren.

Also was haben wir:
  Brett             das eigentliche Schachbrett
  Liste von Zügen   die brauchen wir um das Protokoll
                    drucken zu können
  einen Zug         der auszuführende Zug. So ein Zug hat
                    auch ein Eigenleben. Er besteht aus
                    den Positionen von wo der Zug weggeht
                    und wo der Zug hinführt.
                    Ausserdem speichern wir noch welche Figur
                    das war. Ergo haben wir noch
  Position          Wie wird am Brett eine Position gekennzeichnet
  Figur             Eine Auflistung aller möglichen Figuren
  Farbe             Die Farbe der Figur
  Anzeige           Dort wird der aktuelle Stand ausgegeben.
  Zugprüfer         Das ist weniger offensichtlich aus der
                    Beschreeibung von oben. Aber wenn wir einen
                    Zug prüfen wollen, muss es auch eine Maschine
                    geben, die dies tut.
  Spiel             Dieses Objekt hält alles zusammen. Es nimmt
                    Eingaben entgegen (könnte man auch in ein
                    eigenes Objekt auslagern) und veranlasst, dass
                    die Objekte zu arbeiten anfangen.

Hab ich noch was vergessen? Möglich. Wir werden im Lauf der Zeit
schon noch drauf kommen, was fehlt.

OK. Welche Eigenschaften haben diese Einzelteile, woraus
bestehen sie, welche Aufgaben haben sie?

Brett:  Das Brett ist eine Matrix. In jedem Schnittpunkt (also
in jedem Feld) dieser Matrix kann eine Figur sein oder auch nicht.
Was uns an dieser Stelle zb. überhaupt nicht interessiert ist,
ist ob das Feld Weiss oder Schwarz ist. Für das Spiel an sich
hat das überhaupt keine Bedeutung. Ob weiss oder schwarz ist etwas
worum sich die Anzeige kümmern muss.
Ansonsten muss das Brett nur einen Zug ausführen. Es tut dies
indem die 'Figur' von einem Feld auf ein anderes Feld verschoben
wird.

Liste von Zügen: Dieses Teil hat administrativen Charakter.
Ein Zug wird vom Benutzer über die Eingabe eingegeben und
nach erfolgter Prüfung auf Gültigkeit der Zugliste übergeben.
Die Zugliste speichert den Zug und veranlasst, dass er am Brett
ausgeführt wird. Es mag aber auch spezielle Eingaben geben, die
veranlassen, dass ein Zug zurückgenommen wird bzw. ein zurück-
genommener Zug wieder ausgeführt wird. Dann läuft die Zugliste
zu Höchstform auf: Sie kennt ja die vergangenen Züge und kann
daher diese am Brett rückgängig machen. Natürlich manipuliert
die Zugliste die Figuren am Brett nicht selbst. Wie kommt sie
denn dazu. Aber die Zugliste kann das Brett anweisen einen
Zug durchzuführen.

Ein Zug: Das ist ein eher abstraktes Gebilde. Es ist eigentlich
nur ein Datencontainer der aus 2 Positionen und einer Figur
besteht. Die Bedeutung soll sein: Figur xy zieht von Feld ab
nach Feld cd.

Position: Wieder ein abstraktes Gebilde. Es speichert
Brettkoordinaten und kann Auskunft darüber geben, ob die
gespeicherte Brettkoordinate gültig ist.

Figur: Eine einfache Auflistung, welche Figuren es gibt. Dazu
kommt noch die Farbe der Figur

Anzeige: Aufgabe der Anzeige ist es, das Brett und die Stellung
der darauf befindlichen Figuren anzuzeigen. Dazu muss man der
Anzeige natürlich das Brett zur Verfügung stellen.

Zugprüfer: Aufgabe des Zugprüfers ist es, abzuklären ob ein
bestimmter Zug in der momentanen Brettsituation möglich und
gültig ist. Dazu braucht der Zugprüfer natürlich den zu
untersuchenden Zug und das Brett (das ja die aktuelle Situation
hält). Daraus folgt natürlich auch, dass es eine Möglichkeit
geben muss, das Brett nach dem Inhalt von bestimmten Feldern
zu befragen.

Bleibt nur noch das Spiel. Seine Aufgabe ist es zb, die
Benutzereingaben entgegenzunehmen, den Zug zusammen mit dem
Brett dem Zugprüfer zu übergeben. Wenn der Zugprüfer sein ok
gibt, dann wird der Zug der Zugliste übergeben, die ihn speichert.
Danach wird besagter Zug dem Brett übergeben, das ihn ausführt
und das geänderte Brett der Anzeige übergeben. Bei speziellen
Eingaben (undo) wird die Zugliste um den letzten Zug befragt,
der Zug auf rückgängig umgeformt und ebenfalls wieder dem
Brett übergeben, dass dan brav den Zug rückgängig macht.

Ha. Da haben wir schon den ersten Designfehler. Wenn ein
Zug ausgeführt wird, dann kann es sein, dass eine Figur
geschlagen wird. Diese Figur verlässt dann das Brett und
taucht nicht mehr auf. Allerdings: Um den Zug rückgängig machen
zu können, ist es daher notwendig, daß die geschlagene Figur
beim Zug, in dem sie geschlagen wurde, zu speichern.

Aber was solls. Fangen wir mal an:

Wir haben ein Brett:

class Brett
{
  public:
    Figur Apply( Zug& zug );
    Figur Piece( Position& pos );
    void  Init();

  protected:
    Figur Inhalt[8][8];
};

Apply führt einen Zug aus und liefert die Figur die gschlagen
wurde, wenn überhaupt.
Piece liefert die Figur, die auf einem Feld steht.
Init hingegen stellt die Figuren zum ersten mal auf.

Also machen wir gleich mal weiter mit einer Position. Das
ist leicht:

class Position
{
  public:
    Position( int z, int s ) : Zeile(z), Spalte(s) {}

    int Zeile;
    int Spalte;

    bool IsValid();
};

An dieser Stelle verlasse ich das Dogma ein klein wenig.
Zeile und Spalte sind public Variablen. Eigentlich möchte
man sowas nicht haben. Allerdings gibt es immer wieder solche
Klassen, die eigentlich eher Datenhaltecharakter haben. Bei
solchen Klassen verlasse ich auch schon mal das Dogma.


To be continued ...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist eine Figur?
Nun eine Figur besteht aus 2 Informationen. Welcher Figurtyp
und welche Farbe die Figur hat.

enum FTyp = { Keine, Bauer, Turm, Laeufer, Springer, Dame, Koenig };
enum FFarbe = { weiss, schwarz };

class Figur
{
  public:
    Figur( FTyp& t, FFarbe& f ) : Typ( t ), Farbe( f ) {}

  FTyp Typ;
  FFarbe Farbe;
};

Damit ergibt sich aber auch sofort, wie ein Zug aussieht:

class Zug
{
  public:
    Zug( const Position& von, const Position& nach,
         Figur& f );

    void WurdeGeschlagen( const Figur& f );

  protected:
    Position Von;
    Position Nach;
    Figur    ZugFigur;
    Figur    Geschlagen;
};

.....
Bitte erspar mir jetzt das weitere tippen. Das geht jetzt
eine ganze Weile so dahin. Jede Klasse hat eine definierte
Aufgabe. Jede Klasse kann sich dabei auch auf andere Klassen
stützen. Zb. Wird die Ausgabefunktion der 'Anzeige' das
Brett Feld für Feld durchgehen und die dort befindlichen
Figuren abfragen. Je nach Figur wird dann die Ausgabe gemacht.
zb. so

void Anzeige::Show( const Brett& Aktuell )
{
  for( int Zeile = 0; Zeile < 8; ++Zeile )
    for( int Spalte = 0; Spalte < 8; ++ Spalte ) {
      ShowFigur( Brett.Piece( Position( Zeile, Spalte ) ) );
    }
    cout << endl;
  }
}

void Anzeige::ShowFigur( const Figur& f )
{
  if( Figur.Typ != Keine ) {
    if( Figur.Farbe == schwarz )
      ShowFigurBlack( f );
    else
      ShowFigurWhite( f );
  }
  else
    cout << " ";
}

void Anzeige::ShowFigurBlack( const Figur& f )
{
  char Symbols[] = " btlsdk";

  cout << Symbols[ f ];
}

void Anzeige::ShowFigurWhite( const Figur& f )
{
  char Symbols[] = " BTLSDK";

  cout << Symbols[ f ];
}

Jede Funktion für sich ist trivial und leicht zu durchschauen.
Und doch bilden sie ein Geflecht, so dass sie in der Spiel
Klasse leicht zu verwenden ist:

class Spiel
{
  ...
  protected:
    Brett      m_Brett;
    Anzeige    m_Anzeige;
    Zugliste   m_Zuege;
    Zugchecker m_Checker;
};

bool Spiel::Do( const Position& von, const Position& nach )
{
  Figur wer = m_Brett.Piece( von );
  Zug* pZug = new Zug( von, nach, wer );

  if( m_Checker.IsValid( pZug ) ) {
    Figur Geschlagen = m_Brett.Apply( pZug );
    pZug->Geschlagen = Geschlagen;
    m_Zuege.Add( pZug );
  }
  else {
    delete pZug;
    return false;
  }

  m_Anzeige.Show( m_Brett );
  return true;
}

Auch diese Funktion ist im Grunde schon selbsterklärend.
Sie ist kurz genug um überschaubar zu bleiben und beim
Durchlesen der Funktion offenbart sich relativ schnell
was diese Funktion macht und wie sie es macht. Wichtig:
Für verschíedene Dinge, macht sich die Funktion nicht
selbst die Hände schmutzig, sondern delegiert. Die Abfrage
welche Figur an der von-Position sitzt, die überlässt
sie dem Brett. Ob ein Zug gültig ist oder nicht, das will
diese Funktion vom Zugprüfer wissen. Diese Funktion führt
auch den Zug nicht selbst aus; das wird wiederum an das
Brett delegiert. Und schliesslich die Anzeige: Die wird
wiederum an das Anzeige Objekt abgetreten. Möchte ich
eine andere Form der Anzeige haben, sei es ein schönes
graphisches Display oder vielleicht überhaupt ein reales
Schachbrett an dem ein Roboter echte Figuren verschiebt:
Dafür zuständig ist das Anzeige Objekt. Das kann ich
jederzeit gegen ein anderes tauschen. Das kümmert zb.
den Zugprüfer oder die Zugliste überhaupt nicht. Daher
kann auch eine Änderung im Anzeigeobjekt die Zugprüfung
nicht beeinflussen bzw. mir dort einen Fehler hineinhauen.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber die Zugliste kann das Brett anweisen einen
> Zug durchzuführen.

Das ist überhaupt auch einer der Knackpunkte in der
Progammierung. Bei jedem Ding, jeder Aktion die durchgeführt
werden soll, muss man sich fragen, ob der Programmteil
(das Modul, das Objekt) überhaupt dafür zuständig ist.
In dem Zusammenhang ist eine 'Beamtenmentalität'
(nicht abwertend gemeint) von Vorteil: "Das fällt
nicht in meinen Aufgabenbereich, dazu gibt es einen
der dafür zuständig ist."

Wenn du also ein Auto simulierst und auf Knopfdruck
soll das Simulierte Seitenfenster aufgehen, so führt
nicht das Auto diese Aktion aus. Das Auto nimmt nur
vom Benutzer den Wunsch entgegen, dass das Fenster
aufgehen soll. Aber es delegiert sofort: Da es sich
um das Fahrerfenster handelt, wird der Wunsch sofort
an das Subobjekt 'Fahrertür', das ein Mitglied des
Autos ist, weitergerecht. Auch die Tür veranlasst nicht
direkt, dass sich der Servomotor in Bewegung setzt.
Die Tür delegiert sofort an das Subsystem 'Fenster',
welches wiederrum diesen Wunsch an den Servomotor
weiterreicht, der dann endlich, je nach Öffnen oder
Schliessen entscheidet in welche Richtung er sich drhen
soll und ob die Endlage schon erreicht ist.

Was sich auch bewährt hat ist, die einzelnen Objekte
als 'kleine Mitarbeiter' anzusehen und dementsprechend
sind Funktionsaufrufe einfach Befehle an diese Objekte
etwas zu tun. Das ist wie bei der Bundeswehr: Der
Garnisonskommandant wendet sich an seinen Kompaniekommandaten,
dass der Müllplatz gereinigt werden muss. Der Kompaniekommandant
gibt diesen Befehl weiter an seinen Spiess: "Um 9 Uhr
ist der Müllplatz zu reinigen". Der beauftragt
seinen Schreiber das dazu nötige Werkzeug zu organsisieren.
Mit diesem Werkzeug wartet der Spiess bis 8.45 Uhr und sucht
sich dann vielleicht einen Zugskommandanten heraus, desen Zug
die Aktion durchführen soll. Dem übergibt er das Werkzeug und
den Befehl die Reinigung mit diesem Werkzeug durchzuführen. Der
Zugskommandant seinerseits macht das natürlich nicht selbst,
sondern holt sich wiederrum einen armen Teufel, der den Befehl
erhält: Mit diesem Besen ist sofort der Müllplatz zu reinigen.
Und erst der führt dann die eigentliche Aktion durch.
In jeder Hierarchiestufe, die der Befehl von oben bis unten
durchläuft, sind zusätzliche Informationen hinzu oder auch
weggekommen. Der arme Teufel muss ein Uhr nicht ablesen können.
Das Timing ist schon ein paar Ebenen weiter oben gemacht worden.
Dafür hat sich der Garnisonskommandant nicht darum zu kümmern
mit welchem Werkzeug der Befehl umgesetzt wird, das weiss
wiederrum der Spiess-Schreiber.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passt, wie ich finde, zum Thema und interessiert vielleicht den Einen 
oder Anderen:
http://se-radio.net/

@oimelx
> Häufig ist es jedoch trotzdem so, dass sich Anforderungen während der
> Programmierung, oder nach Fertigstellung ändern. Gerade im Bereich der
> kaufmännischen Software ist dies "normal".

Das "kaufmännisch" ist da über, das kannst Du streichen. ;-))

Autor: Tobi O. (der_ossi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kbucheg:

toll beschrieben... solltest vllt. ein Wiki dafuer hier auf der Seite 
eroeffnen

ich hab mir das nicht alles durchgelesen... Aber die Frage mit dem "Wie 
teste ich das am besten" laesst sich ganz einfach mit dem neumodischen 
Begriff "extreme programming" beantworten. Dazu gibt es einige wikis. 
Sinn der ganzen Sache ist es fuer alles eine Testklasse zu schreiben ;)

Autor: Ingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei all euren sicherlich gut gemeinten Bespielen solltet ihr verstärkt 
darauf achten, nicht einfach das Beispiel den Erfordernissen der 
Explikation anzupassen, da iehr sonst Gefahr lauft, in komplett bizarren 
Szenrarien zu versinken:

Das Auto mag vielleicht noch die übergeordnete Struktur für Fenster und 
Fensterheber darstellen und "Wünsche des Fahrers" entgegen nehmen, aber 
was soll man mit einem Beipiel anfangen, bei dem das Fenste Wünsche an 
den Heber weiterleitet? Das sehe ich z.B. genau umgekehrt: Der Heber ist 
die höhere Ordnung gegenüber der Scheibe - umfassende Struktur wäre die 
Türe!
Wunschweiterleiter wäre auch nicht das Auto, sondern die 
Boardelektronik. Wenn, dann bitte sinniger.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn, dann bitte sinniger.

Der springende Punkt ist: Eine Objekthierarchie macht in einem
bestimmten Kontext Sinn. In einem anderen mag sie komplett
sinnlos sein. Dementsprechend gibt es kein "one size fits
all" Lösung.
Wenn es für deine Simulation Sinn macht, die Elektrik mitzu-
simulieren, dann sei es so. Für meine Simulation, die ich im
Kopf hatte, machte es keinen Sinn, also lies ich sie weg.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> class Brett
> {
>   public:
>     Figur Apply( Zug& zug );
>     Figur Piece( Position& pos );
>     void  Init();
>
>   protected:
>     Figur Inhalt[8][8];
> };

Also Du hast ein 8 mal 8 Array mit Figuren, wobei eine Figur auch vom 
Typ "keine" sein kann. Das finde ich jetzt interessant, weil ich das 
anders gemacht hätte. Ich hätte gesagt dass eine Figur eine Position 
hat. Und im Brett hätte ich eine "std::list<Figur> Figuren;" deklariert.

Vielleicht laufe ich, mit dieser Liste, in eine Sackgasse. Kannst Du mir 
sagen was die Vor- und Nachteile dieser beiden Möglichkeiten ist?

Gruß, Feadi

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War mehr so eine Bauchentscheidung.
Bei der gewählten Aufgabenstellung ist das rechenintensivste
sicherlich das Abklären ob ein Zug überhaupt möglich ist.
Dazu müssen aber ständig Linien und Diagonalen am Brett
abgeklärt werden. Daher möchte ich eine einfache Möglichkeit
haben, dies auch zu tun. Und etwas einfacheres als das Spielfeld
im Rechner durch ein 2D Array abzubilden, ist mir auf die Schnelle
nicht eingefallen :-) (*)
Würde man das mit einer Figurenliste machen, müsste man für
jede Position jedesmal die Liste abklappern, ob es für eine
gegebene Position eine Figur an dieser Position gibt. Im
Vergleich dazu ist das ständige updaten der Matrix ein
verschwindendes Problem.

Die Fragestellung die in diesem Pgm die häufigere sein
wird ist doch: An einer bestimmten Position: steht da eine
Figur und wenn ja, welche?
Die Frage, die deine Liste besser beantworten könnte, würde
lauten: Wo steht eine bestimmte Figur?
Nur, diese Fragestellung kommt in der gewählten Aufgabenstellung
nicht vor.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Aber die Zugliste kann das Brett anweisen einen
>> Zug durchzuführen.

> Das ist überhaupt auch einer der Knackpunkte in der
> Progammierung. Bei jedem Ding, jeder Aktion die durchgeführt
> werden soll, muss man sich fragen, ob der Programmteil
> (das Modul, das Objekt) überhaupt dafür zuständig ist.
> In dem Zusammenhang ist eine 'Beamtenmentalität'
> (nicht abwertend gemeint) von Vorteil: "Das fällt
> nicht in meinen Aufgabenbereich, dazu gibt es einen
> der dafür zuständig ist."

Dazu vielleicht noch ein bischen 'Geheimdienstmentalität'? Also: "Wer 
muss das wissen?", "Wer braucht das nicht wissen?".

Da fällt mir ein: Wenn ich sagen eine Figur hat eine Position, dann 
kennt die Figur ihre Position, aber ich glaube sie braucht das garnicht. 
Man könnte also sagen: Das Brett muss wissen wo welche Figur steht.

Ich glaube diese Überlegungen gehen in die richtige Richtung, oder?

Gruß, Feadi

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich glaube diese Überlegungen gehen in die richtige Richtung, oder?

Absolut.

> Da fällt mir ein: Wenn ich sagen eine Figur hat eine Position, dann
> kennt die Figur ihre Position, aber ich glaube sie braucht das garnicht.
> Man könnte also sagen: Das Brett muss wissen wo welche Figur steht.

Grundsätzlich richtig.
Das nenne ich mal das 'Datenbank-Prinzip': Speichere
jede Information nur einmal.

Allerdings wird dieses Prinzip zähneknirschend auch schon
mal über Bord geworfen. Denn die Frage die sich als nächstes
stellt, ist: Wie lange dauert es, bis das Brett eine bestimmte
Figur auf dem Brett gefunden hat(*). Sieh also die Positionsangabe
bei einer Figur als eine Art Cache an. Ja, ja, ich weiss
schon: preamture optimization is the root of all evil :-)


(*) Ist in der gewählten Aufgabenstellung sicherlich kein
Thema. Aber eine schöne Begründung.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir helfen solche Sätze wie dieser hier sehr viel:
> 'Datenbank-Prinzip': Speichere jede Information nur einmal.
Ich fände es sehr schön, würden davon noch einige zusammenkommen.

Noch eine Frage: Wie macht man das Interface am besten, wenn ein Objekt 
ein Ereigniss erzeugt, und ein anderes Objekt dieses Ereigniss behandeln 
soll?

Ich kenne z.B. das hier:
class maschine
{
 public:
  class handler
  {
   public:
    virtual void ereigniss() = 0;
  };

 private:
  handler *h;

 public:
  void registerHandler( handler *x )
  {
    h = x;
  }

  void erzeugeEreigniss()
  {
    h->ereigniss();
  }
};

class EreignissSenke : public maschine::handler
{
 public:
  void ereigniss()
  {
    // mach etwas...
  }
};

Aber da muss es doch was besseres geben, oder?

Gruß, Feadi

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber da muss es doch was besseres geben, oder?

Wenn ich da mal so schnell drüber schaue, dann ist
das doch das 'Observer Pattern'. In einer etwas
vereinfachten Form. Ein volles Observer-Pattern
würde beliebig viele Beobachter zulassen, aber
darum geht es nicht. Die Grundprinzipien eines
Observers sind alle da.

Was besseres: Nein, das wird tatsächlich so gemacht.
OK. Man könnte mit Basisklassen etwas auslagern, aber
hey: der Observer den du da hast, der ist doch noch
nicht kompliziert.

Wenn dich solche Dinge interessieren, dann empfehle
ich dir:

Design Patterns
Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Das Buch ist auch bekannt als "Gang of 4" oder kurz der "Go4".

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe sehr lange überlegt, bis ich diesen Code da oben hatte. Hätte 
ich gewusst dass es ein Buch über sowas gibt... ;)

Das Buch werde ich mir sofort kaufen, vielen Dank für den Tip.

Gruß, Feadi

Autor: ITler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also allgemein ist das IT-Management leider nicht in der Lage 
grundsätzliche Management Prinzipien umzusetzen (warum auch immer), als 
da wären:
http://de.wikipedia.org/wiki/Lastenheft
und daraus abgeleitet dann:
http://de.wikipedia.org/wiki/Pflichtenheft
Egal was für ein Projekt ansteht, es müssen vor allem auch Termine und 
Prüfkriterien definiert und eingehalten werden.
Das ganze Thema hat nichts mit Programmierung oder Software-Design zu 
tun, sondern ausschließlcih mit Management.
Das wird leider grundsätzlich übersehen :(
Nehmne wir als Beispiel ein Verwaltungsprogramm für eine große 
Bibliothek.
Das erstes was gemacht werden muß ist nicht mal schnell einen Prototypen 
in C++ zu entwickeln, sondern ganz im Gegenteil zu sehen wer wird später 
das System pflegen müssen und wie ist die aktuelle Arbeitsweise.
Es nützt schließlich nix, wenn zwar eine superperformante parallel und 
objektorientierte Software in "Schlagmichtot" programmiert wurde, wenn 
die Personen die später damit umgehen müssen außen vor bleiben.
Statt dessen ist es immer effizienter, die vorhandenen Strukturen zu 
analysieren und entsprechend nachzubauen.
Dann verringert sich die Einarbeitungszeit der Leute die es benutzen 
müssen und wenn man intelligenterweise eine Abstraktionsebene einbaut, 
läßt sich das schnell ändern ;)
Für die Verwaltung von größeren Software-Projekten hat sich CVS bewährt, 
eine Verwaltungssoftware, die Änderungen im Code verwaltet und pflegt.
Wenn mehrere Leute an einem Projekt arbeiten ist es zudem sehr sinnvoll, 
jeder Person einen einzigen Part des Gesamtprojekts zuzuorden inklusive 
einem weiteren Part als Ersatz/Helfer.
Z.B. eine Resource bearbeitet die Bedienoberfläche und ist gleichzeitig 
in die Schnittstelle zwischen Oberfläche und eigentlicher 
Bibliotheksverwaltung involviert.
Eine andere Person übernimmt das Design der Datenbank für die Bibliothek 
und ist gleichzeitig in die Schnittstelle zwischen Verwaltungsprogramm 
und Datenbank involviert.
usw. usw. usw.
Vor allem muß immer darauf geachtet werden, das das Projekt passende 
Granularitäten aufweist, um klare Bezüge abgrenzen zu können.
Das gilt sowohl für das Programm selbst, als auch für die Personen die 
es umsetzen.
Ich hoffe mal es richtig erklärt zu haben ;)

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"divide and conquer"

:-)

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist  das für eine Software an der man 20 Jahre Arbeitet.
Wie heißt die?

Autor: tastendrücker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was ist  das für eine Software an der man 20 Jahre Arbeitet.
> Wie heißt die?

...aktuell: "Vista"

SCNR

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neugier wrote:
> Was ist  das für eine Software an der man 20 Jahre Arbeitet.
> Wie heißt die?

Die kriegst du so nicht zu kaufen:-)

Es geht um einen Bereich, der sich 'Innenraum-Visualisierung'
nennt. Los geht es mit der ganz einfachen Fragestellung:
Wenn ich meinen Raum so und so einrichte, wie sieht nachher
das Ergebnis aus. Also das was du auch von diversen, zur
Zeit im Fernsehen in Mode gekommenen Heimwerkershows,
kennst.
Aber das Ganze geht ja dann weiter. Eine der Gretchenfragen
lautet ja: Was kostet mich der ganze Spass? Eine andere:
Wo kriege ich aktuelle firmenspezifische Daten her?
Eine ganz andere Fragestellung lautet: Wenn ich komplizierte
Teile aufbauen muss, muss ich dann wirklich alles ganz von
alleine machen, oder kann mir der Rechner nicht dabei
helfen. Ich zeige ihm wo mein WC und mein Waschbecken hin
soll, und er konstruiert das Vorwand-Tragwerk ganz von alleine.
Und zwar so, dass alles hält und ich trotzdem noch die richtige
Neigung beim Fäkalrohr in der Wand habe. Dann hätte ich davon
ganz gerne eine komplette Stückliste bis runter zur letzten
Schraube und wenn der Rechner für den Monteur vor Ort noch
ganz alleine eine Montageanleitung generieren könnte, wärs
auch nicht schlecht.
Oder: Ich möchte in meinen Innenraum eine Heizung einbauen.
Welche Heizkörper brauche ich, wie sehen die Heizkreisläufe
aus? Reicht die Heizleistung? Welche Teile muss ich in der
Zentrale bestellen? Sind die lieferbar?
Oder: In einer Produktionshalle liegen die Versorgungsstränge
für Wasser, gas etc. normalerweise an der Decke. Die sind dort
an Konsolen montiert. Nur: Wie müssen diese Konsolen dimensioniert
werden? In welchen Manschetten muss ich die Rohre führen, so dass
die Ausdehnung auch abgefangen werden kann? Am liebsten wäre
mir, ich zeige dem Rechner nur wie ich die Konsole an die Wand
schrauben möchte, wie mein Rohrbündel aussieht und um die ganze
Befestigungstechnik, so dass das Zeugs nicht runter kommt und
die Manschetten auch alle halten, soll sich der Rechner kümmern.
Ach ja: Das Ganze soll natürlich voll parametriesiert sein, denn
für Ergänzungen im Konsolen, Schrauben, Träger, Manschettensortiment
will ich nicht immer den Entwickler benötigen.

Und, und, und.
Das Grundkonzept ist: Lego spielen im Rechner. Aus vorgefertigten
3D-Bausteinen (sagte ich schon, dass wir uns im 3D bewegen?)
wird eine Szenerie zusammengestellt. Jetzt kann man
eine Menge Spezialfunktionalität im Bereich Konstruktion
unterbringen. Man kann aber auch eine Menge Spezialfunktionalität
hinten dran setzen um spezeille Auswertungen zu fahren.

Und das Ganze nach Möglichkeit so, dass auch Lieschen Müller
mit der Software zurechtkommt.

Und so gehen die Jahre ins Land.

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind in eurer Anwendung auch Bibliotheksmodule
Oder ist alles aus euer Entwicklung.
Ich denke da so an Daten-Schnittstellen usw.
Ich meine Ihr bewegt euch im Cadbereich und müsst wahrscheinlich 
Modellierwerkzeuge zur Verfügung stellen . Verwendet ihr auch sogenannte 
Cadkernel wie Parasolid oder andere?

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das meiste ist von uns.

Modellierwerkzeuge haben wir vor einiger Zeit aufgegeben.
Das lohnt nicht mehr. SolidEdge kannst du auch mit der
besten Entwicklungsmannschaft preislich nicht schlagen.

Geometriekern ist von mir (war von mir. Ich bin vor einem
Jahr aus der Truppe ausgestiegen :-)

Dementsprechend sind auch die Kern-Fileformate alle von uns.
Der notwendigen Geometrie Import anderer Formate,
wird dir dann sowieso vom Markt aufgezwungen.

http://www.gascad.at

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaum vorstellbar das da 1.8 Millionen Zeilen drinn stecken sollen.
Ich habe eine Software geschrieben mit über 100000 Zeilen,
auch im 3D Cadbereich (mit komplizierten Algorithmen).
Hat 3 Jahre gedauert.
Allerdings bin ich kein Objekt-Programmierer. Ich nutzte alles 
durcheinander von c bis c++.
Standards oder ändere nette Sachen interessieren mich nicht.
Ich dokumentiere meinen Programmcode nicht mal, keine Kommentare, 
nichts.

Meine Arbeitsweise ist zugegebenermaßen sehr eigenwillig und auch nicht 
Teamfähig, da Niemand anders außer mir den Code wegen fehlender 
Dokumentation entschlüsseln kann.
Ich nutzte auch kaum Test-Funktionen oder ähnliches.
Trotzdem läuft meine Applikation absturzfrei.
Das Einzige was ich konsequent durchziehe  ist: das ich Pointer immer 
mit Null initialisiere und wann immer ich sie benutze auf Null teste, 
sofern es notwendig erscheint.
Für den Außenstehende mag das alles wie Kaos aussehen, aber jeder Mensch 
programmiert so wie er denkt. Die Masse der Menschen brauchen die 
Objektorientierung um sich zurecht zu finden. Bei mir ist das genau 
umgekehrt. Was nicht heiß das ich Sie nicht nutze  wenn es Sinn macht.
Natürlich mache ich mir auch über die Programmstruktur Gedanken  und 
weiß oft auch am Anfang ziemlich genau wie es sein muss.
Meine persönliche Meinung ist , wenn ich  konsequente Objektorientierung 
anwenden würde, wäre ich mindestens um den Faktor 2 langsamer. Ich hätte 
statt 3   6 Jahre gebraucht.
Meine Kunden bekommen eine Anwendung die nicht schlechter und nicht 
besser ist wie eine Anwendung die konsequent mit Objektorientierung 
geschrieben ist.





Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wenn ich  konsequente Objektorientierung
> anwenden würde, wäre ich mindestens um den Faktor 2 langsamer

Das halt ich, mit Verlaub, für ein Gerücht.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohje, Code ohne Kommentar. Der Tot für jedes Projekt!

Wenn mir jemand solche Software abliefert, wird sie aus Prinzip nicht 
abgenommen. Denn Was Passiert wenn Du ausfällst? Dann hätte ich Code den 
niemand weiter pflegen kann. Das bedeutet alles neu schreiben.
Nein Danke!



Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das halt ich, mit Verlaub, für ein Gerücht."

Das kann jeder halten wie er will, aber ich bin jedenfalls schon fertig 
wenn du noch deine Klassenstruktur planst. Objektorientierung ist für 
Rapidentwicklung nicht zu gebrauchen.
Ein Fehler in der Anfangs-Planung und man muss alles umbauen.
Objektorientierung wende ich da an wo es wirklich Sinn macht.
Sonst kommt C-Stile zum Einsatz. Besonders bei zeitkritischen Funktionen 
verwende ich keine Objektorientierung.
Man sagt „Objektorientierung ist unbedingt notwendig bei größeren 
Projekten“, das ist quatsch.
Früher wurden auch große Projekte bewältig  z.B. noch mit Assembler.
Mann sollte sich nicht zu sehr an Schemata binden wenn man vorankommen 
will. Das ist eigentlich meine Kernaussage.




"Wenn mir jemand solche Software abliefert, wird sie aus Prinzip nicht
abgenommen. Denn Was Passiert wenn Du ausfällst?"


Ja, ich sagte ja das ist kein Teamprojekt .Wenn ich ausfalle gibt auch 
die Software nicht mehr.
Der Code wird auch nicht ausgeliefert . Der Kunde bekommt nur das 
Endprodukt .
Ich behaupte mal das ich damit aber um den Faktor 3 schneller entwickle.
Der Umstand das mein Code keine Kommentare hat bringt noch andere 
Vorteile mit sich.
Das ist wie mit den Merkzettel, wenn man sich die Notiz aufgeschrieben 
hat, darf man sie vergessen.  Ich bin daher gezwungen das Gedächniss ein 
wenig zu schulen.Wenn ich wissen will, was mein Code macht, muss ich mir 
das merken oder eben die Abläufe entschlüsseln.
Insgesamt finde ich mich dadurch aber schneller zurecht. Man weiß sehr 
genau wo im Code sich was befindet und man merkt sich mit der Zeit auch 
die Funktionsweise der einzelnen Abläufe und Algorithmen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiss.
Ich dachte auch einmal, ich wäre der Grösste, weil
ich ich die 30 oder 40-tausend Codezeilen auswendig
konnte und von jedem beliebigen 5 Zeilen Fragement
genau sagen konnte wo es herkommt und was es dort bewirkt.

Da muessen wir alle durch :-)

Irgendwann begreift es jeder, dass das Teure an
Software weniger die Erstentwicklung ist, sondern
die laufenden Änderungen und Ergänzungen und Änderungen
die aufgrund von Ergänzungen notwendig sind.

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meinte aber nicht nur 40.000 ich meinte 100.000. Ich habe deinen 
Werdegang längst hinter mir .
Bei mir geht Wartung,Ergänzungen  überraschend schnell. Ist zumindest 
die Meinung meiner Kunden. Und teuer ist das bei mir schon gar nicht 
(weil das kostet mich keine Zeit).

Autor: Grünbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur 100.000? Also ich habe 3 größere Programme mit je. 250.000 Zeilen 
unkommentiert geschrieben und alles im Kopf.
Das machen meine Kollegen auch so, mit 100.000 brauchst du hier gar 
nicht anfangen

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na also, geht doch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neugier wrote:
> Ich habe deinen Werdegang längst hinter mir .

Guter Witz.
Es ist wohl eher so, dass ich das fröhliche Draufloshacken
schon längst aufgegeben habe. Für meine eigenen, privaten
Dinge, macht es noch Spass einfach draufloszutippen.
Im Büro herrschen allerdings andere Prioritäten.
Dumme Fehler, die beim Testen unentdeckt bleiben sind
einfach zu teuer, wenn sie erst mal an die Endkunden
ausgeliefert sind.

Ausserdem: Wer sagt, dass sich Rapid Prototyping und OO
beissen? Ganz im Gegenteil: OO ist ein hervorragendes
Werkzeug um damit Rapid Protoyping zu betreiben. Das
ist ja gerade der Witz an der Sache, dass die Klassenstruktur
nicht von vorne herein 100% richtig sein muss. Du brauchst
nur eine Arbeitsversion und genauso wie du im Lauf der Zeit
draufkommst, ob deine struct vernünftig sind, so stellt sich
auch bei OO im Lauf der Zeit heraus, ob die Klassenstruktur
vernünftig ist oder nicht. Ist man allerdings nur ein klein
wenig diszipliniert an die Sache rangegangen, so ist es ein
leichtes die Klassenstruktur zu ändern ohne dass gleich alles
zusammenbricht. Ein wesentlicher Vorteil: Man akzeptiert so
wesentlich seltener Krücken, nur weil man sonst quer durch den
Code eine Änderung durchziehen müsste. Bei OO ist die Änderung
eher in einem kleinen Codeteil gekapselt.

Autor: e^x Man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein derzeitiges Projekt (3er Team):
-zur Zeit 2 Mio Zeilen
-Programmiersprache ist Java
-zur Planung komme ich noch
-Der Zeitplan wird (bisher) eingehalten

Planung: Es wurde definiert, was rauskommen soll. Dann wurde die 
Architektur definiert und gebaut (ein Transaktionsframework, ein 
Eventframework, Hibernate gabs zum Glück schon :-)). Dann wurden das 
Ergebnis der Analyse in UML-Diagrammen festgehalten, und das Design 
wurde hinzugefügt. Das Ganze dann mit Hilfe eines Generators in 
Quellcode transformiert. Diesen Quellcode erweitert, Generator 
angepasst, Design angepasst. Zur Zeit funktioniert das schon gut.

Offiziell sind wir ein agiles Team, d.h. wir bauen alle 3 Wochen einen 
funktionierenden Prototypen und zeigen den den Anwendern. Die 
Änderungswünsche werden dann beim nächsten Prototypen berücksichtigt.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Buch ist angekommen. Es macht einen sehr guten Eindruck, vorallem 
Kapitel 2 weckt Interesse: "A Case Study: Designing a Document Editor".

Gruß, Feadi

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe in python standalone application geschrieben
mit sehr bescheidenen 3000 loc
da allerdings abstraktionsgrad sehr viel höher als in C++
und noch viel höher als in C ist, kann man ziemlich viel
an logik da reinpacken und entsprechend auch verwalten.

ich finde grade python für prototyping ideal um die idee
auszutesten, grundzüge eines algorithmuses ausprobieren etc
man kann danach nicht die arhitektur 1 zu 1 übernehmen,
weil nun mal OO sich unterscheidet, aber dafür plage ich
mich erstmal nicht mit container, mit new/delete, mit regex und das
entscheidende ist ... wenn man erkennt das die struktur so
nicht ganz richtig ist .. wenn man information die ein objekt
trägt woanders verlagern will, dann ist das meist in 10 zeilen
gemacht

ich hab die erfahrung gemacht, dass die logische struktur
vom programm in C und C++ gut zum ausdruck gebracht werden kann,
aber das lästige kleinkram wie stringoperationen, umkonvertierungen,
regex viel zu viel raum beanspruchen und logische struktur
letztendlich begraben können
wenn man aber soweit ein funktionieredes konzept hat
wird man besser zurecht kommen

@neugier
mir kann keiner erzählen dass dein adhoc programmiertes kode
so leicht erweiterbar ist wie du es schilderst
es würde ja voraussetzen, dass du alle zukünftigen änderungen
kennst und in der einen oder anderen form darauf hinprogrammierst
es kann viel zu schnell passieren, dass eine änderung dein
ganzes konzept durcheinanderwirft
das ist so wie mit algorithmen .. eine kleine nebenbedingung weglassen
und schon haben wir NP schweres problem

grüsse

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Pythonprogrammierer,
Mein Programm wird ständig erweitert .Probleme gibt es keine.
Aber wenn du dir nichts erzählen lässt, dann mache ich das auch nicht.

Wobei, für mich ist Pyhton-proggen  bestenfalls "Rumscripten für 
Anfänger"  .Als "Programmieren" bezeichne ich das nicht.


Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wobei, für mich ist Pyhton-proggen  bestenfalls "Rumscripten für
> Anfänger"  .Als "Programmieren" bezeichne ich das nicht.

Ach, da lachen ja die Hühner. Kannst du das vielleicht näher begründen ?

Autor: Thomas B. (yahp) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach spring doch nicht drauf an. Lass ihn einfach. Wer von sich denkt, 
dass er der Größte ist, weil er hunderttausend LOC im Kopf hat und 
deswegen nicht kommentiert, dessen Horizont hört einfach am eigenen 
Tellerrand auf. Wer nicht soweit denkt, dass morgen jemand anderes auf 
diesen Code starren können müsste, wird früher oder später eine 
Bauchlandung machen. Garantiert.

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber schau doch, ich bin nicht der Einziege der das so macht.
Und ob ich früher oder später eine "Bauchlandung" mache, dass bleibt
wohl ein Wusch deiner Phantasie.

Wenn du zu denen gehörst,die ihre 3 Zeilen
Pythoncode dokumentieren müssen, dann kannst du das eh nicht verstehen.

Autor: Thomas B. (yahp) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht ja auch nicht gegen dich und die Probleme wirst auch 
nachweislich nicht du bekommen, sondern ein potentieller Nachfolger, 
denen es einen Heidenspass machen wird durch deinen Code zu wühlen. 
Insofern war meine obige Behauptung natürlich Quatsch. Dein 
Arbeit-/Auftraggeber wird damit langfristig besondere Freude habe oder 
willst du dich unabdingbar machen. Auch ein Plan, muss man sagen.

Mach was du willst. Ich würde mich bei deinen Programmen aber einigen 
der Vorredner anschliessen und diese kategorisch ablehnen.

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Neugier

warum wehrst du dich denn so verzweifelt gegen Struktur und 
Dokumentation?

Schlussendlich klingt bei deiner Argumentation für mich da nur durch, 
daß du ein heilloser Chaot bist, der sich irgendwie durchs (Programmier) 
Leben wurschtelt.

In der Selbstbetrachtung (Selbsteinschätzung) sehen Dinge immer besser 
aus als in der Fremdbetrachtung. Deine Argumente klingen ähnlich wie die 
von (alkohol-, nikotin-, ess-, drogen-) süchtigen, die haben auch alle 
möglichen schadenfeinigen Gründe bei Hand, zu erklären, warum ihr 
Verhalten "doch gar nicht so schlimm ist". Sie erkennen es einfach 
nicht, weil sie in ihrem eigenen Erfahrungshorizont gefangen sind und da 
ähnlich wie aus einem schwarzen Loch aus dem Ereignisshorizont und ihren 
gewohnten Verhaltensweisen gar nicht heraus kommen (wollen).

Manchmal ist der Weg das Ziel. Oder um es hier auf Programmiererei 
abzubilden: Der Algorithmus (die Grundidee) (d)eines Programms steckt in 
der Dokumentation und Verfahrensbeschreibung, und nicht im "if" oder 
"brnz" Statement.

Autor: ITler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hat ja Ausmaße angenommen lol
Also jede "gute" Programmiersprache bietet passende Strukturen für 
Fehlerbehandlung und wenn's ein ASSERT Skript ist !
In JAVA und C++ sind die Exceptions zu bevorzugen, die dann jeweils mit 
dem gutem try ausprobiert werden.
In "gewachsenen" Programmen muß man leider zu unschönen Mitteln wir 
explizite Abfragen vor jeder Änderung greifen :(
Also z.B.
int irgendeinevariable; // steht irgendwo in irgend einem Header

void tuewas(int eingabevariable)
{
 if(eingabevariable == NULL || irgendeinevariable == NULL)
  return;
 
 // Rechne irgendwas mit den Vars aus 

}
Der Vorteil von objektorientierter Programmierung liegt in der einfachen 
Erweiterbarkeit des bereits laufenden Codes, denn ich muß ja nicht's 
umschreiben, sondern kann einfach das Objekt erben und erweitern.
Auch was Threadprogrammierung betrifft haben einzelne Objekte gewisse 
Vorteile gegenüber z.B. C-Funktionen.
Und eine ordentliche Dokumentation sollte von Anfang an in der Planung 
mit drin sein !
Damit sind nicht nur sinnvolle Namensgebungen innerhalb des Programms 
und erklärende Kommentare gemeint, sondern eine komplette Beschreibung 
außerhalb des Programmkontextes.
Eben ein Pflichtenheft, welches aus dem Lastenheft hervorgehen sollte.
JAVA bietet was die Dokumentation und verknüpfung des Source-Codes 
angeht ein mächtiges Werkzeug.
Allerdings macht eine Übersicht der einzelnen Objekte mit Funkitonen und 
Abhängigkeiten eine erklärende Dokumentation, die auch für 
NICHT-Programmierer lesbar und verstehbar ist NICHT unnötig !
Das verstehen die meisten Leute in der IT-Planung und vor allem die 
Programmierer nicht.
Ein von Anfang an gut durchgeplantes Softwareprojekt hat schon 
Schnittstellendefinitionen und Ausstiegspunkte definiert, bevor die 
erste Zeile Programm geschrieben wurde.
Quickhacks neigen dazu schnell unübersichtlich zu werden und enden dann 
in Frickelwerk, das niemand mehr wirklich verstehen kann und wo sich 
unbemerkt Race-Conditions oder schlimmeres einschleichen, die dann Dinge 
bewirken die sich niemand erklären kann !
Das habe ich gerade bei meinem kleinen Hobbyprojekt bemerkt, das ich 
einfach inne Tonne trete und mit Planung von vorne anfangen werde !
Das hat klein angefangen und wurde dann kontinuierlich erweitert, bis es 
irgendwann einfach geklemmt hat und ich beim besten Willen nicht 
feststellen konnte wo und warum :(
Und was Skriptsprachen angeht, so sind die den compilierten Sprachen 
kaum "unterlegen" !
Gutes Beispiel ist PHP ;)
Damit läßt sich sogar objektorientiert arbeiten und es wird weltweit 
auch bei First-TIERs eingesetzt ;)
Mein Grundtenor bleibt in diesem Bereich aber immer der selbe:
- Gutes IT-Management muß vorhanden sein !

Autor: Neugier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah Wegstaben Verbuchsler,

du bist hier ja der Schnacker vom Dienst. Solche Lokus-Weißheiten  habe 
ich ja noch nie gehört. Ich wette du studierst gerade das Buch „c++ für 
dummies“ und verkündest jetzt deine angelesenen  Weißheiten.






Hallo ITler (Gast)
"Programmierst du schon? oder planst du noch?"

Planung mach ich nicht zweimal und das ich ein ganzes Projekt
verwerfen muss passiert mit heute nicht mehr.

Klar kann man das auch  wissenschaftlich aufziehen mit tausend 
Dokumentationen und Pflichtenheften, vielleicht auch noch ein Buch 
schreiben und dabei in der Nase popeln . Am Ende hast du dann aber nur 3 
Zeilen Code fertig und deine schöne Sourcecode Dokumentaion kauft dir 
dein Kunde nicht ab. Das kannst du mir schon glauben, die braucht und 
bezahlt kein Mensch.



Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Neugier

jaja, die Wahrheit tut weh und wird nicht gerne eingesehen. Welche 
meiner Sprüche hat dich persönlich am meisten betroffen gemacht, weil du 
dich darin wieder gefunden hast?

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Neugier

um auf deine Frage zu kommen was ich so grade mache:

Nö, ich lese kein c++ Buch. Ich arbeite (seit 10 Jahren) in der 
Qualitätssicherung, typischerweise Telekommunikationsunternehmen, und 
bin als Testleiter für die Einführung und Weiterentwicklung von 
Programmpaketen mit mehreren Mio Codezeilen in ziemlich verwegenen 
heterogenen Umgebungen verantwortlich. Das sind teilweise angepasste 
Standardpakete wie Bsp SAP (ca. 70% Basisfunktion, ca. 30% 
kundenspezifisch), und teilweise komplett kundenspezifische 
Anwendungspakete. Als Programmiersprachen wird alels mögliche verwendet, 
aber das ist ziemlich "egal" in welcher Sprache was geschrieben ist, 
sofern es dokumentiert ist.

Solche komplexen Anforderungen lassen sich naturgemäß ausschließlich 
über strukturierte Vorgehensweisen abbilden. da ist tatsächlich 1 Zeile 
"Doku" (*1) wesentlich mehr wert als 1 Zeile Code. Tatsächlich ist das 
Verhältnis deutlich "Doku-Lastig"

(*1) Doku ist alles außer Code wie z.B. Lastenhefte, Pflichtenhefte, 
Benutzerhandbücher, Schnittstellen- und Modulspezifikation etc.



Für kleine (und auch möglicherweise große) Frickelsprojekte für einen 
Einzelkämpfer wie dich mag das befremdlich klingen, daßauf 1 Zeile Code 
10  Zeilen Doku kommen, aber es ist in einer derartigen Umgebung das 
einzig mögliche, um noch irgendwie in dem alltäglichen Wahnsinn der 
Steuerung von hunderten Programmierern wie dich einigermaßen zurecht zu 
kommen.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Neugier:

> ... und das ich ein ganzes Projekt verwerfen muss
> passiert mit heute nicht mehr.

Hört sich an als hättest Du aus Erfahrung gelert. Bitte verrate die 
Details warum Du früher ganze Projekte verwerfen musstest? Und warum 
heute nicht mehr?

Wie strukturierst Du Deine Programme? Kannst Du ein paar Beispiele 
geben, bitte?

Gruß, Feadi

Autor: poeschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr wollt doch jetzt nicht aufhören? :-)
Das ist wirklich ein sehr interessanter Thread. Zuerst fragt Feadi eine 
ziemlich naive Frage (nicht böse gemeint), deren Antwort eigentlich ein 
Studium füllt! Aber es finden sich Leute, die mit unglaublicher Geduld 
die Kunst des Softwareentwurfs schildern. Und dann prallen auch noch die 
"Frikler" auf die "Planer".

Also muss ich auch noch meine Meinung anbringen:

@neugier: Du hast völlig recht. Die ganze Plaung und Doku zahlt kein 
Kunde. Allerdings klappt das nur in deinem speziellen Fall! Wenn du 
andere Software einbinden, deine Software exportieren müsstest, noch ein 
paar Kollegen oder einen Chef, der das Produkt unabhängig von dir 
verkaufen will, hättest, würde dein Ansatz nicht funktionieren!

@Wegstaben Verbuchsler: Dein Ansatz ist natürlich generell richtiger. 
Aber ist es nicht so, dass deine verwegenen, heterogenen Umgebungen nur 
so chaotisch sind, weil früher schlecht geplant wurde bzw. ein Kunde die 
Planung nicht bezahlten wollte bzw. ein Chef eine falsche Entscheidung 
getroffen hat?

Ihr habt also beide eigentlich das gleiche Problem :-)

@feadi: Softwareentwicklung ist eigentlich eine Kunst. Natürlich kann 
jeder programmieren...aber Bilder malen kann eigentlich auch jeder. Es 
gibt wirklich extrem viel Bücher zu diesem Thema und mit kleinen Tipps 
ist es leider nicht getan! Ein Anfang ist wie immer:
http://de.wikipedia.org/wiki/Softwaretechnik

So, ich wünsche allen einen guten Rutsch!

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ihr wollt doch jetzt nicht aufhören?

z.Z. bin ich mit dem Go4-Buch beschäftigt ;)

Ich habe aber gemerkt dass ich viel zu wenig plane. z.B. implementiere 
ich Programmteile die ich dann garnicht brauche, oder ich finde einen 
Weg der das Problem viel besser löst.
Aber wenn Herr Neugier große Programme ganz ohne Planung und Doku 
schreibt, hat er entweder ein großes Super-Gehirn ;) oder eine andere 
Vorstellung von 'groß'.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Feadi wrote:
>.... z.B. implementiere
> ich Programmteile die ich dann gar nicht brauche, oder ich finde einen
> Weg der das Problem viel besser löst.

Jo mei das ist doch normal, je mehr du in ein Thema einsteigst, desto 
einfacher findest du dich darin zu recht. Am Anfang glaubst du, du 
brauchtest nen Kran. Den hast grad nicht aber nen Kettenzug also erst 
mal hoch das Zeug und der letzte ruck geht mit nem kleinen Hebel
Kein Kran und noch nen Tag gespart.

> Aber wenn Herr Neugier große Programme ganz ohne Planung und Doku
> schreibt, hat er entweder ein großes Super-Gehirn ;) oder eine andere
> Vorstellung von 'groß'.

Nein das muß nicht sein.
Das wirkt nur auf uns Gedächtniskrüppel abstrus.
Wir sollten uns damit vertraut machen, dass Menschen mit ihrer an sich 
gleichen Ressource Hirn unterschiedlich umgehen können. Weit verbreitet 
ist die Meinung, nur sozial Orientierte hätten die besseren Chancen. 
Diese Meinung ist zwar evolutionstheoretisch schwer von der Hand zu 
weisen, jedoch selbst in diesem Kontext widerlegbar, so kann in 
Extremsituationen (länger anhaltender akuter Mangel an evident 
Notwendigem) eine Gruppe schwerer überleben als ein Spezialist welcher 
isoliert leben kann, da im knappe Ressourcen ein Überleben ermöglichen.

Nicht von ungefähr hat das Wort "Krise" im Altgriechischen die 
Doppelbedeutung welche wir von selbiger als "Chance" abstrahieren.

Neuere wie auch ältere Studien beschäftigen sich mit Menschen bei denen 
sich die Gerichtetheit  der Hirnleistung weg vom sozialen hin zu 
verstärkter Abstraktionsfähigkeit gestaltet. Es ist ein fließender 
Übergang, wo jeder von uns sich da einzuordnen vermag  muss er selbst 
bestimmen.

Die meisten meiner Mitschüler waren mit bruchrechnen und Euklidscher 
Geometrie voll ausgelastet aber fanden sich in der Klassenstruktur 
bestens zurecht. Ich "Trottel" hingegen kam damit zunächst gar nicht 
klar (Schulklasse wie C-Klasse, heute besser aber noch immer nicht gut), 
da gegen waren Chemie, Mathe und Physik weniger langweilig als 
Sprachen(die ich erst neuestens entdecke). Die erste Grenze meines 
Abstraktionsvermögens erreichte ich bei der Auflösung von Integralen 3. 
Ordnung. Es fehlte mir schlicht an Phantasie das passende 
Ergänzungsintegral zu bilden um das zu Lösende um einen Grad zu 
reduzieren, ich benötigte plötzlich ein Schema nachdem vorzugehen sei. 
Aber diese Universalkrücke habe ich bis heute nicht gefunden.

Fakt ist es gibt Menschen mit nahezu unglaublichen 
Abstraktionsfähigkeiten und fotographischer Gedächtnisleistung, welche 
leider oft seelische Krüppel sind. Ich bitte alle das nicht persönlich 
zu nehmen und ich neige nicht zu Generalisierung.

Daneben gibt es solche deren Lebensbasis ungeheures soziales Feeling ist 
(ich meine hier nicht Mutter Theresa) sondern einfach ganz normale 
Menschen die zwar nicht mehr als ihre Wohnung und den Kochtopf 
beherrschen aber es verstehen alle sie umgebenden Personen so in ihr 
Umfeld einzubauen, das die sie rundum versorgen.

Auch das lässt sich ins Extreme verfolgen. Soziales Feeling ohne 
Gewissen führt zum skrupelloser Selbstbereichehrung. Betrüger nutzen 
genau ihr soziales Wissen, um die Schwächen der Gutgläubigen für sich zu 
plündern.


Ich bin bereit Neugier zu glauben
und stelle die These auf das auf in das Savant-Syndrom zumindest im 
Ansatz zutreffen mag, ohne das er darunter leiden muss.

http://de.wikipedia.org/wiki/Inselbegabung

Die Frage ist nur: Was ist normal?
der Anstandsleiter oder "seine" Insassen ;_))))))


Ist sozial == normal oder können uns auch gänzlich unsozial organisierte 
Persönlichkeiten wichtig sein, ja sind sie nicht unverzichtbar?

Meine 2. These ohne Savants gäbe es keinen heutigen Menschen. Unsere 
Vorfahren hätten den Urwald nie verlassen ;-)).

Und seien wir mal ehrlich nur unsere Umwelt und die Disziplin machen uns 
Freaks in der Gesellschaft der „Normalos“ hoffähig.

ein gutes Neues Uns Allen,  den organisierten und den unorganisierten 
Chaoten.

back to Topic.









Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
p.S.

Worüber ich die ganze Zeit nachdenken mußte, während ich den Thread las:
Bin ich nun ein frickelnder Planer oder ein planender Frickler ?-)

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ein Punkt kommt mir hier zu kurz.

Alle denken mir zu abstrakt. Motivation spilet für mich die grösste 
Rolle bei umfänglichen Projekten (eines davon ist beispielsweise 
Microsoft Windows).

Und da zählen ganz andere Faktoren:

- Bezahlung
- Arbeitsklima
- eine Vision haben
- Realisierbarkeit und praktischer oder persönlicher Nutzen

usw.

Es macht gar nicht so sehr ein Unterschied in Assembler oder in einer 
vorgegebenen Architektur in einer höheren Sprache zu programmieren 
solange das Umfeld Ok ist. Zugegeben ist Assemblercode zunächst 
unübersichtlich und schlecht wartbar und auch keine rechte Architektur, 
aber das muss nicht so sein.

Ich habe die Erfahrung gemacht, dass man sich in Details beginnt zu 
verzetteln und nicht weiterkommt, weil man "das Problem" beginnt aus den 
Augen zu verlieren oder es einfach zu schwierig ist. Das helfen gute 
Ratschläge in Form von GO4 und Arbeitsteilung und Zeitplanung wenig.
Das sind alles Dinge um sich herumzudrücken, dem eigentlichen Problem 
auszuweichen.

Ein Beispiel ist die Aufgabe: "Baue ein sprachverstehendes intelligentes 
System!".

Ein anderes Extrem ist eine lästige Trivialaufgabe der Realisierung 
einer vorgegebenen Benutzeroberfläche für ein solches System.

Im Programmieralltag begegnen einem viel Trivialaufgaben, um die man 
sich gerne nur herumdrückt. Und da sind die Methoden der modernen 
Softwareentwicklung wirksam. Da kommt dann auch noch ein Betriebswirt 
mit seinem Zeitplaner intellektuell mit.

Leider sind solche "Lösungen" meistens ziemlich verzichtbar.

Also interesssante Aufgaben, die über eine Textverarbeitung hinausgehen 
kosten einfach ihre Zeit und erforderen etwas von Genialität und 
Einsicht in die Zusammenhänge, was mit Programmieren dann gar nicht mehr 
so viel zu tun hat.

Was mich jetzt ärgert ist, dass es 
Entscheidungsträger/Arbeitgeber/Auftraggeber gibt, die sowas alles in 
einen Topf werfen und mit ihrer Stoppuhr praktisch eine Zeitmaschine 
geschenkt bekommen haben wollen.

In diesem Sinne stehe ich über GO4 weil leeres Stroh gedroschen wird.

Das musste mal gesagt werden!

Gruss 2007

Jorge


Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In diesem Sinne stehe ich über GO4 weil leeres Stroh gedroschen wird.

1) Gibt es durchaus Leute, die das was im GO4 diskutiert wird
   interessant finden

2) Ist genau der Inhalt vom GO4 eienr der Bausteine, die einem
   helfen, den faden Routinejob möglichst schnell hinter sich
   zu bringen um sich dann mit Genuss den interessanten 5%
   in einem Projekt zu widmen.

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich bin ich dafür und nicht dagegen. Ich habe nur etwas gegen den 
unreifen religiösen Eifer. GO4 gibts schon lang. Es hat nix bewegt.


>1) Gibt es durchaus Leute, die das was im GO4 diskutiert wird
   interessant finden

Ha. Bürokraten. Über die Wahrheit kann man nicht demokratisch 
entscheiden, d.h. man kann es zwar aber...


>2) Ist genau der Inhalt vom GO4 eienr der Bausteine, die einem
   helfen, den faden Routinejob möglichst schnell hinter sich
   zu bringen um sich dann mit Genuss den interessanten 5%
   in einem Projekt zu widmen.

"Form Follows Function". Also zuerst die Eingebung.
Die 95% meistert man hauptsächlich über "Motivation". Anschliessend kann 
man sich dann noch der Verbesserung einer Architektur zuwenden.

Ansonsten erfüllt es noch die Funktion des Blendwerk. Mir ist es schon 
passiert, dass der Auftraggeber abgesprungen ist, weil er sein Vorhaben 
für unrealistisch befunden hat. Hat ein bisschen gejammert und ist dann 
frischen Mutes zur nächsten Klitsche gegangen. Dort hat man ihm 
Zwischenlösungen verkauft. Und wenn sie nicht gestorben sind...

Also die Realität des Alltags bewegt sich woanders. Das meine ich.






Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>1) Gibt es durchaus Leute, die das was im GO4 diskutiert wird
>   interessant finden
>
> Ha. Bürokraten.

Würde ich nicht sagen. Algorithmen und Datenstrukturen haben
mich schon immer fasziniert. Und ich bin sicher kein
Bürokrat.

> Die 95% meistert man hauptsächlich über "Motivation".

:-)
Die 95% meistert man in 3 Nachtschichten 1/2 Woche vor
Abgabe.
:-)

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es beruhigt mich, das Andere auch Nachts Dinge durchziehen welche im 
Stress des Alltags einfach nicht zu lösen sind weil ständig irgend etwas 
den notwendigen Fluß stört:
-Arbeit,
-Essen,
-Trinken und
-unwichtige Termine,
-Schatzi könntest du nicht mal schnell...,
-beim .... gibts .....Sonderangebot ...,
-Sonnenlicht und
-das Geschrei der Vögel

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried Jaeckel wrote:
> Es beruhigt mich, das Andere auch Nachts Dinge durchziehen welche im
> Stress des Alltags einfach nicht zu lösen sind weil ständig irgend etwas
> den notwendigen Fluß stört:
> -Arbeit,
> -Essen,
> -Trinken und
> -unwichtige Termine,
> -Schatzi könntest du nicht mal schnell...,
> -beim .... gibts .....Sonderangebot ...,
> -Sonnenlicht und
> -das Geschrei der Vögel

-völlig unwichtige Programmfeatures, die aber oberaffengeil
 sind. Wen interessiet schon die Eingabe und Verwaltung von
 Kundendaten wenn er in der gleichen Zeit auch ein
 Partikelsystem zur Simulation von Vorhängen die im Wind flattern
 machen und optimieren kann :-) Ist zwar nur ein Gimmick
 im Programm, zu nichts nutze, aber schön zum anschauen.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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