Jak kończyć projekty ?

Wstęp

Spis treści
Wstęp
      Projekt
Filozofia programowania
      Podział programowania
      Początkujący a zaawansowani
      Natura hakera
      Programowanie jako praca twórcza
      Kończenie projektów
Projektowanie
      Inżynieria oprogramowania
      Podejmowanie decyzji
      Formy projektowania
      Etapy projektowania
      Jak projektować?
Programowanie
      Programowanie a projektowanie
      Co trzeba umieć?
      Jak programować?
      Kod
      Komentarze
      Dokumentacja
      Kopie bezpieczeństwa
Testowanie
      Szukanie błędów
      Testy
      Optymalizacja
Zakończenie
Literatura

• Jeśli jesteś początkującym, który dopiero poznaje podstawy programowania, nawet jeśli zrozumiesz ten artykuł (nie powinno ci to sprawić problemu), raczej nie będziesz w stanie zastosować podanych tu rad w praktyce. Aby pisać programy, musisz już umieć programować na tyle, żeby elementarne problemy techniczne nie były dla ciebie przeszkodą.
• Jeśli jesteś zawodowym programistą po studiach informatycznych i uczyłeś się inżynierii oprogramowania na zajęciach w sposób systematyczny, z pewnością wiesz o tym więcej niż ja. Jeśli ponadto masz za sobą długą praktykę w programowaniu, potrafisz tą wiedzę doskonale zastosować.
• Jeżeli jesteś programistą pracującym dla firmy i zarabiasz na programowaniu, zupełnie inna jest twoja sytuacja, zupełnie inne są warunki, w jakich pracujesz, a także zupełnie inna jest twoja motywacja. Projektowaniem i programowaniem nierzadko zajmują się w firmach zupełnie różne osoby. Opisane tu problemy po prostu cię nie dotyczą.

Filozofia programowania

• Nauka - jest wtedy, kiedy bawisz się w ucznia, czyli poznajesz nowe języki i biblioteki, czytasz kursy i dokumentacje, nabywasz doświadczenie i oswajasz się z nowym środowiskiem, w których chcesz pracować.
• Eksperymentowanie - jest wtedy, kiedy bawisz się w naukowca, czyli pracujesz nad jakimś zakręconym pomysłem, który ma małe szanse przynieść bardzo dobre efekty (chyba że masz naprawdę dużą wiedzę na dany temat) - np. praca nad własnym formatem plików graficznych, nad sztuczną inteligencją i innymi tematami, które cię fascynują.
• Pisanie programów jest wtedy, kiedy bawisz się w zawodowego informatyka i korzystając z dobrze już znanej, ugruntowanej wiedzy robisz coś, co chcesz dobrze zaprojektować i napisać, aby mieć na swoim koncie ukończoną produkcję.

1. Lektura kursów, aby wstępnie poznać i zrozumieć dany temat.
2. Przejrzenie i potem korzystanie z oficjalnej dokumentacji.

• Posiadanie na swoim koncie ukończonego programu czy gry to ogromna satysfakcja.
• To także coś, co jest w miarę trwałe - pozostaje nawet kiedy ty już o tym zapomnisz i weźmiesz się za następny projekt, może ci przynieść prestiż i popularność.
• Ukończona produkcja to coś, co reprezentuje ciebie, co możesz zamieścić na swojej stronie WWW.
• Wreszcie, ukończona i dostępna do użytku aplikacja po prostu może się komuś przydać - program może się okazać użyteczny, a gra może dostarczyć ludziom rozrywki.

