Last 24h to go

Soooo angesichts der Tatsache, dass morgen unsere selbstdefinierte deadline morgen abläuft ein letzter aufruf zur Motivation.

Ich will spätestens morgen abend um Mitternacht die Version dichtmachen, das ab Mittwoch 00:00 Uhr kommen keine neuen Features mehr rein, es sei denn sie sind absolut unverzichtbar. Dann allerdings sollte auch nur nach Rücksprache etwas geändert werden.

Was die folgenden Zwei wochen bis zur Präsentation angeht:
- Testen: Wir müssen weiter testen - INTENSIV! Bisher sind leider verdammt wenige Bugs gefunden worden. Das heißt entweder, dass wir unglaublich gute Entwickler sind, dass wir es schaffen nahezu fehlerfreie Software zu entwickeln... oder, dass nicht genug getestet wurde... Ein paar sachen hatte ich selber noch gefunden und habe sie teilweise auch schon notiert...
- Bugs: Wenn Bugs gefunden werden, bitte SOFORT (und mit sofort meine ich gestern) im forum posten. Keine Sammelthreads mit "wir haben mal alle in einer runde zusammengesessen". ein bug - ein thread - instant!
- Bugfixing: Wenn ein Bug eingetragen ist, werden wir abwägen, wie risky es ist, den anzupacken und wie hoch die priorität darauf liegt. Danach wird entschieden ob der gefixt wird oder nicht.
- Dokumentation: Der Quelltext sollte dringend (!) ausgiebig dokumentiert und aufgeräumt werden, damit kommende Projekte den Kram problemlos aufgreifen können (außerdem wird das vermutlich auch in die Note eingehen...)
das gilt sowohl für die Klassen, als auch für das XAML. (wobei die klassen mehr zu lesen sind und daher wichtiger)... Auch das sollte bis zur Präsentation fertiggestellt sein (ich nominiere hierfür schonmal hauptsächlich diejenigen, die in den Letzten wochen inaktiv waren...). Als Wichtig erachte ich hierbei insbesondere:
- Inline-kommentare bei nicht-trivialen Funktionen, die beschreiben was passiert und weswegen es so passiert wie es passiert (das gilt auch für auch trigger o.Ä. im xaml, oder zugehörige codebehindfunktionen)
- Dokumentation (<summary>-block) für ALLE funktionen. Es ist wichtig zu beschreiben, was die Funktionen tun, und was ihre Parameter sind. (außerdem sieht man hierbei auch immer schön, ob es ungenutzte oder überflüssige Funktionen gibt)
- Sinnvolle Namen: das gilt insbesondere für das XAML. Alle Elemente (sofern noch nicht geschehen) sollten eindeutige, lesbare, sinnvolle Namen haben. (das gilt auch für grids, damit man direkt am Namen sieht, um welches Grid es sich handelt... Kommentare (<!--[Kommentar]-->) am Gridanfang mit spezifischer Beschreibung in besonders komplexen Fällen wäre Sinnvoll. Das gleiche gilt für Funktionen im Code, die evtl im Laufe der Zeit ihre funktionsweise so geändert haben, dass der Name nicht mehr gut passt. In den Fällen vollständig umbenennen (Refactor). Hierbei IMMER testen, ob das Programm noch startet. Aufrufe können auch aus anderen Klassen kommen. Beim Umbenennen von Commands IMMER das UI Team verständigen und ggf selber das Binding anpassen!


Für all das gilt: Je früher, je besser. Ich will nicht wieder in eine Crunchtime kurz vor der Präsi verfallen, nur weil in letzter Minute irgendetwas passiert was schon lange vorher hätte passieren sollen...

Aller vorraussicht nach kann ich am Mittwoch Abend den zweiten Teil der Quellcode-Bereinigung machen. Diese beinhaltet aber nicht das Kommentieren. Danach kann einer die Dokumentation übernehmen.

gut. Bitte ziehe in erwägung bei der bereinigung auch unnötige Funktionsweitergaben rauszunehmen Ich erinner mach daran dass es irgendwo eine funktion gab die mittlerweile nur eine andere funktion aufruft...)

oh man...das Kommentieren der Styles ist echt ätzend und wird noch sehr lange dauern (ich mach das mal immer zwischendurch)...wie detailiert sollen denn diese Dinger kommentiert werden?

also sagen wir mal so, du hast ja wenn ich das richtig gesehn hab teilweise mehrere styles in einer Datei.

Wenn du einfach für jeden einzelnen style nen comment vorklatschst, der beschreibt wie dieser style agiert (ich denke detaillierte beschreibung is für sowas egal, geht eher um die triggersachen), also ganz oberflächlich, zb "Listbox, gelber rahmen onmouseover, roter rahmen bei selektion"

+

Wenn komplexere Trigger verwendet werden, für den trigger nen kommentar der den kurz erläutert...

das sollte eigentlich reichen (nur damit jemand der projektfremd ist das lesen und nachvollziehen kann)

ok, alles klar

so die version is quasi dicht und lade grad hoch im Ordner Toolsmith - 1.0

Hab schonmal so viele bugs wie möglich noch gefixt. Wenn jetzt jemand was ändern möchte, bitte im regulären Toolsmith ordner arbeiten und rücksprache halten, wenn etwas wichtiges ist was noch rein muss (einiges hat es leider nicht rechtzeitig geschafft)...

Wenn also etwas reinmuss: Arbeiten, einchecken und dann bescheidsagen ich integrier das dann in den 1.0 ordner.


Edit:
Aso, sollte ich vielleicht noch erwähnen, Testen dann ab jetzt bitte auf der Toolsmith - 1.0 version. exe Datei is auch mit drin, das heißt keiner sollte technische Probleme dabei haben. Weiterhin gilt: wir suchen bugs, und ich bin sicher der eine oder andere versteckt sich noch und wir haben nur 2 wochen um die zu finden UND ZU FIXEN! Wäre also gut wenn die schnellstmöglich gefunden werden, sonst haben wir keine chance mehr...

Leider muss ich zur Zeit noch für zwei Klausuren lernen die ich kurz hintereinander schreibe bzw. eine auch im zweiten Versuch. Daher habe ich bis MIttwoch leider nicht viel Zeit für Verbesserungen (würde aber gerne noch die Hilfen einbauen). Aber ich könnte dann direkt nach meiner letzten Klausur noch den Rest erledigen. Ich hoffe das ist so in Ordnung.

wird wohl so sein müssen... wenn wir sauber arbeiten sollte das aber kein problem sein weil die dinge sich dann problemlos mergen lassen sollten (so hoffe ich doch)... Wir haben auch noch ein paar tasks offen, ich hoffe dennoch dass fleißig getestet wird und die bugs dann auch direkt eingetragen werden...