Planowanie przeglądu aplikacji w C#: Nauka całościowego obrazu z Timem Coreyem

Wprowadzenie do Planowania Przeglądowego

Na początku filmu Tim Corey przedstawia Lekcję 02 i wyjaśnia, że skupienie jest na planowaniu przeglądowym, również określanym jako duży obraz aplikacji. Tim wyjaśnia, że ten krok dotyczy kładzenia fundamentów aplikacji przed zagłębianiem się w szczegóły. Podkreśla, że chociaż ta lekcja może wydawać się prostsza niż inne, odgrywa kluczową rolę w tworzeniu aplikacji, które są zarządzalne, skalowalne i łatwe w utrzymaniu.

Tim wyjaśnia, że planowanie przeglądowe nie dotyczy funkcji ani pisania kodu. Chodzi o zrozumienie, jak aplikacja będzie działać jako całość, jak użytkownicy będą z nią wchodzić w interakcje i jak deweloperzy powinni podejść do jej budowania.

Przegląd pytań interesariuszy

Tim wyjaśnia, że zanim pójdzie dalej, musi ponownie przejrzeć 15 pytań zadanych w poprzedniej lekcji. Te pytania były zaprojektowane, aby zebrać dodatkowe informacje od interesariuszy - osób żądających aplikacji. Tim symuluje realny scenariusz, w którym programista wraca do interesariuszy, zadaje pytania wyjaśniające i zbiera bardziej szczegółowe odpowiedzi.

Zwraca uwagę, że ten proces odzwierciedla rzeczywiste środowiska biznesowe. Deweloperzy często muszą zadać wiele pytań i doprecyzować wymagania, ponieważ użytkownicy nie zawsze wiedzą, jak opisać to, czego chcą, w kategoriach technicznych.

Zmienne liczby graczy i rozmiar turnieju

Tim zaczyna przegląd odpowiedzi, wyjaśniając, że aplikacja musi wspierać zmienną liczbę graczy. Śledzenie turnieju nie powinno być ograniczone do stałej liczby. Niezależnie czy są dwóch zawodników czy znacznie więcej, aplikacja musi sobie z tym poradzić.

Wymóg ten bezpośrednio wpływa na funkcjonalność aplikacji, struktury danych i logikę. Tim wyjaśnia, że deweloperzy nie mogą zaprogramować na ślepo założeń dotyczących liczby graczy. Zamiast tego aplikacja musi dynamicznie zarządzać użytkownikami i grami w oparciu o to, ilu uczestników jest wprowadzonych.

Obsługa przydziałów w niedoskonałych turniejach

Tim wyjaśnia, że turnieje nie zawsze będą miały idealną liczbę graczy. Gdy całkowita liczba nie dzieli się równo, aplikacja musi przyznawać przydziały. W tym momencie Tim podkreśla ważną zasadę: przydziały muszą być przydzielane losowo.

To wprowadza jeden z powracających potrzeb technicznych aplikacji - losowość. Aplikacja musi uczciwie zarządzać użytkownikami poprzez losowy wybór, kto przechodzi dalej bez grania. To wymaganie kształtuje późniejsze decyzje dotyczące narzędzi, logiki i wydarzeń w aplikacji.

Losowe porządkowanie graczy

Tim kontynuuje wyjaśniając, że kolejność, kto gra z kim, powinna być również losowa. Aplikacja nie powinna polegać na kolejności wprowadzania użytkowników. Po dodaniu wszystkich graczy, aplikacja losuje listę.

To zapewnia uczciwość i unika uprzedzeń. Tim jasno daje do zrozumienia, że losowość to zasada, a nie opcjonalna funkcjonalność. Staje się to częścią podstawowych zasad aplikacji i musi być przestrzegana przez cały rozwój.

Elastyczne planowanie gier

Tim wyjaśnia, że gry nie są planowane przez system. Gracze mogą grać, kiedy chcą. Jednak aplikacja nadal egzekwuje zasady. O 3:04, Tim wyjaśnia, że każda runda musi być ukończona, zanim wyświetlona zostanie następna runda.

To wymaganie wpływa na to, jak aplikacja śledzi gry, zarządza danymi i wywołuje zdarzenia. Aplikacja musi wiedzieć, kiedy runda jest zakończona i zapobiegać użytkownikom przedwcześnie dostępu do późniejszych rund.

Skalowanie i elastyczność danych

Tim wyjaśnia, że system powinien przechowywać prosty, liczbowy wynik. To sprawia, że aplikacja jest wystarczająco elastyczna, aby obsługiwać różne typy gier. Czy to warcaby, koszykówka lub inna konkurencja, ta sama aplikacja może zarządzać wynikami.

Ta decyzja wpływa na to, jak dane są zbierane, przechowywane i wyświetlane. Utrzymując wynikowanie w prostocie, programiści unikają zamykania aplikacji na jeden konkretny typ gry.

Wybór interfejsów użytkownika z myślą o przyszłości

Tim wyjaśnia, że aplikacja będzie aplikacją desktopową używającą Windows Forms - na razie. Jednak podkreśla, że interesariusze mogą chcieć, aby ta sama aplikacja rozwijała się w kierunku platformy webowej lub mobilnej później.

Z tego powodu Tim wyjaśnia, że programiści muszą oddzielić interfejsy użytkownika od logiki biznesowej. O 4:41, wyjaśnia, że podstawową funkcjonalność należy umieścić w bibliotece klas, aby różne interfejsy użytkownika można było zintegrować później bez przepisywania aplikacji.