1. Zdarza się, że rozpoczynamy projekt zbyt ambitny - tak duży i tak wymagający, że nie jesteśmy w stanie go zrealizować.
2. Zdarza się, że w pewnym momencie brakuje nam wiedzy, umiejętności i doświadczenia, by zrealizować jakąś rzecz, a w konsekwencji by kontynuować i ukończyć rozpoczęty projekt.
3. Zdarza się, że pisanie danego programu staje się nudne - okazuje się dużo mniej ciekawe, niż wcześniej było myślenie i marzenie o nim, projektowanie go itp. Czas także działa tu na naszą niekorzyść.
4. Zdarza się, że wpadamy na nowy, dużo lepszy i ciekawszy pomysł i natychmiast rozpoczynamy jego realizację porzucając poprzedni.
5. Zdarza się, że rozpoczynamy pisanie podczas gdy sami do końca nie wiemy, co to ma być, jak ma wyglądać i jak ma działać.
6. Zdarza się, że piszemy niczego wcześniej nie projektując, nie planując i okazuje się, że nie wiemy, jak nasze zadanie ma zostać zrealizowany, jak program ma być zbudowany. Czasami nawet nie potrafimy go zaprojektować, nie mamy na niego żadnej koncepcji.
7. Zdarza się, że pisząc jakiś moduł chcemy uczynić go zbyt elastycznym, skalowalnym i uniwersalnym, a w konsekwencji piszemy go długo lub w ogóle go nie kończymy.
8. Zdarza się, że w programowaniu przeszkadzają niesprzyjające czynniki zewnętrzne, jak rodzice, rodzeństwo czy szkoła. Najczęściej po prostu opóźniają pisanie, co może mieć jednak bardzo zły wpływ na powodzenie projektu.

Projektowanie

Faza strategiczna

Polega na podjęciu decyzji dotyczącej tego, co pisać.

Faza określania wymagań

Polega na określeniu wymagań, jakie ma spełniać program.

Faza analizy (modelowania)

Polega na określeniu, jak program ma działać, żeby spełniał postawione mu wymagania.

Projektowanie

Polega na zaprojektowaniu implementacji programu, czyli zaplanowaniu, jak będzie wyglądał jego kod (podział na moduły, klasy, funkcje itp.).

Implementacja

Polega na napisaniu programu - to jest sedno programowania.

Dokumentacja

Odbywa się równolegle z innymi fazami i polega na sporządzeniu dokumentów opisujących tworzony program.

Testowanie

Polega na znalezieniu i usunięciu błędów.

Instalacja

Polega na przekazaniu systemu końcowemu użytkownikowi.

Konserwacja

Polega na dalszym poprawianiu programu, pisaniu kolejnych wersji itp.

Czy swoją grę powinienem pisać w 3D?

Na prawej ręce odliczam zalety:
1. Gra będzie ładniejsza, bardziej atrakcyjna
2. Nauczę się przy okazji 3D

Na lewej ręce odliczam wady:
1. Będę się musiał nauczyć 3D...
2. ...To będzie trudne...
3. ...Pisanie potrwa dłużej...
4. ...Mniejsze są szanse, że to skończę

Decyzja: Więcej jest wad, piszę grę dwuwymiarową!

Tabelka ważona

Kiedy czujesz, że taka metoda jest nie w porządku, bo różne argumenty mają różne znaczenie, czas na przypisanie im współczynników wagowych. Tabelka ważona jest trochę trudniejsza, ale często się przydaje i dlatego postaraj się ją dobrze zrozumieć. Najpierw popatrz na przykład, a następnie przeczytaj objaśnienie poniżej.

Najpierw wypisałem w trzech kolumnach trzy opcje, między którymi mam dokonać wyboru - Konsola tekstowa, Windows GDI oraz DirectX. Potem w kolumnie Zagadnienie wypisałem wszystkie 4 ważniejsze kryteria, według których będę oceniał każdą z tych opcji.

Dla każdego zagadnienia każdej opcji przyznaję pewną liczbę punktów. Zagadnienia są sformułowane tak, żeby zawsze więcej punktów przemawiało na korzyść, a nie na niekorzyść danego wyboru. Jako przykład rozpatrzmy zagadnienie Jaki ładny. Każde rozpatrywane API graficzne oceniam w nim pod względem tego, jak atrakcyjną grafikę można moim zdaniem za jego pomocą prezentować. API, w którym grafika wygląda najgorzej (czyli Konsola tekstowa) dostaje 0 punktów, a API, w którym mogę przygotować najbardziej efektowną grafikę - maksimum, czyli 10 punktów. Pozostałe, trzecie API (Windows GDI) plasuje się gdzieś między nimi, a ponieważ w porównaniu z trójwymiarowymi możliwościami DirectX wypada bardzo blado, otrzymuje ostatecznie 2 punkty.

