Extreme Programming


EXtreme Programming
Dr Karol Grudziński


Wydajne Programowane (extreme programming) to
nowe podejście do tworzenia oprogramowania oparte
o najlepsze z technik ze szczególnym
uwzględnieniem prostoty i pracy zespołowej.

XP to ciągłe testowanie i przeglądanie kodu oraz
zaangażowanie klienta w proces tworzenia aplikacji.
Metody XP zostały dobrze przyjęte przez
programistów, jednak ich praktykowanie wymaga
cierpliwości i jest nie lada wyzwaniem. 1
Krótko o Extreme Programming

Gdy programowanie komputerów było nową dziedziną,
czas procesora był bardzo cenny.

Było niewiele komputerów i konkurencja w zyskaniu
dostępu do sprzętu była bardzo duża.

Jeśli istniał błąd uniemożliwiający poprawne działanie
programu, trzeba było czekać dni albo tygodnie, by móc
sprawdzić go ponownie.

Dowolna zmiana programu miała wpływ na cały program.

Aby zaoszczędzić czas i pieniądze należało się upewnić, iż
program jest w pełni sprawny przed umieszczeniem go w
komputerze (sprawdzanie na  sucho ). Sprawdzanie kodu
zajmowało wiele godzin.

A więc wynikała z tego lekcja:
ZMIANA JEST TRUDNA I KOSZTOWNA! 2

Kilka dekad pózniej, Extreme Programming, nazywane w skrócie XP
(wydajne programowanie), stawia wszystko na głowie, gdyż sugeruje
operację całkowicie odwrotną:
Wykonanie wysokiej jakości oprogramowania odbywa się
pomimo, a nawet dzięki ciągłym zmianom.

XP to sposób tworzenia oprogramowania, który kładzie nacisk na
prostotę, reakcję zwrotną, odwagę i komunikację. Stanowi w zasadzie
reakcję na przekonanie, iż zmiana jest zła i można jej uniknąć.

W kilku ostatnich latach tysiące programistów i firm przekonało się, że
XP pomaga im tworzyć lepsze, bardziej niezawodne oprogramowanie
przy mniejszym stresie. Koncepcje XP wpłynęły nawet na słownictwo i
narzędzia wykorzystywane poza zespołami używającymi XP.

Zauważyć można wzmożone zainteresowanie inżynierów
oprogramowania testowaniem i odpowiednimi do tego narzędziami.
3

XP jest doskonałym rozwiązaniem, ponieważ 12 jego
głównych technik polega na sobie i jest ściśle związanych.
Siła jednej z technik neutralizuje słabość innej.

Zrozumienie wartości wydajnego programowania i
związków między technikami umożliwia odniesienie
sukcesu.

XP nadaje się idealnie dla niewielkiej grupy twórców w
firmie piszącej oprogramowanie dla innej firmy 
oprogramowanie dostarcza się często, wynik prac nie jest
znany od samego początku  modyfikacje są nieuniknione.

XP nadaje się także w projektach, w których wiadomo, co
dokładnie należy wykonać.

Oczywiście kilka technik XP przydaje się w każdym
projekcie programistycznym. 4
Dlaczego Extreme Programming?

Wiele metod tworzenia oprogramowania zakłada, że
zmiana jest kosztowna. Błąd znaleziony w fazie
konserwacji kosztuje więcej, niż ten sam błąd
znaleziony w fazie planowania.

Techniki Extreme Programming (wydajne
programowanie) postulują inne stwierdzenie:
Możliwa jest minimalizacja wzrostu kosztu zmian
w czasie.
5

XP stara się odpowiedzieć na następujące pytania:

Jakiego rodzaju oprogramowanie można wykonać,
gdy ma się pełną swobodę w zmianie wymagań i
środowiska?

Mając wystarczającą ilość czasu i zasobów, co
można w ten sposób uzyskać?

Czy taki cel jest w ogóle realistyczny?

Jeśli tak, w jaki sposób można go uzyskać?
6
Równanie XP

Projektami programistycznymi można zarządzać w
kategoriach 4 zmiennych:
czasu, możliwości, zasobów i jakości.

Wiele projektów koncentruje się na czasie i zasobach,
zakładając, że jakość pozostanie stała. Jeżeli możliwości
kiedykolwiek się zmieniają, są typowo zwiększane (np. klient
prosi o nowe funkcje).

