App-Überblicksplanung in C#: Das große Ganze mit Tim Corey lernen

Einführung in die Gesamtplanung

Zu Beginn des Videos führt Tim Corey in Lektion 02 ein und erklärt, dass der Schwerpunkt auf der Gesamtplanung liegt, auch als das große Ganze der Anwendung beschrieben. Tim erklärt, dass dieser Schritt darin besteht, das Fundament der App zu legen, bevor man sich in Details vertieft. Er betont, dass obwohl diese Lektion einfacher erscheinen mag als andere, sie eine entscheidende Rolle bei der Schaffung von Apps spielt, die verwaltbar, skalierbar und wartbar sind.

Tim erklärt, dass es bei der Gesamtplanung nicht um Features oder das Schreiben von Code geht. Es geht darum, zu verstehen, wie die App als Ganzes funktioniert, wie Benutzer damit interagieren und wie Entwickler beim Aufbau vorgehen sollten.

Überprüfung von Stakeholder-Fragen

Tim erklärt, dass er, bevor er weitermacht, die 15 Fragen aus der vorherigen Lektion revisieren muss. Diese Fragen wurden entwickelt, um zusätzliche Informationen von Stakeholdern zu sammeln—den Personen, die die App verlangen. Tim simuliert ein reales Szenario, in dem ein Entwickler zu den Stakeholdern zurückgeht, klärende Fragen stellt und detailliertere Antworten sammelt.

Er weist darauf hin, dass dieser Prozess reale Geschäftsumgebungen widerspiegelt. Entwickler müssen häufig mehrere Fragen stellen und Anforderungen verfeinern, da Benutzer nicht immer wissen, wie sie beschreiben sollen, was sie in technischen Begriffen wollen.

Variable Spieleranzahlen und Turniergrößen

Tim beginnt mit der Überprüfung der Antworten, indem er erklärt, dass die App eine variable Anzahl von Spielern unterstützen muss. Der Turnier-Tracker sollte nicht auf eine feste Anzahl beschränkt sein. Egal, ob es zwei Spieler oder viele mehr sind, die App muss damit umgehen.

Diese Anforderung wirkt sich direkt auf die Funktionalität, die Datenstrukturen und die Logik der App aus. Tim erklärt, dass Entwickler keine Annahmen über die Anzahl der Spieler fest codieren können. Stattdessen muss die App dynamisch Benutzer und Spiele basierend auf der Anzahl der Teilnehmer verwalten.

Umgang mit Freilosen in unvollständigen Turnieren

Tim erklärt, dass Turniere nicht immer eine ideale Anzahl von Spielern haben werden. Wenn die Gesamtzahl sich nicht gleichmäßig teilen lässt, muss die App Freilose zuweisen. An dieser Stelle hebt Tim eine wichtige Regel hervor: Freilose müssen zufällig zugewiesen werden.

Dies führt eine der wiederkehrenden technischen Anforderungen der App ein—die Zufallsmechanik. Die App muss Benutzer fair verwalten, indem sie zufällig auswählt, wer ohne Spiel weiterkommt. Diese Anforderung gestaltet spätere Entscheidungen über Werkzeuge, Logik und Ereignisse innerhalb der Anwendung.

Zufällige Reihenfolge der Spieler

Tim erklärt weiter, dass die Reihenfolge, wer gegen wen spielt, ebenfalls zufällig sein sollte. Die App sollte sich nicht auf die Reihenfolge verlassen, in der Benutzer eingegeben werden. Sobald alle Spieler hinzugefügt sind, randomisiert die App die Liste.

Dies stellt Gerechtigkeit sicher und vermeidet Voreingenommenheit. Tim macht deutlich, dass Zufälligkeit eine Regel ist, keine optionale Funktion. Es wird Teil der Kernregeln der App und muss während der gesamten Entwicklung respektiert werden.

Flexibles Spielplanen

Tim erklärt, dass Spiele nicht vom System geplant werden. Spieler können spielen, wann immer sie wollen. Die App setzt jedoch weiterhin Regeln durch. Bei 3:04 erklärt Tim, dass jede Runde abgeschlossen sein muss, bevor die nächste Runde angezeigt wird.

Diese Anforderung beeinflusst, wie die App Spiele verfolgt, Daten verwaltet und Ereignisse auslöst. Die App muss wissen, wann eine Runde beendet ist, und verhindern, dass Benutzer vorzeitig auf spätere Runden zugreifen.

Punktwertung und Datenflexibilität

Tim erklärt, dass das System eine einfache numerische Punktzahl speichern sollte. Dadurch bleibt die App flexibel genug, um verschiedene Spieltypen zu unterstützen. Egal ob es sich um Dame, Basketball oder einen anderen Wettbewerb handelt, dieselbe App kann Punktzahlen verwalten.

Diese Entscheidung beeinflusst, wie Daten gesammelt, gespeichert und angezeigt werden. Indem die Punktwertung einfach gehalten wird, vermeiden Entwickler, die App auf eine spezifische Art von Spiel festzulegen.

Benutzeroberflächen mit Blick auf die Zukunft wählen

Tim erklärt, dass die App vorerst eine Desktop-Anwendung sein wird, die Windows Forms verwendet. Er betont jedoch, dass Stakeholder später möchten, dass die gleiche App sich zu einer Web- oder mobilen Plattform weiterentwickelt.

Tim erklärt daher, dass Entwickler Benutzerschnittstellen von der Geschäftslogik trennen müssen. Bei 4:41 erklärt er, dass die Kernfunktionalität in eine Klassenbibliothek geschoben werden sollte, sodass verschiedene Benutzerschnittstellen später integriert werden können, ohne die App neu zu schreiben.