Po wypełnieniu tabelki czas na przypisanie wag poszczególnym zagadnieniom. Posłużyła mi do tego ostatnia kolumna zatytułowana Waga. Najważniejsza jest dla mnie prostota danego API, więc te spawa otrzymuje maksymalną wagę - 10. Pozostałe są bardziej albo mniej ważne i otrzymują różne wagi mniejsze od 10. Żadne zagadnienie nie może otrzymać wagi 0 chyba, że zupełnie nie powinno się liczyć do końcowego wyniku (ale wtedy po co w ogóle je pisać?).

Wreszcie czas na obliczenia. Ponieważ mamy zdecydować się na jedną z trzech rozpatrywanych opcji, musimy podliczyć sumę punktów osobno każdej z nich. Robimy to mnożąc każdą liczbę w kolumnie przez wagę zagadnienia w danym wierszu i dodając te wyniki do siebie. Na przykład Windows GDI ma w wierszu pierwszym (zatytułowanym Jak prosty) wartość 6, a waga tego zagadnienia to 10, więc po pomnożeniu wychodzi 60. W ten sam sposób liczymy pozostałe wiersze dla tej opcji i ostatecznie liczba punktów Windows GDI to:

6*10 + 0*5 + 2*7 + 1*3 = 60 + 0 + 14 + 3 = 77

Projekt gry
         ==
________________
Założenia główne

- ma być ładna
- grywalna
- dynamiczna
- dużo krwi

Listy

- intro
  Jakiś fajny, cząsteczkowy efekt graficzny
- menu
  > Wróć do gry (tylko jeśli gra trwa)
  > Nowa gra
  > Otwórz grę
  > Zapisz grę (tylko jeśli gra trwa)
  > Credits
  > Opcje
  > Wyjście
    Tutaj pytanie: Czy na pewno chcesz wyjść?
- ekran zapisywania i otwierania gry
  > lista zapisanych gier
  > pole do wpisania nazwy
  > przycisk OK
  > przycisk Anuluj
- Opcje
  > wybór rozdzielczości
  > wybór częstotliwości odświeżania

Listy TODO

W pliku tekstowym

Zmienić punktatorek (na v jeśli dana pozycja została zrealizowana lub ma x, jeśli zrezygnowałeś z jej realizacji) albo po prostu wykasować linijkę z danym punktem listy.

Na kartce

Postawić ptaszek lub krzyżyk obok pozycji listy, wykreślić jej punktatorek albo w ogóle przekreślić całą treść punktu.

• Od rzeczy najprostszych do zrobienia do najtrudniejszych.
• Od najbardziej niezbędnych do tych dodatkowych, nad których sensem jeszcze trzeba będzie się zastanowić.
• Od najpilniejszych do tych, którymi można się będzie zająć później.
• Od najważniejszych do najmniej istotnych.

Formy graficzne

Kiedy tekst nie wystarcza, trzeba użyć jednej z graficznych form projektowania. Do wszystkich ich wygodniej jest moim zdaniem używać kartki papieru i długopisu, niż programów graficznych na komputerze.

Schematy i diagramy

Tabele

Okno główne

Mapy myśli

Etapy projektowania

Wracamy jeszcze raz do inżynierii oprogramowania, by omówić niektóre fazy powstawania programu. Sama świadomość, że program przed napisaniem trzeba najpierw zaprojektować i umiejętność tego projektowania nie wystarcza. Jeśli będziesz chciał zaprojektować większy program wystarczająco dobrze, może się okazać, że samo to projektowanie jest zadaniem bardzo trudnym.

Dlatego warto robić je sobie na kolejne etapy. Chociaż nie musisz kończyć każdego z nich spisaniem formalnego dokumentu, powinieneś być świadomym tego podziału, by za każdym razem wyobrazić sobie te etapy i przejść przez nie - poświęcając każdemu z nich przynajmniej chwilę namysłu czy jedno zdanie na kartce.

Faza strategiczna

