Motivation bei Privatprojekten (Split aus Diamond of Death)

volkard

314159265358979 schrieb:

Gibt es irgendwelche Methoden, die sich beim Designen als besonders gut erwiesen haben?

Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind. Da sehe ich bei Dir größte Gefahr. Ablehnen von Shlaer-Mellor. UML nicht als Planungswerkzeug benutzen. Ich glaube nicht, daß mangelnde Planung überhaupt etwas mit Deinem Problem zu tun hat. Deine Projekte kippen ja nicht um, werden nicht unwartbar wegen schlechtem Anfang, eröffnen nicht, daß der Anfang ganz falsch war. Sondern Du verlierst einfach die Lust, sobald Du herausgefunden hat, wie es geht. Deswegen lernst Du auch so schnell, auffallen schnell, würde ich sagen. Was Du brauchst, sind ein paar FIAEs, die den Rest für Dich erledigen. Oder einen Chef, der sehr sehr traurig wird, wenn Du das Projekt nicht fertig machst.

314159265358979

Die Sache ist die: Ich möchte endlich mal ein Projekt, das ich auch herzeigen kann. Wenn ich die Leute im IRC sehe, wie der erste mit seinem 3D-Spiel mit Raumkrümmung, der nächste mit seinem siebzehnten IRC-Daemon und der dritte mit einer eigenen Programmiersprache daherkommt, fragt man sich, ob man nicht doch irgendwas falsch macht.

Jester

volkard schrieb:

Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind.

[...]

UML nicht als Planungswerkzeug benutzen.

genau.

UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger. Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar. Warum schadet es, nachdem man siche ne Liste der wichtigsten Klassen gemacht hat, sich Boxen zu malen, da die Klassennamen reinzuschreiben und Klassen die sich vermutlich kennen müssen mit ner Linie zu verbinden? Wo ist das Problem? Menschen arbeiten stark visuell, das auszunutzen ist doch kein Fehler.

@314159265358979: überleg dir, was die wichtigsten klassen sind, was die ungefähr für schnittstellen brauchen und welche Klassen (bzw. Instanzen davon) sich kennen müssen. Ob Du auf dem richtigen Weg bist kannst Du leicht überprüfen, indem Du mal versuchst dir zu überlegen wie Du jetzt die Use-Cases abhandeln würdest, wer müßte dafür wen wann und mit welchen Informationen aufrufen? Kennen die die benötigten Objekte und können sie sich die benötigen Informationen besorgen? Wenn nicht, hast Du vermutlich noch ein paar Verbindungen übersehen.

volkard

Jester schrieb:

UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger.

Wird aber in Schule, Berufsschule und Studium als Planungswerkzeug gelehrt.

Jester schrieb:

Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar.

So, wie ich auch religiös gegen den Papst eifere.

this-*gt*that

Jester schrieb:

genau.

UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger. Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar. Warum schadet es, nachdem man siche ne Liste der wichtigsten Klassen gemacht hat, sich Boxen zu malen, da die Klassennamen reinzuschreiben und Klassen die sich vermutlich kennen müssen mit ner Linie zu verbinden? Wo ist das Problem? Menschen arbeiten stark visuell, das auszunutzen ist doch kein Fehler.

volkard is halt in vielen Bereichen ziemlich... verbohrt.

volkard

volkard schrieb:

UML nicht als Planungswerkzeug benutzen.

Jester schrieb:

UML ist auch kein Planungswerkzeug

this->that schrieb:

volkard is halt in vielen Bereichen ziemlich... verbohrt.

Ich hätte auch feststellen können, daß Gras grün ist; es wird jemanden geben, der mir das zur Last legt.

Jester

Weil das bei Dir klingt, als müsse man sich von UML fernhalten. Das ist aber eigentlich überhaupt kein Kriterium. UML bietet nichts anderes als eine "Sprache", in der man Entwürfe aufmalen kann. Da ist meiner Meinung nach nichts falsches dran. Oder wie siehst Du das? Natürlich muß man nach wie vor selber nachdenken welche Klasse welche Funktionalität bietet, welche Interfaces sich kennen sollen etc. Das kann einem aber auch keiner abnehmen.

Zugegeben, vieles an UML ist überladen, mir genügen zum Beispiel Boxen für Klassen, ungerichtete Verbindungen, evtl. besondere Pfeile für Vererbung und Gruppierungen durch Pakete; für das hier angestrebte Projekt ist das mit Sicherheit vollkommen ausreichend. Man mag sich streiten, ob man das noch UML nennen mag (ich würde aber schon dazu tendieren). Aber hilfreich ist das doch allemal.