Datenhaltung und Integrationsstrategie

Tim erklärt, dass Daten idealerweise in Microsoft SQL Server gespeichert werden sollten, aber die App muss auch einen Textdatei-Fallback unterstützen. Dies stellt sicher, dass die App auch dann funktioniert, wenn bestimmte Werkzeuge oder Dienste nicht verfügbar sind.

Diese Entscheidung beeinflusst, wie Entwickler den Datenzugriffscode schreiben. Tim erklärt, dass die Integration flexibel sein muss, sodass dieselbe App Daten aus verschiedenen Quellen speichern und abrufen kann, ohne die Funktionalität zu beeinträchtigen.

Teilnahmegebühren, Preise und reale Unklarheit

Tim erklärt, dass Stakeholder oft vage Antworten geben. Anfangs lautet die Antwort auf die Frage, ob die App Teilnahmegebühren und Preise verarbeitet, einfach "Ja." Tim erklärt, dass Entwickler tiefer graben müssen, um zu verstehen, was das bedeutet.

Er umreißt dann die geklärten Anforderungen: Turniere können Teilnahmegebühren erheben, Preise an mehrere Plätze vergeben und sicherstellen, dass Auszahlungen nie das Einkommen übersteigen. Er erklärt auch anteilige Auszahlungen und Fundraising-Szenarien.

Dieser Abschnitt zeigt, wie die Gesamtplanungsübersicht Entwicklern hilft, reale Geschäftsregeln zu antizipieren, ohne die App zu komplizieren.

Meldung und Anzeige von Ergebnissen

Tim erklärt, dass die Berichterstattung einfach sein sollte. Die App muss Rundenresultate und Endergebnisse anzeigen, einschließlich wer gewonnen hat und wieviel er gewonnen hat. Berichte können auf Formularen angezeigt oder per E-Mail verschickt werden.

Dies vermeidet den Aufbau eines komplexen Berichtssystems, während weiterhin die Erwartungen der Benutzer erfüllt werden. Der Fokus bleibt auf Funktionalität, nicht auf unnötigen Features.

Benutzerzugang und Einfachheit

Tim erklärt, dass jeder, der die App nutzt, die Spielergebnisse eingeben kann. Es gibt keine unterschiedlichen Zugriffsebenen innerhalb der Anwendung. Dies vereinfacht die Entwicklung, indem Konten, Passwörter und Sicherheitsebenen vermieden werden.

Er erklärt, dass die App in der Praxis auf dem Gerät des Administrators residieren kann, während andere Benutzer nur per E-Mail interagieren.

E-Mail-Benachrichtigungen und Automatisierung

Tim betont, dass die E-Mail-Funktionalität entscheidend ist. Die App muss Benutzer automatisch über bevorstehende Spiele und Rundenresultate benachrichtigen. Dies erfordert ein Verständnis für E-Mail-Integration und Automatisierung schon früh im Designprozess.

Tim stellt fest, dass diese Anforderung mehrfach auftritt und ihre Bedeutung signalisiert.

Unterstützung von Teams und Benutzergruppen

Tim erklärt, dass die App nicht nur Einzelpersonen, sondern auch Teams unterstützen muss. Alle Teammitglieder werden gleich behandelt und erhalten die gleichen E-Mails. Teams müssen auch Namen haben.

Dies beeinflusst, wie Benutzer gruppiert, Daten strukturiert und wie Ereignisse Benachrichtigungen auslösen.

Das große Ganze des Designs definieren

Tim führt die Idee des 'großen Ganzen' mit einer Malerei-Analogie ein. Er erklärt, dass diese Phase Grenzen definiert, nicht Details. Bei 18:48 umreißt er die Struktur: Eine Windows Forms App, eine Klassenbibliothek, SQL oder Textdatei-Datenhaltung und jeweils ein aktiver Benutzer.

Diese Grenzen verhindern, dass Entwickler in unnötige Entscheidungen abschweifen.

Schlüsselkonzepte für Entwickler identifizieren

Tim erklärt, dass Entwickler Schlüsselkonzepte identifizieren sollten, die sie möglicherweise erforschen müssen. Er listet E-Mail, SQL, benutzerdefinierte Ereignisse, Fehlerbehandlung, Schnittstellen und zufällige Anordnung auf.

Er erklärt, wie benutzerdefinierte Ereignisse verwendet werden können, um den Abschluss von Runden zu erkennen und Funktionalitäten wie E-Mails auszulösen.

Bonusideen ohne Verletzung der Anforderungen

Tim führt das Versenden von Nachrichten als mögliche zukünftige Erweiterung ein. Er erklärt, dass Bonusfunktionen nur akzeptabel sind, wenn sie die Kernanforderungen nicht ändern oder die Lieferung verzögern.

Dies verstärkt die Betonung auf die Einhaltung der in der Gesamtplanung festgelegten Regeln.

Zusammenfassung und nächste Schritte

Tim schließt sein Video ab, indem er den Prozess zusammenfasst: Stakeholder-Fragen führen zu Anforderungen, Anforderungen führen zum Gesamtentwurf und der Gesamtentwurf offenbart Schlüsselkonzepte. Er erklärt, dass sich die nächste Lektion auf das Daten-Design konzentrieren wird, indem aufgezeigt wird, wie die Informationen zusammenpassen.

Diese Lektion zeigt, wie sorgfältige Gesamtplanung Entwicklern hilft, strukturierte, flexible und wartbare Apps zu erstellen—bevor auch nur eine Zeile Code geschrieben wird.