To jest faza, w której podejmujesz decyzję, co pisać. To najważniejsza decyzja w całym projekcie. Możliwe, że wybór odpowiedniego pomysłu to właśnie ten moment, który ma decydujący wpływ na szanse ukończenia projektu. Tylko jak go dokonać? Jeżeli masz naturę hakera, z pewnością codziennie przychodzi ci do głowy wiele pomysłów. Nigdy nie będziesz w stanie napisać ich wszystkich i dlatego musisz wybrać te najlepsze.

Po pierwsze - nigdy nie zaczynaj pisania pochopnie. Każdym nowym pomysłem jesteśmy tak podekscytowani, że w pierwszej chwili wydaje się być wręcz genialny. Dopiero po pewnym czasie okazuje się, czy jest naprawdę bardzo dobry, przeciętny, czy może całkiem głupi. Dlatego moja rada jest taka: z rozpoczęciem pisania zawsze poczekaj do następnego dnia. Trzeba najpierw przespać się z problemem. To daje dostatecznie dużo czasu, by emocje opadły, a pomysł został przynajmniej wstępnie, racjonalnie przemyślany. Kiedy wieczorem i rano składasz pościel, myjesz się, jesz itp. to być może jest jedna z nielicznych chwil w ciągu dnia, kiedy twój umysł nie jest niczym zajęty i może spokojnie pomyśleć nad tą sprawą, choćby podświadomie.

Być może masz takie pomysły, które chodzą ci po głowie od dawna, często o nich myślisz i co jakiś czas wracasz do nich. Ja takie mam i wiem, że najlepiej jest właśnie je wybierać do realizacji. Na przykład jeśli wczoraj przyszedł ci do głowy pomysł, żeby napisać tetris, przedwczoraj arkanoid, tydzień temu RPG, ale już od dawna myślisz o napisaniu platformówki, napisz platformówkę. Kiedy wybierasz taki pomysł, jest większa szansa, że pracowanie nad nim dłużej ci się nie znudzi.

Moja trzecia rada jest taka, by wybierać te małe pomysły. Każdy mały program jest duży - będziesz do pisał kilka tygodni, a każdy duży program jest ogromny - będziesz go pisał miesiącami. Dlatego pomyśl wcześniej, czy jesteś gotów przez tak długi czas pracować tylko nad tym, czy nie znudzi ci się, czy nie wpadniesz na lepszy, ciekawszy pomysł? To bardzo prawdopodobne i może stanowić przeszkodę nie do pokonania w realizacji większych projektów nawet, jeśli sama wielkość projektu pod względem technicznym nie stanowiłaby już dla ciebie problemu (dzięki umiejętności projektowania i organizacji kodu).

Powinieneś z góry odrzucać pomysły nierealne. To jasne, że fantastyczne byłoby napisać myślącego choatterbota - ale pomyśl, jak to zrobisz, jeśli nie udało się to jeszcze nawet największym naukowcom? Oczywiście, że super byłoby napisać grę przygodową czy RPG z porywającą fabułą - ale pomyśl, kto ułoży wszystkie plansze i napisze wszystkie dialogi? Będzie ci się chciało? Wiem coś o tym, bo już raz napisałem całą grę RPG, skończyłem kod, a projekt upadł kiedy przekonałem się, ile pracy jest z układaniem wirtualnego świata.

Efektem tej fazy może być na przykład taka notatka:

Faza określania wymagań

Na tym etapie powinieneś określić, jakie wymagania musi spełniać projektowany program. Czy twoja gra będzie miała trójwymiarową grafikę? Czy będzie miała podkład muzyczny? Czy wymaga skomplikowanego menu? Czy powinna umożliwiać zmianę rozdzielczości? Wyobraź sobie ją tak, jakby była już skończona. Najważniejsze, by w tej fazie nie wdawać się w szczegóły implementacyjne.

Takie myślenie dla programisty może być trudne. Jak nie myśleć o programowaniu? Aby to zrobić, spróbuj poczuć się jak użytkownik czy gracz. Potem wyobraź sobie swój program (już skończony) - jego interfejs użytkownika, główne okno programu czy główny ekran gry. Jakie elementy interfejsu użytkownika powinien zawierać? Jaki powinien być, ogólnie i w szczegółach, żeby spełniał oczekiwania? Jakie są w ogóle twoje oczekiwania wobec niego? To są pytania, na które powinieneś szukać odpowiedzi w tej fazie.