Przechowywanie danych i strategia integracji

Tim wyjaśnia, że dane powinny być idealnie umieszczane w Microsoft SQL Server, ale aplikacja musi również obsługiwać alternatywę z plikiem tekstowym. To zapewnia, że aplikacja działa nawet wtedy, gdy niektóre narzędzia lub usługi są niedostępne.

Ta decyzja wpływa na sposób, w jaki programiści piszą kod do dostępu do danych. Tim wyjaśnia, że integracja musi być elastyczna, aby ta sama aplikacja mogła przechowywać i pobierać dane z różnych źródeł bez łamania funkcjonalności.

Opłaty za wpis, nagrody i rzeczywista niejasność

Tim wyjaśnia, że interesariusze często dostarczają niejasnych odpowiedzi. Początkowo odpowiedź na pytanie, czy aplikacja obsługuje opłaty za wpis i nagrody, jest po prostu "tak". Tim wyjaśnia, że programiści muszą głębiej wniknąć, aby zrozumieć, co to oznacza.

Następnie określa sprecyzowane wymagania: turnieje mogą pobierać opłaty za wpis, przyznawać nagrody na wiele miejsc i zapewniać, że wypłaty nigdy nie przekraczają dochodów. Wyjaśnia także scenariusze związane z wypłatami procentowymi i zbiórkami funduszy.

Ta sekcja pokazuje, jak planowanie przeglądowe aplikacji pomaga programistom przewidzieć rzeczywiste zasady biznesowe bez przekombinowania aplikacji.

Raportowanie i wyświetlanie wyników

Tim wyjaśnia, że raportowanie powinno być proste. Aplikacja musi wyświetlać wyniki rund i ostateczne wyniki, w tym kto wygrał i ile wygrał. Raporty mogą być wyświetlane na formularzach lub wysyłane e-mailem.

To unika budowania skomplikowanego systemu raportowania, jednocześnie spełniając oczekiwania użytkowników. Skupienie pozostaje na funkcjonalności, a nie na niepotrzebnych funkcjach.

Uzyskiwanie dostępu użytkowników i prostota

Tim wyjaśnia, że każdy korzystający z aplikacji może wprowadzać wyniki gier. W aplikacji nie ma różnych poziomów dostępu. To upraszcza tworzenie aplikacji poprzez unikanie kont, haseł i warstw zabezpieczeń.

Wyjaśnia, że w praktyce aplikacja może być na urządzeniu administratora, podczas gdy inni użytkownicy komunikują się tylko przez e-mail.

Powiadomienia e-mail i automatyzacja

Tim podkreśla, że funkcjonalność e-mail jest kluczowa. Aplikacja musi automatycznie powiadamiać użytkowników o nadchodzących meczach i wynikach rund. Wymaga to od programistów zrozumienia integracji e-mail i automatyzacji na wczesnym etapie procesu projektowania.

Tim zauważa, że to wymaganie pojawia się wielokrotnie, co sygnalizuje jego znaczenie.

Wspieranie zespołów i użytkowników grupowych

Tim wyjaśnia, że aplikacja musi wspierać zespoły, a nie tylko jednostki. Wszyscy członkowie zespołu są traktowani jednakowo i otrzymują te same e-maile. Zespoły muszą również mieć nazwy.

To wpływa na to, jak użytkownicy są grupowani, jak strukturyzowane są dane i jak wydarzenia uruchamiają powiadomienia.

Określanie szerokiego projektu

Tim wprowadza pojęcie szerokiego projektu, używając analogii malarskiej. Wyjaśnia, że ten etap definiuje granice, a nie szczegóły. O godzinie 18:48 przedstawia strukturę: aplikacja Windows Forms, biblioteka klas, SQL lub plik tekstowy do przechowywania danych i jeden aktywny użytkownik na raz.

Te granice zapobiegają dryfowaniu programistów do niepotrzebnych decyzji później.

Identyfikowanie kluczowych koncepcji dla programistów

Tim wyjaśnia, że programiści powinni zidentyfikować kluczowe koncepcje, które mogą wymagać zgłębienia. Wymienia e-mail, SQL, zdarzenia niestandardowe, obsługę błędów, interfejsy i losowe porządkowanie.

Wyjaśnia, jak niestandardowe zdarzenia mogą być używane do wykrywania ukończenia rundy i wywoływania funkcjonalności, takiej jak e-maile.

Pomysły dodatkowe, które nie łamią wymagań

Tim wprowadza tekstowanie jako możliwe przyszłe ulepszenie. Wyjaśnia, że dodatkowe funkcje są akceptowane tylko wtedy, gdy nie zmieniają podstawowych wymagań ani nie opóźniają dostawy.

To wzmacnia znaczenie respektowania zasad ustalonych podczas planowania przeglądu.

Podsumowanie i kolejne kroki

Tim kończy swoje wideo podsumowując proces: pytania interesariuszy prowadzą do wymagań, wymagania prowadzą do projektu przeglądu, a projekt przeglądu ujawnia kluczowe koncepcje. Wyjaśnia, że następna lekcja skupi się na projektowaniu danych, mapując, jak informacje pasują do siebie.

Ta lekcja pokazuje, jak staranne planowanie przeglądu pomaga programistom tworzyć usystematyzowane, elastyczne i łatwe w utrzymaniu aplikacje — zanim zostanie napisana jedna linia kodu.