Wenn Du das Gefühl hast, dass UML zu stark als Planungswerkzeug und zu wenig als Konvention fürs Aufmalen von Planungsergebnissen (bzw. deren Evolution) verstanden wird, warum arbeitest Du dann nicht eher dagegen als gegen das komplette Konzept UML? Das komplette Ablehnen wirkt dagegen einfach nur stur und wenig begründet.

volkard

Jester schrieb:

Wenn Du das Gefühl hast, dass UML zu stark als Planungswerkzeug und zu wenig als Konvention fürs Aufmalen von Planungsergebnissen (bzw. deren Evolution) verstanden wird, warum arbeitest Du dann nicht eher dagegen als gegen das komplette Konzept UML? Das komplette Ablehnen wirkt dagegen einfach nur stur und wenig begründet.

volkard schrieb:

314159265358979 schrieb:

Gibt es irgendwelche Methoden, die sich beim Designen als besonders gut erwiesen haben?

Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind. Da sehe ich bei Dir größte Gefahr. Ablehnen von Shlaer-Mellor. UML nicht als Planungswerkzeug benutzen. Ich glaube nicht, daß mangelnde Planung überhaupt etwas mit Deinem Problem zu tun hat. Deine Projekte kippen ja nicht um, werden nicht unwartbar wegen schlechtem Anfang, eröffnen nicht, daß der Anfang ganz falsch war. Sondern Du verlierst einfach die Lust, sobald Du herausgefunden hat, wie es geht. Deswegen lernst Du auch so schnell, auffallen schnell, würde ich sagen. Was Du brauchst, sind ein paar FIAEs, die den Rest für Dich erledigen. Oder einen Chef, der sehr sehr traurig wird, wenn Du das Projekt nicht fertig machst.

Nö, da bist Du hochgegangen, weil ich meinen dreckigen Finger auf eine Wunde legte.

Jester schrieb:

Aber hilfreich ist das doch allemal.

Hier liegt der Hund begraben.

Jester

volkard schrieb:

Nö, da bist Du hochgegangen, weil ich meinen dreckigen Finger auf eine Wunde legte.

Quark, Du hast offensichtlich eine UML-Wunde, die Du bei jeder Gelegenheit auspackst. Und genau da leg ich grad den Finger rein, und was kommt? Gejaule aber kein einziges Argument. Schade.

An das Mär vom Projekt, das nur scheitert weil jetzt alles ganz einfach ist, glaube ich nicht. Insofern halte ich Deine Analyse für falsch und auch für kontraproduktiv. Wenn ein Projekt scheitert, sollte man sich vielleicht mal überlegen woran es genau gelegen hat. Da scheint mir die Erklärung, dass die immer alle zu leicht waren auf Dauer nicht sehr befriedigend.

volkard

Jester schrieb:

und was kommt? Gejaule aber kein einziges Argument. Schade.

Wie sind doch einer Meinung, was UML als Planungswerkzeug angeht.

Jester schrieb:

Da scheint mir die Erklärung, dass die immer alle zu leicht waren auf Dauer nicht sehr befriedigend.

Das war nicht meine Erklärung.

otze

314159265358979 schrieb:

Die Sache ist die: Ich möchte endlich mal ein Projekt, das ich auch herzeigen kann.

Dann mach einfach. Du hast jetzt eine Programmdefinition, also eine Art Lastenheft. da du alleine bist und das bereits eine Menge ist, solltest du jetzt Schrittweise vorgehen:

1. definiere aus dem Lastenheft den "minimalen Bot". Was davon muss ein Bot haben, um als sochler geradfe noch durchzugehen.
2. Mache eine Planung des Bots anhand dieses Minimalsets.
3. Checke schnell ob deine Planung auch auf die anderen Features erweiterbar ist, oder ob es offensichtliche Konflikte gibt. Wenn ja, dann ändere das Design Wiederhole, bis kein offensichtlicher Konflikt mehr besteht. Hierbei gehts nicht darum, das perfekt erweiterbare design zu finden. Sondern eins, dass dich nicht in eine Sackgasse führt.
4. Jetzt kannst du programmieren.
5. testen des minimalen Bots
6. einfügen der neuen Features