Jedynym wyjątkiem od tej zasady, by nie myśleć o samym kodowaniu, jest kontrolowanie cały czas, czy wymyślane oczekiwania nie są dla ciebie nierealne do zrealizowania. Podczas projektowania, szczególnie na tym etapie, bardzo łatwo jest się zagalopować i nawymyślać ogromną ilość fantastycznych, ale bardzo trudnych albo wręcz niemożliwych do napisania elementów. Stawiaj przede wszystkim na takie rozwiązania, które są jednocześnie proste do napisania, a przynoszą bardzo dobry efekt. Nie zapomnij też rozpatrzyć zawsze, które rzeczy są najważniejsze, a z których można zrezygnować albo je ograniczyć.

Efektem tej fazy może być na przykład taka notatka:

Faza analizy

W poprzedniej fazie trzeba się zastanowić, *co* program ma robić, a w tej, *jak* ma to robić - czyli jak zrealizować postawione mu wymagania. Można już zacząć myśleć o szczegółach implementacyjnych i planować, jak napiszesz to wszystko. Często okazuje się, że część planowanych rzeczy trzeba będzie odrzucić.

Pomyśl: Jakich bibliotek użyjesz? Jak ogólnie zorganizujesz swój kod i pracę nad projektem? Jak podzielisz ten proces na etapy, a sam program na moduły? Czy będziesz musiał czegoś nowego się nauczyć - jakiejś biblioteki, jakiejś techniki? Czy jesteś w stanie zrealizować wszystkie założenia? Jak to zrobisz? Tutaj wszędzie pojawiają się decyzje do podjęcia.

Efektem tej fazy może być na przykład taka notatka:

Faza projektowania

Według inżynierii oprogramowania, w tej fazie należy dokładnie zaprojektować kod. W praktyce nie zawsze bywa potrzebna - zwykle wystarczy po prostu usiąść i zacząć pisać polegając tylko na swoim doświadczeniu i intuicji. Czasami jednak, kiedy napisanie jakiegoś modułu wydaje się bardzo trudne, warto wprowadzić ten etap pośredni i pomóc sobie w pisaniu formami, które przedstawię poniżej. Mnie już nie raz pomogły one napisać coś, co wydawało się trudne do ogarnięcia umysłem.

Pseudokod

System dźwiękowy - interfejs
                           =
- void Create() - inicjalizacja systemu
- void Destroy() - finalizacja systemu
- void Load(int ID, string FileName) - wczytanie dźwięku WAVE
- int Play(int ID, bool Loop) - odgrywa dźwięk, zwraca kanał
- void Stop(int Channel) - zatrzymuje dźwięk z podanego kanału
- void SetVolume(int Channel, byte Volume) - ustawia głośność dźwięku

foreach(obj na liście)
  if obj się porusza
    Circle = obj.Ruch
  CircleBackup = Circle
    Stop = false
    foreach (kolidująca ściana, Circle)
      if obj.Collision(ściana)
        Stop = true
    foreach (kolidujący obiekt, Circle)
      if obj.Collision(obiekt)
        Stop = true
      if obiekt.Collision(obj)
        Stop = true
    if Stop
      Circle.x = obj.x
      if JestKolizja(Circle)
        Circle = CircleBackup
        Circle.y = obj.y
        if JestKolizja(Circle)
          obj.vx = 0
          obj.vy = 0
        else
          obj.pos = Circle
          obj.vx = 0
      else
        obj.pos = Circle
        obj.vy = 0
    else
      obj.pos = Circle

Diagramy klas

Diagramy przejść stanów

Inny przykład to diagram stanów dla prostej sztucznej inteligencji potworka w grze. Pokazuje on, że stan nie musi być czymś globalnym dla programu - każdy potworek będzie wykonywał ten algorytm i będzie miał swój własny stan niezależnie od innych.

Podsumowanie

