admin 0Comment

Pamiętam jak, jeszcze nie tak dawno temu, wyglądało moje początkowe podejście do rozwiązywania programistycznych problemów. Przerabiałem wtedy mój pierwszy kurs programowania w języku Python a ćwiczenie kończące każdy rozdział było związane z napisaniem praktycznego skryptu lub skryptów (nawiasem mówiąc, jako, że autor nie podawał własnych propozycji rozwiązań, przedstawiam moje w tej serii wpisów). Do każdego z zadań podchodziłem tak, by jak najszybciej zacząć klepać sam kod, co bardzo często wpędzało mnie w programistyczną ślepą uliczkę i oznaczało konieczność rozpoczynania kompletnie od nowa. I świetnie, że tak to wyglądało, ponieważ pozwalało mi to przekonać się na własnych błędach, że programowanie to nie tylko pisanie samego kodu, ale równie ważnym (o ile nie ważniejszym!) elementem jest faza planowania naszej aplikacji.

Zdecydowanie nie chciałbym popełnić ponownie tego błędu przy okazji mojego projektu realizowanego w ramach DSP 2017. Tutaj kwestia ta jest szczególnie ważna, jako, że framework, którym będę się posługiwał (czyli Django) także nie jest mi znany. To właśnie praca nad aplikacją yourFinance ma pomóc mi poznać to narzędzie.

Nie mam więc zamiaru śpieszyć się z klepaniem w klawiaturę. Chciałbym działać zgodnie z kilkoma uniwersalnymi zasadami.

 

Tworzę ogólną strategię i staram się nie wyważać już otwartych drzwi

 

Najpierw szukam odpowiedzi na najbardziej ogólne pytania. Zastanawiam się nad samą strategią tworzenia projektu – czy powinienem zająć się konkretnymi elementami – funkcjonalnościami programu osobno i dopiero pod koniec starać się je połączyć, czy też tworzyć kolejne wersje programu małymi krokami, ale tak, aby w każdym momencie mieć funkcjonującą aplikację? Sięgam także po gotowe rozwiązania, i nie mam tutaj na myśli tylko przeklejania już napisanego kodu – skoro tworzę konkretne narzędzie, służące do gromadzenia informacji o budżecie użytkownika i podstawowej analizy to warto też rozejrzeć się w sieci jak wyglądają tego rodzaju aplikacje. Może w ten sposób trafię np. na funkcjonalność, o której sam nie pomyślałem, a którą chętnie umieszczę we własnym programie?

 

Opisuję działanie programu od strony użytkownika

 

Nie ma sensu rzucać się do klepania kodu, nie zastanowiwszy się najpierw, jak program będzie prezentował się przyszłemu użytkownikowi. To jak wygląda interface, będzie wpływało na projektowanie klas i wybór konkretnych rozwiązań oraz zarządzanie wyjątkami, wynikającymi z niewłaściwych działań użytkownika.

Krok po kroku, planuję jak ma wyglądać każda z dostępnych opcji działania. Jakich danych wejściowych oczekują od użytkownika i jakie dane (oraz w jaki sposób) mają być wyświetlane? Oczywiście w trakcie pisania mojego programu przynajmniej część z tych założeń zostanie zmieniona, tym niemniej warto mieć już na początku obraz tego, jak aplikacja ma funkcjonować w praktyce.

 

Dzielę „problem” na mniejsze „podproblemy” i opracowuję strategie ich rozwiązywania

 

Stworzenie funkcjonującej aplikacji przy użyciu narzędzia, którego jeszcze nie znam jest dość przytłaczającym zadaniem, jeśli spojrzeć na nie całościowo. Na szczęście każde duże zadanie jesteśmy w stanie podzielić na serię mniejszych, nad którymi łatwiej się pracuje, i realizować je po kolei. Kluczem jest właściwe zidentyfikowanie tych „podproblemów” oraz określenie, jakie konkretne pytania stoją za każdym z nich. W moim przypadku mogą to być m.in. takie kwestie jak logowanie, rejestracja użytkownika, sposób zapisu danych oraz sposób ich wyświetlania czy w końcu zakres i miejsce, w którym użytkownik może dokonywać ich modyfikacji.

 

Zastanawiam się, jakie konkretne rozwiązania wdrożyć, biorąc pod uwagę ich plusy i minusy 

 

Na przykład – wiem, że bazą dla danych odpowiadających miesięcznemu budżetowi użytkownika będą obiekty, posiadające konkretną informację o zgromadzonej w nich sumie (może to być np. „portfel”, „konto bankowe” czy inna przysłowiowa „skarpeta”). Każdy z tych obiektów należy umiejscowić w konkretnym miesiącu i roku, jeśli chcemy operować zmianami w naszych finansach w tych przedziałach. Muszę zastanowić się między innymi, w jaki sposób powiązać te informacje. Czy konkretne miesiące i lata mają także być obiektami? Czy może obiekty gromadzące sumy powinny po prostu posiadać pola wartości DateTime, i na nich powinienem operować, wyszukując konkretne informacje? Te, i wiele innych pytań muszę zadać sobie na samym początku a potem postarać się sobie wyobrazić, jak konkretna decyzja wpłynie na pisanie programu w dalszej części i jakich ewentualnych zysków (oraz zagrożeń) mogę się spodziewać po moich  konkretnych decyzjach.

 

Godzę się z tym, że program nie będzie idealny 🙂

 

Nie wszystko da się (a nawet powinno) zaimplementować od razu. Wiem też, że końcowy kod będzie trzeba refaktoryzować. I super, byleby nie robić tego w nieskończoność. Klucz tutaj to nauka i doświadczenie wynikające z tworzenia tej aplikacji. Nastawiam się na to, że po drodze wejdę i w kilka programistycznych ślepych zaułków ale, tak długo jak w każdej z takich sytuacji będę w stanie się czegoś nauczyć, nadal nie będzie to czas stracony.

Uogólniając – nie ma sensu rzucać się od razu na głęboką wodę i zaczynać od pisania kodu. Masz pomysł na konkretny projekt? Siądź nad nim i pogłówkuj, zastanów się, i spisz to, jak widzisz jego działanie w praktyce a nawet więcej, jak powinna wyglądać struktura klas, jakie rozwiązania powinieneś zastosować. To zdecydowanie lepsze niż kilkukrotnie zaczynać i przy okazji tracić zapał do rozwijania własnego pomysłu.

Dodaj komentarz