Ich vermute, dass bei dir 1-3 nicht das Problem ist. Ich denke dass du schon Ahnung hast, was du programmieren willst und wie das aufgebaut ist. Nur ziehst du das nie durch. Die Checkliste da oben führt dich schnell zu einem Grundgerüst eines Bots den du relativ schnell implementieren können solltest. ALso hast du fix ein Erfolserlebnis und schon einmal etwas, was vorzeigbar ist. Andererseits sorgt diese Minimaldefinition dafür, dass du nicht von der ganzen Komplexität des Programms auf einmal erschlagen wirst. Bei 6. kann sich dann das Design schrittweise bewähren. Irgendwann wirst du refactorn müssen und eventuell sogar bei dem ein oder anderen Feature scheitern. Das ist lehrgeld, das haben auch die mit dem tollen Ultraspiel gezahlt.

314159265358979

Ich habe mal angefangen, über eine Session Klasse nachzudenken. Allerdings bin ich schon damit mal überhaupt nicht zufrieden. Hier mal das Interface.

namespace irc
{
    class session
    {
    public:
        session(std::string server, uint16_t port, std::string nickname, std::string username = nickname, std::string realname = nickname);

        std::string read_line();
        void write_line(std::string line);

        const std::string& server() const;
        uint16_t port() const;

        const std::string& nickname() const;
        const std::string& username() const;
        const std::string& realname() const;

        void disconnect();
    };
}

Was mich daran stört ist der nickname. Nicknames gehören zur Session, aber ein nickname kann auch geändert werden. Die Logik dafür gehört irgendwie nicht in die Session, aber der Nick in der Session muss irgendwie geändert werden. Ideen?

Edit: Achja, und Channel fehlen da natürlich auch noch, hier dasselbe.

Jester

mach erstmal den grobaufbau, das ist imo schon zu detailliert. welche komponenten gibt es, welche klassen brauchen die, schreib zu jeder klasse (und auch zu jeder komponente im grobaufbau) einen satz, der ihre aufgabe beschreibt.

314159265358979

irc::session
Enthält Daten zu aktuellen Verbindung - Nickname, Username, Realname, Channel

irc::logger
Verwaltet die Log-Datei, fügt Datum/Zeit-Strings und Server/Client Präfixe an.

irc::config_manager
Erstellt eine neue Config-Datei, wenn nicht vorhanden und bietet Zugriffsmethoden auf die einzelnen Einstellungen.

irc::channel
Enthält Daten über den Channel (User + Rechte, Chanmodes, Topic) und stellt Methoden zu dessen Verwaltung bereit.

irc::plugin_manager
Bietet Methoden zur Verwaltung von Plugins und zum Auslösen von Events.

irc::plugin
Stellt Methoden zur Kommunikation mit Plugins bereit.

irc::message_parser
Zerlegt Nachrichten in ihre Teile und macht daraus Events, die an den irc::plugin_manager weitergeleitet werden.

So richtig, oder doch zu ungenau?

Edit - Vergessene Klassen:

irc::console
Selbsterklärend nehme ich an. Stellt dem Benutzer die Befehle zur Verfügung.

irc::listener
Plugin-seitige Klasse, die auf Events reagieren kann.

ipsec

Mache dir am besten auch einen Ablaufplan. Was passiert, wenn ein Client connected, oder jemand eine Nachricht schreibt, oder jemand einen Befehl absetzt etc.? Insbesondere welche Klassen sind wie und in welcher Reihenfolge beteiligt. Überlege auch die Ablaufpläne für deine User Stories.

pumuckl

otze schrieb:

Schrittweise vorgehen: [...]

So in der Art mache ichs auch. Ich weiß, dass mein aktuelles Projekt eine Weile (1-2 Jahre oder länger) dauern kann. Ich hab mir daher Meilensteine definiert, die sehr fein granular sind. Der erste ist z.B. nur, das Grundgerüst der Architektur (die ich mir vorher gut überlegt hab) zum Laufen zu kriegen, d.h. Programm startet, alle Komponenten werden einmal erzeugt und kurz "angetickt", und das Ding fährt sich wieder runter. Wenn das läuft, kommt schrittweise die Funktionalität in kleinen Happen.
Was ich dabei beachten muss ist, mich zu beherrschen. Viele Funktionalität brauche ich noch garnicht, auch wenn es mich in den Fingern juckt, die "mal eben" zu schreiben. Was ich nicht brauche, ist eben später dran, und so komme ich einerseits relativ schnell zu den Ergebnissen, andererseits bin ich bei jedem Meilenstein gezwungen, einen Teil der nervigen Drecksarbeit zu machen, die man so gern auf später verschiebt und die einem normalerweise im "fast fertig"-Zustand den Tag vermiest, weil die ganzen Bonbons schon gelutscht sind und nurnoch Mist zu erledigen ist
Ich arbeite streng Testbasiert, d.h. ich schreibe den Header einer Klasse, dann erst die nötigen Tests, und dann die Implementierung, bis die Tests laufen. Die Implementierung soll dabei so einfach wie möglich bleiben, d.h. wenn es noch keine Situation gibt, in der der Client mit einem Server verbunden ist, dann liefert Client::isConnected() eben stumpf false zurück, statt irgendwelche komplexeren Abfragen zu starten.
So gehts schrittweise voran - und ich hab noch nie so lange und gerne an einem Projekt gearbeitet wie an dem aktuellen