Można powiedzieć, że w pewnym sensie są dwa modele programowania. Pierwszy to taki, w którym przed rozpoczęciem kodowania planuje i projektuje się wszystko dokładnie. Jak dokładnie? - to zależy od wielkości programu. Projektować trzeba wystarczająco szczegółowo, żeby się potem nie pogubić w kodzie. Dużo zależy też od osobistego doświadczenia i umiejętności improwizowania.

Wbrew pozorom ten model oprócz zalet ma też swoje wady. Kiedy programowanie staje się tylko "formalnością", bardzo łatwo przyjąć taką strategię, że realizuje się poszczególne zaplanowane części na "odwal się" jak najszybciej zapominając o nich - bez dobrej optymalizacji, bez dobrego testowania - pozostawia się kod powolny i pełen błędów, w dodatku słabo skomentowany i trudny potem w konserwacji. Trzeba na to uważać.

Drugim podejściem jest pisanie na żywioł - bez żadnego dokładniejsze projektowania. To trochę niemądre, ale ma też swoje zalety. Wiadomo, że trudno wtedy napisać od razu dobrze i trzeba będzie stale coś zmieniać, a niejednokrotnie dużą część kodu napisać zupełnie od nowa. To wymaga więcej czasu i pracy, ale wcale nie jest takie złe - każda nowa wersja jest lepsza, a podczas takiego pisania zdobywa się dużo doświadczenia. Takie pisanie skłania też do dbałości o kod. Kiedy wiesz, że będziesz musiał do niego wracać, bardziej starasz się pisać go czytelnie, z komentarzami itp.

Choć to niezwykłe, taki sposób pomógł mi kiedyś, kiedy nawet solidne projektowanie zawiodło. Chciałem napisać coś, co trudno było ogarnąć i zaplanować. Nie mogłem wymyślić dobrej organizacji tego wszystkiego, więc zacząłem po prostu pisać - i napisałem! Wydaje mi się, że to jednak można racjonalnie wytłumaczyć. Jako programiści pasjonaci jesteśmy tak zżyci z kodem, że łatwiej nam operować na nim niż na abstrakcyjnych schematach.

Jak projektować?

Kiedy już potrafisz dobrze projektować okazuje się, że zaprojektowanie skomplikowanego programu wcale nie jest dużo prostsze od jego napisania. Dlatego na koniec chciałbym udzielić odpowiedzi na pytanie: Jak projektować, żeby to nie było za trudne?

Najtrudniej jest zacząć. Mówią nawet, że kiedy zaczniesz, to zrobiłeś już połowę roboty. Dlatego moja pierwsza rada jest taka: nie spędzaj czasu na "przerażaniu się" - jakie to wielkie i trudne zadanie - tylko wyciągnij kartkę, weź długopis, napisz nazwę swojego programu, dzisiejszą datę itp. - po prostu zacznij. Dopiero potem pomyślisz co dalej a przekonasz się, że dalej już jakoś pójdzie.

Po drugie: podziel swoje zadanie - wzdłuż i wszerz. To oczywiste, że każdy większy projekt jako całość wydaje się nie do ogarnięcia. Dlatego najpierw zaprojektuj go ogólnie, podziel na części (moduły), a dopiero potem przejdź do szczegółów skupiając się zawsze tylko na jednym z nich. Nigdy nie przegap okazji, by jakieś zagadnienie podzielić na części albo na podzagadnienia - wtedy taki problem staje się kilka razy prostszy. Posługuj się listami z punktami i podpunktami. Wypisuj i systematyzuj wszystko, co się da. Po prostu dziel i rządź!

Mówiąc już bardzo abstrakcyjnie możnaby nawet powiedzieć, że organizacja projektowania programu ma strukturę trójwymiarową:

Szerokość

To rozbicie zagadnienia na mniejsze, osobne elementy, które tworzą płaską listę.

Głębokość

To podział zagadnienia na swoje bardziej szczegółowe podzagadnienia, które tworzą hierarchię (drzewo).

Wysokość

To podział procesu projektowania na etapy według inżynierii oprogramowania (faza strategiczna, określania wymagań, analizy, projektowania), które następują kolejno po sobie w czasie.

Programowanie

