Cześć!

Witam Cię, w środowy dzień. Jest to jeden z dwóch postów, które powstaną w tym tygodniu. Czas się zabrać za naszą aplikację.

Od czego by tu zacząć? Może siądziemy od razu do kodu? Nic z tych rzeczy.

Oczywiście są różne podejścia do tworzenia aplikacji. Działka, która się tym zajmuje nazywa się Inżynierią Oprogramowania. Jest to bardzo, bardzo ciekawa nauka z dziedziny informatyki, która zajmuje się wszystkimi fazami cyklu życia oprogramowania. Samo pisanie kodu, to tylko fragment tego cyklu (tak, część z Was, która programowanie miała w szkole/na studiach etc. jako tylko przedmiot jeden z wielu, pewnie się zdziwi, a ludzie, którzy trochę bardziej zawodowo zajmują się oprogramowaniem wiedzą to doskonale i wiedzą również, jak życie weryfikuje założenia, o czym będzie kiedy indziej). Oprogramowanie jest produktem takim samym jak… nie wiem, masło, samochód czy krzesło. (Co to za herezje!) Ma spełniać określone potrzeby techniczne, społeczne i ekonomiczne, dlatego ważnym jest, by zaplanować to, jakie funkcjonalności ma dostarczać, do czego ma służyć, z jakich komponentów będzie zbudowane itd. itd. Ważne też jest, że nauka ta powstaje niejako od tyłu, tzn. nie siada sobie grupka ludzi i mówi dzisiaj sobie coś wymyślimy, tylko stanowi esencję najlepszych i najbardziej efektywnych praktyk stosowanych podczas aktualnie rozwijanych przedsięwzięć informatycznych. Podejście od teorii do praktyki w tym przypadku całkowicie spaliło na panewce.

Zatem zagłębiając się w ten temat możemy uniknąć popełniania błędów przy tworzeniu własnych rozwiązań, tak naprawdę nie tylko z branży IT, bo wiele z tych praktyk da się przetransformować na inne zawody lub dziedziny życia.

Czy skoro jest to takie idealne, to nasze oprogramowanie będzie bezbłędne? Oczywiście, że nie. Tak po prostu się nie da. Ale da się zminimalizować ich wystąpienia. Da się zoptymalizować sam proces wytwarzania oprogramowania. Czy to dużo, czy mało? Fajnie jest o tym pomyśleć.

Skoro inżynieria oprogramowania rozrosła się tak bardzo, to z jakich jej dobrodziejstw ja skorzystam podczas tworzenia MagazineManager’a? Przede wszystkim zastosuję coś, co zwie się modelem wodospadowym lub kaskadowym  wytwarzania oprogramowania. Model ten, dzieli się na fazy takie jak:

  1. Faza określenia wymagań – to jest to, co będziemy robić już następnym razem, tzn. wytworzymy sobie dokument zawierający informację na temat celi jakie chcemy poprzez ten projekt osiągnąć oraz wymagań, jakie postawię przed tworzonym oprogramowaniem.
  2. Faza projektowania – bardzo szczegółowo określimy strukturę wewnętrzną systemu.
  3. Faza implementacji – coś co tygryski lubią najbardziej, czyli w końcu posiedzimy przy kodzie!
  4. Faza testowania – co tu dużo komentować, jak się coś zrobiło no to trzeba zrobić rozruch systemu i zobaczyć czy działa.
  5. Faza konserwacji – ta faza trwa chyba najdłużej, tzn. poprawiamy to, co przestało działać kiedy produkt poszedł do klienta.

Niby takie proste, jasne i logiczne, ale ile razy każdy z nas wpadł w takie sidła, że usiadł, zrobił coś tak od strzału i nagle na koniec nie działa/działa tragicznie/nie spełnia wymagań/jest tak źle zrobione, że nie da się tego w prosty sposób poprawić czy rozwinąć (niepotrzebne skreślić).

Wadami tego systemu jest to, iż błędy popełnione w pierwszych fazach, silnie oddziałują na kolejne etapy rozwoju, przez co ich poprawianie może być drogie (jeżeli mówimy o komercyjnych projektach). Zaletą przede wszystkim łatwość monitorowania tego procesu. Głównie model ten wykorzystywany jest w projektach, które są bardzo ważne i rzadko zmieniają się zachcianki klienta.

Ciekawostką jest też to, że zapętlając punkty 1. do 4. otrzymujemy model spiralny, też często używany. Łatwo buduje się w ten sposób nowe wersje systemu, dodaje kolejne funkcjonalności. Klient ma większy wpływ na bieżący rozwój oprogramowania, przez co zmiana zdania czy wykrycie błędu jest zdecydowanie tańsze. Poza tym pozwala na dopracowywanie projektu. Znaczenie poszczególnych faz jest nieco inne, ale to raczej temat na inny post. Gdzie na przykład stosowany jest tego typu metoda? Hmm… A którą teraz mamy wersję Volkswagena Golfa? VII czy VIII? 🙂

Ktoś może zadać pytanie, czy to projektowanie rzeczywiście jest tak ważne? TAK! Powszechnie twierdzi się, że sama faza projektowania powinna zabierać ok. 70% a nawet 80% czasu rozwoju całego projektu. Lepiej przemyśleć coś 1001 razy niż o raz za mało.

Dobra czas kończyć chyba to pisanie. Tak będzie wyglądał początek zabawy z MagazineManager’em i w sumie z Daj się poznać 🙂 Może wydawać się to nudne, jednak mam nadzieję pokazać wam, jak bardzo takie rzeczy są potrzebne! Osoby bardziej doświadczone, mogą się podzielić własnymi doświadczeniami czy wiedzą!

Zachęcam gorąco do zagłębienia się w temat inżynierii oprogramowania, myślę, że wiele osób świetnie się tu odnajdzie i wyniesie dużo ciekawych wniosków.

A może…?

Dziękuję Ci, że dotartłeś aż do tego miejsca. Mam nadzieję, że podobał Ci się mój wpis i dowiedziałeś się z niego czegoś wartościowego. Jeżeli chcesz być poinformowanym o moich kolejnych wpisach bądź od czasu do czasu dostać wiadomość ze zbiorem jakiś ciekawych linków, zapisz się proszę do mojego newslettera. Będzie mi niesamowicie miło, jeśli to zrobisz i dołączysz do mojej społeczności!


Piotr Wachulec

Student, konsultant IT/programista, bloger, w wolnych chwilach uczy się nowych rzeczy, tańczy bachatę lub pije pyszną kawę ze znajomymi (chętnie się jej napije także z Tobą! :)). Często można go spotkać na konferencjach, meetupach lub po prostu biegnącego po stolicy na tramwaj. Jego piątka w "teście" Gallupa: Learner, Achiver, Intellection, Relator, Harmony.