Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie logi­ka” jest powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to czło­wiek developera”.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 3 komentarzy

  1. Szympans u steru

    Bardzo cie­ka­wie opisane.
    W przy­pad­ku TDD moż­na też zna­leźć i try­wial­ny przy­pa­dek, któ­re­go TDD nie obsłu­ży pra­wi­dło­wo a przy­naj­mniej nie da nam jed­no­znacz­nej odpo­wie­dzi na temat tego jaki System nale­ży wybrać.

    Przypuśćmy, że mamy do zapro­jek­to­wa­nia samo­chód, któ­re­go jedy­nym warun­kiem jest osią­gnię­cie 100km/h w 9 sekund.
    Test jaki zapro­jek­tu­je­my jest pro­sty, star­tu­je­my samo­cho­dem, włą­cza­my sto­per i wyłą­cza­my po osią­gnię­ciu 100km/h.

    Prosty test, któ­ry zali­czy zarów­no Opel Astra z sil­ni­kiem 1.4 jak i Ferrari, z tym że Ferrari zro­bi to na wstecz­nym. I tak oto uży­wa­jąc jedy­nie TDD może­my z czy­stym sumie­niem zapro­po­no­wać odbior­cy zakup Ferrari 488 GTB za milion. Pytanie czy to na pew­no ten samo­chód jaki Klient potrzebuje?


    Poruszyłeś jesz­cze jed­ną cie­ka­wą kwe­stię, któ­ra czę­sto gdzieś umy­ka. Developer czy czło­wiek z biz­ne­su robią­cy za ana­li­ty­ka. Ten pierw­szy na zasa­dzie Idź Krzysiu pil­nuj, żeby nam nie wci­snę­li za dużo do zro­bie­nia”, ten dru­gi na zasa­dzie Halinka idź, dasz radę, lubisz prze­cież analizę”

    Co praw­da czę­sto jest to wyni­kiem ogra­ni­czeń budże­to­wych i zatrud­nia­nia – zwłasz­cza w kor­po­ra­cjach – yes manów, któ­rzy zro­bią wszyst­ko. Przeważnie wystar­czy jed­nak jeden rzut oka na doku­men­ta­cję żeby wie­dzieć czy ana­li­tyk cho­ciaż prze­cho­dził koło niej.
    Nikomu nie ujmu­jąc wie­dzy czy ambi­cji, ana­li­zę wyma­gań naj­le­piej zosta­wić pod­mio­tom zewnętrz­nym nie zwią­za­nym z biz­ne­sem czy deve­lo­pe­rem. Przy napraw­dę dużych i cie­ka­wych roz­wią­za­niach – moim zda­niem – dobrze jeśli wydzie­li się tak­że nie­zwią­za­ną z pro­jek­tem i fir­mą oso­bę odpo­wie­dzial­ną za napi­sa­nie sce­na­riu­szy testowych.

  2. Uwagi w dru­giej czę­ści są bar­dzo nie­po­pu­lar­ne gdyż wdro­że­nie ich prak­tycz­nie cał­ko­wi­cie eli­mi­nu­je lob­bing jed­nej i dru­giej stro­ny, któ­ry naj­czę­ściej psu­je pro­jekt poprzez wymu­sza­nie nie­lo­gicz­nych wyma­gań, któ­re dają jakieś korzy­ści lobbującemu. 😉

  3. Pawel Zubkiewicz

    Witam Jarku,
    Muszę przy­znać, że to chy­ba jeden z Twoich naj­lep­szych arty­ku­łów na blo­gu! Sądząc po pyta­niach to na kon­fe­ren­cji była pra­ca u pod­staw” dla­te­go tym bar­dziej waż­ne jest pro­mo­wa­nie ele­men­tar­nej wie­dzy. Szczególnie przy­padł mi do gustu przy­kład z tablicz­ką mno­że­nia, oso­bi­ście w gło­wie od razu zaświ­ta­ła mi funk­cja w mate­ma­ty­ce” czy­li ogól­ny zapis (wzór) zamiast sze­re­gu spe­cy­ficz­nych przy­pad­ków usi­łu­ją­cych opi­sać” zjawisko. 

    Pytanie o TDD dla mnie tro­chę chy­bio­ne, pew­nie oso­bie pyta­ją­cej cho­dzi­ło o to, że mają user sto­ries też… ale to nie waż­ne. Istotne jest to, że same wyma­ga­nia w posta­ci kry­te­riów (pobu­dze­nie i rezul­tat) BEZ ana­li­zy nie wystar­cza­ją i nie­ste­ty to jest naj­więk­sza bolącz­ka meto­dy­ki Agile. O tym nie napi­sa­łeś wprost,choć domy­ślam się z jakich względów 🙂

    Do Szympans u ste­ru: pra­cu­jąc w TDD raczej małe jest praw­do­po­do­bień­stwo, że zbu­du­jesz Ferrari (bar­dziej roz­bu­do­wa­ny pro­dukt) niż Opla (mniej skom­pli­ko­wa­ny) wcze­śniej. Udoskonalasz pro­dukt tak dłu­go aż speł­ni kry­te­ria, naj­wczę­ściej LINIOWO udo­sko­na­lasz, czy­li w pierw­szej pró­bie samo­chód jedzie 10km/h, w dru­giej 23 i tak dalej… aż osią­gniesz 100km/h (przej­dzie test).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.