Co gorsza, czas i zasoby są często zmniejszane lub
pozostają stałe. Gdy zbliża się data wydania, często przy
projekcie pracuje mniej osób niż na początku.

Ostatni z parametrów, czyli jakość musi spadać! 7

XP sugeruje inną strategię:

Zespół wraz z klientem godzi się na pewien poziom
jakości.

Czas i zasoby ustala się jako wartości stałe.

Pozostaje tylko określenie możliwości:

Co zostanie dostarczone?

Kiedy zostanie dostarczone?

Klient ustala priorytety dla poszczególnych funkcji
systemu.

Praca odbywa się etapami a oprogramowanie
prawie zawsze będzie gotowe do wydania, choć nie
zawsze z pełnym zestawem funkcji. 8

XP zaleca regularne dostrajanie możliwości, nawet
codziennie. Każda decyzja biznesowa może wpłynąć na
projekt.

XP to wykorzystuje, czyniąc zmiany i ich efekty widocznymi
dla osób podejmujących decyzje biznesowe.

Zakładając odpowiednią komunikację w zespole, szybkie
odpowiedzi w kwestii stanu projektu i zdolność do
dostosowania możliwości, praktycy XP mogą swobodnie
zakładać dostateczną ilość zasobów. Jest to jedno z
głównych założeń XP:
Uwidocznienie zależności dotyczących zmian prowadzi
do mniejszej liczby niespodzianek i bardziej płynnego
tworzenia oprogramowania. 9
Wartości XP

XP składa się z czterech podstawowych
wartości:
komunikacji,
odpowiedzi na pytania (pętla zwrotna),
prostoty,
odwagi.

Wszystkie techniki XP wykorzystują te
podstawowe wartości. 10
Wartości XP: Komunikacja

Dobra komunikacja leży u podstaw każdego
projektu i umożliwia łatwe dostosowywanie się do
zmian.

Dzięki temu klient wie, kiedy poszczególne
funkcje systemu będą dostarczone a programiści i
analitycy wiedzą co robić.

Ukrywanie lub ignorowanie informacji i
nieszczerość jest często przyczyną fiaska
projektów.

Metodyka XP dokonuje podziału: osoby
podejmujące decyzje biznesowe zajmują się nimi
a osoby zajmujące się szczegółami technicznymi
podejmują wyłącznie decyzje techniczne. 11

Klient zajmuje się wyłącznie priorytetami i dyktuje
co i kiedy powinno być zrobione.

Wzajemne zaufanie: Analitycy ufają osobom
biznesowym w kwestiach identyfikacji funkcji i ich
priorytetów  to właśnie zarządzający znają się na
dziedzinie problemu.

Klient ufa twórcom oprogramowania w dziedzinie
oszacowania czasu trwania poszczególnych faz
zadań ponieważ to właśnie twórcy znają się na
technologii.

Każda z grup (osoby biznesowe i analitycy-
programiści) są częścią tego samego zespołu i
podejmują odpowiedzialność za swoje decyzje.
Celem zespołu jest zaspokojenie wymagań
rzeczywistego klienta. 12

XP, a jak to niekoniecznie bywa w przypadku tradycyjnego
procesu tworzenia oprogramowania, wymaga ciągłej
komunikacji twórców systemów z klientem.

Klient musi przeanalizować dostarczony przez twórców
projekt z punktu widzenia użytkownika i działalności
biznesowej.

Tak więc klient współdziała przy opracowaniu priorytetów i
odpowiada na pytania twórców.

Klient powinien codziennie widzieć postępy prac i do nich
dostosować harmonogram.

Klient uczestniczy w testowaniu oprogramowania już na
wczesnych etapach wytwarzania oprogramowania.

Usunięcie bariery komunikacyjnej prowadzi do
elastyczności.

Rozróżnienie decyzji biznesowych od technicznych
pomaga podejmować dobre decyzje.

Komunikacja jest niezbędna dla osiągnięcia celów. 13
Wartości XP: Odpowiedzi na pytania

Ten element XP podkreśla umiejętność zadawania pytań i
uczenie się z uzyskiwanych odpowiedzi.

Jedynym sposobem poznania zdania klienta jest zapytanie
go.

Jedynym sposobem sprawdzenia poprawności kodu jest
przetestowanie go.

XP kładzie nacisk na wczesne zadawanie pytań i wczesne
testowanie. XP umożliwia częste i szybkie odpowiedzi.