Język programowania

Z językiem programowania jest trochę tak jak z językami obcymi. Dopóki nie znasz go dobrze, jedyne, co możesz robić, to dalej się go uczyć na jakiś zmyślonych przykładach. Dopiero potem, kiedy potrafisz wyrażać w nim swoje myśli możesz powiedzieć, że potrafisz się nim dobrze posługiwać. Aby dobrze programować, nie musisz znać perfekcyjnie wszystkich sztuczek i drobiazgów swojego ulubionego języka programowania, ale musisz znać go na tyle dobrze, żeby swobodnie wyrażać w nim swoje myśli - czyli implementować swoje pomysły.

Biblioteki

Sam język programowania nie wystarczy. Musisz poznać i nauczyć się używać jakiś bibliotek - np. do tworzenia graficznego interfejsu użytkownika (jak Windows API), do grafiki (jak Windows GDI, DirectX czy OpenGL), do dźwięku (jak DirectAudio czy FMOD), do sieci (jak WinSock czy DirectPlay) itp. - takie, które będą ci potrzebne. Czasami będziesz się musiał nauczyć jakiejś biblioteki specjalnie, by móc zrealizować konkretny projekt.

Matematykę

Tego trudno nauczyć się samemu. Twoja wiedza matematyczna zależy do tego, w jakim jesteś wieku i do jakiej szkoły chodzisz. Dlatego nie zaniedbuj nauki matematyki w szkole, bo to jest na prawdę bardzo ważne w programowaniu.

Myśleć

Programowanie to proces twórczy, wymagający inteligencji, logicznego i abstrakcyjnego myślenia, a także niemałej wiedzy, doświadczenia, kreatywności i intuicji.

Wyszukiwać

Internet (głównie strony WWW) to Wszechnica Wiedzy Wszelakiej, ale z niej też trzeba umieć odpowiednio korzystać. Do rozwiązania niektórych problemów potrzebujesz dodatkowych informacji i musisz umieć je odnaleźć, np. za pomocą wyszukiwarki Google (zamiast od razu biegnąć z pytaniem do bardziej doświadczonego kolegi).

Korzystać z dokumentacji

Nawet najlepszy programista nie zna na pamięć wszystkich funkcji używanych bibliotek, ich nazw ani parametrów, jakie przyjmują. Z kolei bazowanie na kursach (tutorialach) to nienajlepszy pomysł - one mają pomagać w zrozumieniu nowego tematu i opisują tylko niektóre funkcje. Musisz potrafić korzystać z oficjalnych dokumentacji do swojego języka i używanych bibliotek, nie bać się ich. To właśnie tam jest systematyczny, dokładny opis wszystkich funkcji.

// Abstrakcyjna klasa bazowa dla obiektów w grze
class Obiekt {
  // Pozycja na mapie
  int x, y;
public:
  // Klasa jest polimorficzna - wirtualny destruktor
  virtual ~Obiekt();
  // Przesunięcie obiektu (sprawdza kolizje)
  virtual void Move(int NewX, int NewY);
  // Odczytanie pozycji
  int GetX() { return x; }
  int GetY() { return y; }
  // Rysuje obiekt na ekranie
  virtual void Draw() = 0;
};

// Jakiś leżący nieruchomo przedmiot, ozdoba itp.
class Rzecz : public Obiekt {
private:
  int Rodzaj;
public:
  // Konstruktor
  Rzecz(int a_Rodzaj);
  // Rysowanie
  virtual void Draw();
};

// Postać w grze - jakieś żyjątko, które może zginąć
class Postac : public Obiekt {
private:
  int Zycie; // 0..ZYCIE_MAX
public:
  // Konstruktor
  Postac() : Zycie(ZYCIE_MAX) { }
  // Zwraca życie
  int GetZycie() { return Zycie; }
  // Obrazenia dla tej postaci
  // (zwraca true, jeśli nie żyje)
  bool Damage(int x);
};

// Bohater gry - to też rodzaj postaci
class Bohater : public Postac
{
private:
  // Amunicja do broni różnego rodzaju
  int Amunicja[BRONIE_COUNT];
public:
  // Konstruktor
  Bohater();
  // Rysowanie bohatera
  virtual void Draw();
};