EXDW

Ich zieh auf Arbeit ein Projekt alleine auf - seit ende 2008. Das Projekt mach immer noch Spaß, und es kommen immer mehr Features hinzu Hätte das Projekt auch gerne daheim am PC, aber hier nützt es nichts ^^.

314159265358979

Use Case Config-Erstellung
.) Sollte glaub ich selbsterklärend sein. irc::config_manager erstellt die Datei, wenn nicht vorhanden.

Use Case Log-Start
.) Ebenfalls selbsterklärend. irc::logger erstellt Logdatei.

Use Case Auto-Connect
.) Mit irc::config_manager werden die Verbindungsdaten geholt
.) Eine neue irc::session wird erstellt

Use Case Auto-Plugin-Load
.) irc::plugin_manager lädt Plugins.

Use Case Nachricht vom Server:
.) irc::session liest Zeile
.) irc::message_parser erzeugt Event aus der Zeile
.) Ändert sich was Channel-spezifisches, wird irc::channel verwendet
.) irc::plugin_manager schickt das Event an die Plugins

Use Case Nachricht von Plugin:
.) irc::plugin_manager benachrichtigt irc::message_parser
.) irc::message_parser macht IRC Nachricht
.) irc::session sendet die Nachricht

Use Case Plugin-Shutdown:
.) irc::plugin_manager stoppt Plugins

Use Case Bot-Shutdown:
.) irc::plugin_manager fährt Plugins herunter
.) irc::session schließt Verbindung

Use Case Console-Connect:
.) irc::console liest Befehl ein
.) irc::session wird erstellt und verbindet
.) irc::plugin_manager startet Plugins

Use Case Console-Disconnect:
.) irc::console liest Befehl ein
.) irc::plugin_manager stoppt Plugins
.) irc::session schließt Verbindung

Use Case Console-Plugin-Start:
.) irc::console liest Befehl ein
.) irc::plugin_manager startet Plugin

Use Case Console-Plugin-Stop:
.) irc::console liest den Befehl ein
.) irc::plugin_manager stoppt Plugin

Use Case User-Information:
.) irc::console gibt Zeile samt Datum und Uhrzeit aus

Use Case Logging:
.) irc::logger schreibt Zeile samt Datum und Uhrzeit in Datei

So?
(Plugin API lass ich jetzt mal Weg, wichtig ist mal der Bot.)

ipsec

Das ist alles zu ungenau, du vergisst jedesmal die Hälfte. Beispiel:

314159265358979 schrieb:

Use Case Auto-Connect
.) Mit irc::config_manager werden die Verbindungsdaten geholt
.) Eine neue irc::session wird erstellt

Der config_manager kommt doch nicht einfach mal so auf die Idee, die Verbindungsdaten zu holen, genauso wenig wie session telepathisch davon erfährt und plötzlich meint, eine Verbindung aufbauen zu müssen.
Also: Wer lässt den config_manager die Daten holen, an wen werden sie weiter gegeben, wer erstellt die Session, was passiert dann mit der Session?

Das gleiche bei den anderen Use-Cases.

314159265358979

Ich weiß nicht so Recht, wie ich das beschreiben soll

So ein Konstrukt hab ich im Hinterkopf:

int main(int argc, char** argv)
{
    irc::config_manager conf("bot.conf");

    std::string host = conf.get<std::string>("host");
    uint16_t port = conf.get<utin16_t>("port");

    std::string nickname = conf.get<std::string>("nickname");

    irc::session session(host, port, nick);
}

Wie soll ich sowas beschreiben?