Każda z technik XP zawiera wbudowaną pętlę pytanie-
odpowiedz.

W celu zmniejszenia wzrostu kosztu zmian w czasie XP
zaleca słuchanie i naukę z wszystkich możliwych zródeł,
koncentrację na ciągłym planowaniu, projektowaniu,
testowaniu i komunikacji.

Pewne zmiany w systemie zawsze będą kosztowne ale są
tańsze, gdy są wprowadzone wcześnie (krótkie cykle pytanie-
odpowiedz. 14

Szybkie odpowiedzi i natychmiastowe reakcje na nie
zmniejszają nakład czasu i zasobów dla pomysłów, które
wnoszą niewiele nowego.

Błędy są znajdowane na przestrzeni krótkiego czasu (dni,
tygodni) a nie miesięcy czy lat.

Planowanie tylko do pewnego stopnia pozwala uniknąć
niektórych błędów  dopiero rzeczywiste sprawdzenie pozwala
poznać niektóre pułapki i zagrożenia.

Pytania i odpowiedzi ułatwiają dostosowywanie
harmonogramów i planów. Dzięki temu gdy ktoś znajdzie
problem, projekt jest natychmiast kierowany na właściwy tor z
uwzględnieniem tego problemu.

Częste uzyskiwanie odpowiedzi umożliwia częste
wprowadzanie poprawek i wyciąganie wniosków na ich
podstawie.

Zaleca się aby klient mógł uczestniczyć w projektowaniu kodu:
przeglądać funkcje w trakcie ich tworzenia  cenne uwagi klienta
 mogą wcześnie wpłynąć korzystnie na projekt. 15

Częste testowanie ogranicza miejsce poszukiwania
błędów do minimum.

Innymi podstawowymi zasadami XP są częste
demonstracje i wprowadzanie szybko
najważniejszych funkcji.

Czas od projektu do implementacji mierzony jest w
godzinach. 16
Wartości XP: Prostota

Prostota oznacza wykonanie tylko tej części
oprogramowania, która rzeczywiście musi być
wykonana.

XP wychodzi z założenia, że projektowanie na
zaś jest trudne i ryzykowane, przewidywalna jest
tylko najbliższa przyszłość, dlatego trzeba z
realizacją pewnych funkcji się wstrzymać. 17
Wartości XP: Odwaga

Odwaga oznacza konieczność podejmowania trudnych
decyzji gdy jest to niezbędne.

Jeżeli funkcja nie działa: naprawia się ją.

Jeżeli kod jest niewystarczający: ulepsza się go.

Informację o ewentualnym fakcie niemożliwości
przekazania wszystkich funkcji klientowi trzeba mu
natychmiast przekazać. To klient powinien zadecydować
jakimi funkcjami się najpierw zająć w przypadku gdy taka
sytuacja zajdzie.

Odwagę bardzo trudno wprowadzić: nikt nie chce zle
wypaść i tracić twarzy na skutek łamania obietnic.

Jednak jedynym sposobem odzyskania zaufania po
błędzie jest naprawienie go i przyznanie się do niego.

Wychodzenie na wprost wyzwaniu jakim jest tworzenie
oprogramowania zamiast unikanie go czyni
oprogramowanie lepszym. 18
Zakładanie dostatecznej ilości
czasu i zasobów

Tworzenie oprogramowania to nieustanny wyścig
związany z czasem i zasobami.

XP ma inne podejście i zakłada wystarczającą ilość
czasu na wykonanie oprogramowania.

XP twierdzi, że tylko zapewnienie wystarczającej
ilości czasu i zasobów prowadzi do dostarczenia
oprogramowania o satysfakcjonującej klienta jakości.

W XP zamiast spieszyć się z powodu zbliżającego
się terminu, praca odbywa się w normalnym tempie.
Ilość wykonywanej pracy jest zawsze stała i
dostosowuje się możliwości, by spełnić harmonogram
przy przyjętych ograniczeniach czasowych. 19
Wystarczająca ilość czasu

Wystarczająca ilość czasu na wykonanie zadań zapewnia
niewielki koszt zmian i małą liczbę popełnianych błędów.

Zakłada się, że klient może łatwo i tanio zmienić priorytety.
Klika technik XP czuwa nad tym by, kod był elastyczny (łatwy
do modyfikacji i rozszerzania).

XP stara się wykonać najlepsze oprogramowanie przy
dostępnych zasobach i czasie, zakłada się jednak, że dobrze
oszacowano ilość pracy jaką rzeczywiście da się wykonać.

Projekty XP mają bardzo krótkie cykle, co redukuje odstęp
czasu między projektowaniem (analizą) a wykonaniem
oprogramowania (działaniem).

Wprowadza się wiele mechanizmów oceny i weryfikacji na
każdym z etapów co umożliwia szybkie wprowadzanie
poprawek. Projekt prawie od razu produkuje pewne wyniki
więc daje się sprawdzić czy podąża się właściwym torem.
20
Wystarczająca ilość zasobów

XP zapewnia wystarczającą ilość zasobów w trakcie tworzenia
systemu informatycznego.

Liczba programistów określa liczbę pracy wykonywanej w
jednostce czasu  modyfikuje się możliwości, aby dopasować
projekt do zasobów.

Programiści muszą wykazać oszacowania przewidywanego
czasu trwania każdego zadania.

Następnie, ma miejsce poprawa tych ocen wraz z realnym
czasem spędzonym na wykonywaniu zadania. Z czasem te oceny
są tak precyzyjne, że mogą być użyte na etapie planowania.

Daje to możliwość klientowi utworzenia budżetu zasobów
niezbędnego na poszczególne elementy systemu. Po pewnym
czasie w projekcie nabiera się doświadczenia a więc zasoby wraz
z upływającym czasem są coraz lepiej wykorzystywane.

Odwrotnie niż w podejściu klasycznym, wraz z rozwojem kodu
coraz łatwiej dodawać nowe funkcje. 21
Stały koszt zmian

W klasycznych technikach rozwijania oprogramowania koszty
zmian z upływem czasu dramatycznie rosną. Np w modelu
kaskadowym gdzie czas, który upływa od momentu
planowania/projektowania do testowania oprogramowania
wykrycie błędów może wiązać się z powtórzeniem całego cyklu
życiowego rozwijania oprogramowania. W klasycznych modelach
cyklu życia aplikacji koszty zmian narastają.

XP zapewnia stały w czasie koszt zmian: dodanie nowej funkcji
będzie tak samo kosztowne za rok, jak w chwili obecnej.

Dzięki temu opóznia się wprowadzenie pewnych funkcji do czasu
aż będą rzeczywiście potrzebne.

XP inwestuje czas i zasoby tam, gdzie oczekuje się
natychmiastowych wyników.

Redukuje się koszt zmian, poszukując ciągłego kontaktu z
klientem. Klient otrzymuje działającą wersję kodu, tak szybko jak
to jest możliwe, często już klika tygodni po rozpoczęciu projektu.
22
Wydajność twórców oprogramowania

XP stawia bardzo wysoką poprzeczkę pod względem
umiejętności programistów i projektantów.

Programiści często pracują w parach i dwóch programistów
pracuje nad tym samym kodem.

Cała baza programistyczna  projekt i implementacja  jest
otwarta na udoskonalenia.

XP zapewnia kilka pętli pytań i odpowiedzi na etapie kodowania
wymuszając na programistach staranność i skrupulatność. Częste
testowanie umożliwia usunięcie błędów natychmiast po ich
wykryciu.

Dzięki zgodzie na modyfikację poziomu możliwości przy
pozostawieniu czasu stałym unika się frustracji i przepracowania.

XP zakłada, że cały zespół  menadżerowie, programiści,
analitycy i klienci mają swobodę eksperymentowania.

Główny cel XP: wykonywanie wydajnego oprogramowania
poprzez wykonywanie naprawdę ważnych zadań. 23
Techniki XP

Istnieje 12 technik XP, które wzajemnie oddziałują i
wspierają się nawzajem.

Techniki te pomagają podejmować trafne decyzje i wykonać
oprogramowanie wysokiej jakości w przewidzianym czasie.

Często stosuje się tylko kilka technik, lecz stosowanie się do
wszystkich daje lepsze rezultaty.

Każda technika spełnia kilka zadań.

Wykorzystanie kilku technik bez znajomości ich
współdziałania często prowadzi do poważnych błędów.

Najlepszym sposobem zapewnienia dobrego
oprogramowania jest stosowanie i praktykowanie XP

XP nie jest uniwersalną receptą: istnieją inne techniki,
czasami wygodniejsze do specyficznych typów zadań.

3 grupy technik XP: kodowania, współpraca programistów,
związki między zagadnieniami technicznymi a biznesowymi.
24
Techniki kodowania

Pisanie kodu to jeden z najważniejszych
elementów tworzenia oprogramowania.

Większość czasu i energii poświęcanej
projektowi dotyczy właśnie kodu  stąd duże
zainteresowanie tym elementem tworzenia
oprogramowania ze strony XP.

Programiści praktykujący XP piszą najpierw kod
aby sprawdzić i ocenić swoje plany. Wiele osób
postrzega, że programiści XP piszą kod bez
żadnego planowania. Jest odwrotnie, pisanie
kodu umożliwia planowanie.

Cztery techniki kodowania współpracują ze sobą,
aby powstał kod prosty w utrzymaniu, elastyczny i
zawsze gotowy do dostarczenia klientowi. 25
Technika kodowania #1: proste projektowanie
i kodowanie
Cel: wykonanie oprogramowania łatwego w
modyfikacji

Należy wykonywać proste projekty i pisać prosty kod, który
spełnia aktualne potrzeby klienta.

Unika się odgadywania przyszłych potrzeb, zarówno na
etapie pisania kodu jak i projektowania.

Nadrzędny cel to elastyczność, prostsze projekty łatwiej
zrozumieć i nimi zarządzać.

Prosty kod łatwiej testować, konserwować i modyfikować.

XP skraca czas planowania do minimum, preferuje
spędzenie niewielkiej ilości czasu przed napisaniem kodu.

Projekt uwidacznia się wraz z rozbudową systemu.

Dla kontrastu tradycyjne podejście zakłada, że zmiany są
trudne i kosztowne więc trzeba wszystko zaplanować przed
rozpoczęciem pracy. 26

XP zakłada, że zmiany są nieuniknione więc plan
powinien się dostosowywać. Pracując w krótkich cyklach,
cały czas testując czy jesteśmy na właściwej drodze,
identyfikujemy błędy i szybko dostosowujemy się do
zmian.

Skupiamy się na prostocie i terazniejszości, XP
przestrzega przed dodawaniem funkcji `na zaś', gdyż
każda funkcja wnosi pewien koszt, zabiera czas, zasoby i
odciąga od głównego nurtu projektu.

Niepotrzebne funkcje zaśmiecają i komplikują system 
chęć ich dodania wynika ze strachu, że wprowadzenie
ich w przyszłości będzie kosztowne i trudne.

XP uzyskuje elastyczność poprzez prostotę.

Zadaje się pytanie:  Czy można uprościć kod i nadal
przejść przez odpowiednie testy .

Przewidywanie przyszłości jest trudne, należy
projektować tylko to co jest aktualnie potrzebne. 27

Prosty projekt zapewnia:

wspólną odpowiedzialność za kod (z racji jego prostoty
 złożone systemy wymagają specjalizacji)

refaktoryzację (ponieważ w prostszym kodzie łatwiej
dostrzec niebędne do przeprowadzenia zmiany)

testowanie (ponieważ prostszy kod łatwiej sprawdzić).

Prosty projekt wymaga:

dobrej komunikacji między twórcami a klientem

pewności siebie

zdolności do znajdowania prostoty i chęci jej
utrzymania (czyli unikania komplikowania rzeczy, które da
się zrobić prosto).
28
Technika kodowania #2: refaktoryzacja
Cel: znalezienie optymalnego projektu kodu

Refaktoryzacja oznacza poprawę projektu aktualnego kodu
bez zmiany jego zachowania.

Refaktoryzacja poprawia istniejący kod, by stawał się
prostszy, krótszy i elastyczniejszy.

Refaktoryzację należy przeprowadzać regularnie zaraz po
fazie testów nowego kodu.

Wiele środowisk programistycznych (IDE) wyższej klasy
obsługuje podstawowe metody refaktoryzacji, które wykonuje
się automatycznie: wystarczy określić cel refaktoryzacji a
środowisko wykona niezbędne poprawki lub powróci do stanu
oryginalnego.

Refaktoryzacja jest o tyle ważna, że XP zachęca do
powstawania projektu na podstawie eksperymentów z kodem
a to prowadzi do powstania kodu nieeleganckiego i niskiej
jakości. 29

Refaktoryzacjia to eliminacja powtórzeń (duplikacji
kodu), podział długich metod i funkcji na krótsze,
uściślenie nazw metod i zmiennych, ciągłe
upraszczanie i poprawianie.

Celem refaktoryzacji jest uproszczenie projektu i
zmiana jedynie struktury kodu, bez wpływania na
zachowanie. Testy przed i po wykonaniu
refaktoryzacji powinny dać takie same wyniki.

Czasem zdarza się sytuacja, że po dłuższym czasie
spędzonym nad refaktoryzacją, zauważa się
możliwość znacznego uproszczenia architektury
systemu. Należy zapytać się klienta o zgodę na
zmiany i być gotowym na obronę swojej tezy pod
względem biznesowym. 30

Refaktoryzacja zapewnia:

prosty projekt (ponieważ zmiany są wprowadzane
regularnie)

dyscyplinę

Refaktoryzacja wymaga:

dyscypliny (ponieważ refaktoryzację należy
przprowadzać, gdy tylko to możliwe)

obiektywnych testów (aby upewnić się, że zachowanie
kodu jest takie samo przed jak i po refaktoryzacji)

wspólnej własności kodu (oznacza to możliowość
poprawienia dowolnego fragmentu systemu)

standardów kodowania (aby wykonywać zmiany w taki
sposób jak to oczekuje zespół)
31
Technika kodowania #3: opracowanie
standardów kodowania
Cel: łatwe przekazywanie pomysłów przy
użyciu kodu

Standardy pisania (kodowania) programów tworzy się w celu
pomocy programistom w komunikowaniu się poprzez kod. Kod to
główne narzędzie komunikacji w całym projekcie.

Standardy kodowania wykorzystują najlepsze praktyki
programistyczne i są to pewne konwencje w stosunku do kodu.

Standardy kodowania nie muszą być sztywne (obowiązujące cały
czas). Ewoluują wraz z projektem.

Standardy kodowania to wskazówki a nie rozkazy. Trzeba
wiedzieć kiedy stosować się do standardów a kiedy je zawiesić.

Standardy kodowania oszczędzają czas.

Niektóre projekty stosują zautomatyzowane testy czy kod spełnia
standardy kodowania.

Znany standard: Notacja węgierska w Microsoft opracowana
przez Charlesa Simonyi 32

Standardy kodowania zapewniają:

refaktoryzację (łatwiej zobaczyć zmiany i
zautomatyzować modyfikacje, gdy kod jest jednorodny
stylowo)

programowanie w parach (programiści skupiają się
na kodzie a nie na stylu)

wspólną własność kodu (kod zawiera elementy
wspólne dla całego zespołu a nie tylko programistów
danego kodu)

Standardy kodowania wymagają:

pracy zespołowej (w celu ustalenia wspólnych
preferencji i przyzwyczajeń)

okresowych sprawdzeń (aby sprawdzić czy
standardy nadal pasują do kodu po jego ewolucji)

programowania w parach (aby zachować - wymusić
standardy w nowo tworzonym kodzie) 33


Wyszukiwarka

Podobne podstrony:
2007 11 Extreme Programming i CMMI [Inzynieria Oprogramowania]
using the rup for small projects expanding upon extreme programm?B73129
2008 02 Extreme Programming i CMMI – kreatywność czy dyscyplina (Cz 3) [Inzynieria Oprogramowania]
Extreme Programming Leksykon kieszonkowy
2007 10 Extreme Programming (XP) i CMMI – Kreatywność, czy Dyscyplina [Inzynieria Oprogramowania]
zestawy cwiczen przygotowane na podstawie programu Mistrz Klawia 6
Międzynarodowy Program Badań nad Zachowaniami Samobójczymi
CSharp Introduction to C# Programming for the Microsoft NET Platform (Prerelease)
Instrukcja Programowania Zelio Logic 2 wersja polska
Program wykładu Fizyka II 14 15
roprm ćwiczenie 6 PROGRAMOWANIE ROBOTA Z UWZGLĘDNIENIEM ANALIZY OBRAZU ARLANG
io port programming 3ogqzy3bscrrpgv753q3uywjfexgwwoiiffd46a 3ogqzy3bscrrpgv753q3uywjfexgwwoiiffd46a
2009 12 Metaprogramowanie algorytmy wykonywane w czasie kompilacji [Programowanie C C ]
Podstawy Programowania Wersja Rozszerzona
koło Programy Goofy

więcej podobnych podstron