// Potworek, czyli wróg gracza
class Potworek : public Postac
{
private:
  int Rodzaj;
public:
  // Konstruktor
  Potworek(int a_Rodzaj) : Rodzaj(a_Rodzaj) { }
  // Rysowanie potworka
  virtual void Draw();
};

// Klasa menadżera obiektów przechowuje kolekcję obiektów,
// zarządza nimi i zwalnia je z pamięci
class ObiektManager {
private:
  std::list<Obiekt*> Lista;
public:
  // Zwalnia wszystkie obiekty z pamięci
  ~ObiektManager();
  // Dodaje do listy utworzony wcześniej obiekt
  void Add(Obiekt *obj);
  // Rysuje wszystkie obiekty
  void Draw();
  // itd...
};

//                                                         =
// Klasy z obiektami gry

// ŹLE!!!
// Dla każdego wiersza...
for (y = 0; y < MAP_HEIGHT; y++) {
  // Dla każdej kolumny...
  for (x = 0; x < MAP_WIDTH; x++) {
    // Odrysowanie pola mapy
    DrawMapCell(x, y, Map[y*MAP_WIDTH+x]);
  }
}

// Odrysowanie całej mapy
for (y = 0; y < MAP_HEIGHT; y++) {
  for (x = 0; x < MAP_WIDTH; x++) {
    DrawMapCell(x, y, Map[y*MAP_WIDTH+x]);
  }
}

// Wczytuje dźwięk z pliku WAVE do pamięci
// Dźwięk zostanie sam zwolniony podczas finalizacji systemu dźwiękowego
// - ID       - identyfikator dla wczytywanego dźwięku
// - FileName - nazwa pliku dźwięku wraz ze ścieżka
// Jeśli się uda, zwraca true
// Jeśli się nie uda, zwraca false i wpisuje komunikat do zmiennej g_ErrMsg
bool Load(int ID, const std::string &FileName);

//----------------------------------------------------------
// Nazwa  : sound
// Wersja : 1.0
// Opis   : Moduł dźwiękowy
// Autor  : Adam Sawicki "Regedit"
// Data   : 2004-09-21
// URL    : mailto:regedit@risp.pl
// URL    : http://www.programex.prv.pl/
//----------------------------------------------------------

/* Rysowanie obramowania przebiega w takich 4 etapach:
    _________________
   |   |____3____|   |
   |   |         |   |
   | 1 |         | 2 |
   |   |_________|   |
   |___|____4____|___|
*/

Format pliku z poziomem do platformówki
                                       

Lokalizacja: Platformówka\Maps\*.map
Pliki binarne

Budowa
------
- nagłowek
- mapa
- liczba obiektów [DWORD]
- obiekt, obiekt, obiekt...

Nagłówek
--------
- łańcuch "Platformówka" (12 B)

Mapa
----
- Szerokość [WORD]
- Wysokość [WORD]
- Rodzaj pola, Rodzaj pola, Rodzaj pola, ... [BYTE]

Obiekt
------
- Typ [BYTE]
  0 = rzecz
  1 = potworek
- x [WORD]
- y [WORD]
Jeśli rzecz:
- Rodzaj rzeczy [BYTE]
Jeśli potworek:
- Życie [int]
- Rodzaj potworka [BYTE]

Testowanie

Beep(1000, 100);

• Konsola systemowa - można ją stworzyć nawet w aplikacji okienkowej za pomocą funkcji AllocConsole().
• Specjalnie stworzone, nowe okno.
• Okno główne programu czy ekran główny gry - informacje loga trzeba wtedy prezentować razem z normalny obrazem.
• Plik tekstowy.

1. Informacje o znalezionych błędach
2. Swoje uwagi, propozycje, pomysły i sugestie

ojProfiler.Begin();
// ...
MojProfiler.End();[

Zakończenie

Literatura

1. "Inżynieria oprogramowania" Andrzej Jaszkiewicz, wyd. Helion, Gliwice 1997
2. "Testowanie oprogramowania" Ron Patton, wyd. Mikom, Warszawa 2002