chcialem sie dowidziec jakie sa wasz doswiadzcenia zwiazane z XP przy pisaniu w php. Moje doswiadzcenia sa nastepujace:
- pisany kod jest o niebo lepszy
- aplikacja powstaje szybciej
- aplikacja ma mniej bledow
- aplikacja rozwija sie szybciej - szybciej dodawane sa nowe pomysly

minusy :

- nie kazdy sie do tego nadaje. znam wiele osob ktore nie powinny/nie chca
tak pracowac
- czasmi ludzie przyjmuja krytyke osobiscie do siebie chociaz jest ona
skierowana raczej w strone kodu.

dlaczego pisze akurat na ta grupe?
Poniewaz XP zaliczyl bym do bardzo dobrych strategi pisania akurat w php gdzie trzeba cos napisac szybko i prosto by klijent nam zaplacil.

Nie wszyscy wiedzą co to jest XP (eXtreme Programming) więc proponuję wyjaśnienie najpierw o co chodzi...

XP jest ogolnie sposobem prowadznenia projektow informatycznych.
Podstawowa jego zasada jest:
- pisanie kodu parami
- testowanie
- szybkie laczenie wersji
- tworzenie aplikacji w scislej wspolpracy z klijentem
- nie opieranie nie sa sztywnej dokumentacji - to mi sie podoba najbardziej
- ciaglemu wracaniu do juz stworzonego kodu - to jest zazwyczaj zadkosc dla
wiekszosci programistow.
- testowanie

Wszystkie te punkty przeplataja sie bardzo ze soba tworzac cala strategie projekty. Mozna sie posunac nawet do tego ze doprawadzaja do strategii ustwien stolikow z kompami gdy pracuje sie parami.

Od tego aby wyjasnic sa google.

Wracajac do XP uwazam, ze to swietna technika pisania, ktora skraca czas testowania i eleiminuje wiekszosc bledow.

Ale jakos nie przypada mi do gustu pisanie testowych klas.

rozumiem zawsze jest z tym problem zeby sie zmusic . Przez caly czas chce sie przelamac ale mi nie zabardzo wychodzi chociaz szkoda Pieknie bylo by wlaczyc poprostu automatyczny test i patrzec jak wszystko idzie gladko i bez problemu po dodaniu nowego modulu a przeciez o to chodzi - by szybko napisac aplikacje bez bledow

Posty odbiegajace od tematu przenioslem tutaj:
http://forum.php.pl/viewtopic.php?t=6801

Chociaż nie jestem znawca w tej dziedzinie to muszę powiedzieć że jak dla mnie to bomba. Wykluczanie błędów staje się bardziej intuicyjne. No tylko jak Seth wspomniał pisanie klas sprawdzających błędy jest dopiero EXTREME Ale jeżeli znalazłby się ktoś kto to lubi to problem z głowy..

Od dwoch prawe lat pisze z kolega aplikacje czerpiac calymi lopatami z XP i musze powiedziec ze super nam sie pisze. Kazdy drugiego wspiera wyjania na czym dany problem polega i jak go rowiazac. Szczegolnie mi trzeba duzo tlumaczyc - wolno kapuje Ale na poczatku trudo sie bylo przestawic bo jak tu sie nie obrazac jak kolega mowi ze moj wspanialy kawalek nad ktorym siedzialem pol dnia jest o wywalenia To boli itzreba miec duzo pokory i odwagi do przyznania sie ze zrobilo sie zle ze ktos moze cos lepiej wiedziec. To bylo dla mnie ciezkie ale sie przyzwyczailem i teraz bardzo lubie z nim razem pisac Dziekuje ci D
Ale z niektrurymi nie wyobrazam sobie wspolpracy oni poprostu nie lubia tego stylu pracy.
Dla mnie wanz jest tez metodyka prowadzenia pojektu wdrazania go bardzo mi sie podoba bo jest podobna do ewolucji. Projekt idzie malymi kroczkami do przodu. Jezeli inwestorowi to odpowiada to bomba oddajemy mu powoli male kawalki i moze on juz na nich pracowac. Prosto dostosowac sie do zmiany zdania - bardzo czesta sytuacja Inwestor tez jest zadowlony bo co jakies czas np co tydzien ma nowe czesci widzi ze projekt zyje ze wie za co placi i wszycy sa szczesliwi

a ja z kolei mam mniej doswiadczenia jezeli chodzi o programowanie w parach ktore jest tylko jednym z nazedzi XP a troszke wiecej z tym co na pierwszy rzut oka wydaje sie meczace czyli z pisaniem testow. Moje zdanie na ten temat jest takie ze jest to rewelacyjny pomysl. To niezwykle pomaga w zdefiniowaniu czego tak na prawde nam potrzeba a co jest zbednym elementem klasy. Z doswiadczenia wiem ze nawet najlepszy projekt klas na papierze czy w glowie ma pewne luki ktore sa wypelniane podczas implementacji, pisanie testow zanim zacznie sie pisac klasy pomaga wyeliminowac te nieprzemyslane elementy do minimum.

Witam,

Poczytałem sobie trochę o XP - szczególnie o idei testowania kodu i tu nasunęło mi się kilka pytań dot. pisania testów klas.

Ostatnio zgłębiam idee MVC i zastanawiam się w jaki sposób można np. testować zgodnie z ideą XP klasy (ich metody) typu View. W przypadku takich klas w zasadzie zawsze mamy do czynienie ze zwracanym stringiem i IMHO trudno by było testować zawartość takiego stringu wynikowego.

Kolejna sprawa to testowanie medod (z klas Modelowych), które wyciągają dane z DB np. czy w przypadku, gdy metoda ma zwrócić liczbę rekordów w bazie np. w tabeli użytkownicy, to wystarczy, że w teście sprawdzimy, że zwracana wartość jest wart. całkowitą?
Kolejny porzypadek, gdy metoda zwraca listę uzytkownikow w postaci tabeli obiektów Users, czy w takim przypadku wystarczy sprawdzić, że zwracana wartość to tablica, czy też należy się zagłębiać dalej ...

Proszę podzielcie się swoimi doświadczeniami ...

gdzie sie dowiem czegos wiecej o XP? najelpeij po polsku, ale moze byc w angielskim...

Artykuł z PC Kuriera z krótkim wprowadzeniem (dość stary ):

http://www.pckurier.pl/archiwum/art0.asp?ID=4465

Oficjalna strona XP:

http://www.extremeprogramming.org/

a jakis przykladowy kod?

racja: programowalem z kumplem na jednej maszynie (wiecej nie mielismy :wink: ) - jeden pisal, a drugi go kontrolowal - obaj myslelismy nad algorytmami i konfrontowalismy opinie - efekt niesamowity - poza faktem, iz przez pierwsze 2 dni, nie moglismy sie "zgrac" - zaden nie dopuszczal do siebie mysli, iz to co wymyslil dziala gorzej od tego co wykombinowal drugi. ale pozniej bylo juz wporzadku: przy okazji faktycznie uczylismy sie pewnych rzeczy jeden od drugiego.

btw. wowczas jeszcze nie slyszelismy nawet o XP; a do takiego kodowania zmusil nas fakt posiadania tylko 1 maszyny :wink:

mam za to pytanie: po co w php'ie stosowac funkcje testujace, skoro przy napisaniu czytelnego kodu: duzej modularyzacji, nazywaniu funkcji tak, aby wiedziec za co odpowiadaja itd. bardzo szybko okresla sie ktory z modulow jest odpowiedzialny za blad, a korzystajac z prostego sledzedznia zmiennych, mozna okreslic, w ktorym momencie cos sie "sypnelo" ?

co sie tyczy dokumentacji: podzielam opinie, ze bzdura jest tracic czas na jej pisanie, bo de facto w wiekszosci wypadkow powstaje ona doiero po napisaniu calego oprogramowania. ja w trakcie kodowania sporzadzam krotkie notatki, na temat uzytych w danym skrypcie funkcji, powiazan pomiedzy nimi oraz w osobnym pliku notuje, ktora funkcja w jakim skrypcie jest wykorzystywana. a na kartkach paieru szkicuje tabele bazy danych oraz powiazania miedzy nimi. - w praktyce istotnie zaoszczedza mi to sporo czasum a w przypadku, gdy trzeba cos poprawic/zmienic dokladnie wiem "co gdzi i jak" - tak wiec, w miare zadko zdaza sie, iz zmiana jakiegos modulu powoduje wysypanie sie innego, badz np. posypanie sie zupelnie innej czesci oprogramownia, ktora z tegoz modulu takze korzysta.

naturalnie, moje spostrzezenia sa takie a nie inne, poniewaz nie pracuej w zespole. w przypadku, gdybym istotnie mial pracowac w grupie, roziwazania oferowane przez XP wydaja mi sie o niebo lepsze od "standardowych".

Zestawy testów w XP nie są po to, żeby wykrywać gdzie będzie błąd tylko sprawdzać czy go nie ma w tym co już napisałeś. Wyobraź sobie, że projektujesz duży system. Piszesz go już razem z kilkoma innymi programistami od powiedzmy pół roku. Teraz jak grom z jasnego nieba przylatuje Twój szef i mówi, że klient zażyczył sobie jeszcze jednej funkcjonalności. Ponieważ zgodnie z zasadami XP struktura i architektura projektu powstają dynamicznie podczas programowania, zmieniasz część rzeczy aby dopasować je do nowego modułu. I teraz pomyśl czy będzie Ci się chciało testować całą resztę projektu pod kątem tego, czy wprowadzone zmiany w wygrzanym kodzie nie narobiły problemów gdzie indziej? Do tego można zatrudnić komputer puszczając zestaw napisanych wcześniej testów. Oczywiście w małym projekcie jest to niepotrzebne i tylko doda zbędnej roboty, ale w większym jest nieocenione.

ok, jarze; to nawet logiczne.

a teraz: moglby mi ktos pokazac jaks przykladowa funkcje (klase) testujaca?

To będzie delikatnie mówiąc trywialne, ale mam nadzieję, że odda sens.

[php:1:d1629facbc]<?php
class Puppa {
var $str_test;
function Puppa()
{
$this->str_test = "mlask";
}
}

function puppaTest()
{
print "<table><tr><td>puppaTest()</td></tr>";
$p = new Puppa();
if($p->str_puppa != "mlask")
print "<tr><td>błąd w konstruktorze</td></tr>;
print "</table>";
}
?>[/php:1:d1629facbc]

oki, thx

a w przypadku, gdy np. funkcja ma wyciagnac z bazy danych jakies dane o uzytkownikach, ktore moga byc od sibebie rozne, to rozumiem, ze wystarczy wypisac to co wyciagnela z np. komentarzem czego mniej wiecej oczewkiwalismy ?

Proponuje poczytac czesc inormacji z przyszlej dokumentaci THOTa http://forum.php.pl/dev/dt/team_site/thot/...al/ch10s02.html
http://forum.php.pl/dev/dt/team_site/thot/...al/ch10s03.html

Seth: dzieki za udostepnienie dokumentacji. Naprawde bardzo wartosciowy material

Przy okazji: dzieki temu uzmyslowilem obie, ze sposob w jaki tworze jest zblizony do samej ideologii XP. Jedyne czego do tej pory brakowalo to: funkcje testujace - i oczywsice wszystkie elementy zwiazane z praca w grupe, bo de facto caly czas sam harowalem nad kazdym elementem projektu.

wg. mnie XP ma przyszlosc - przynajmnie w przypadku projektowania na siec (niegdy nie projektowalem duzych, czy nawet srednich zwyklych aplikacji); ta technika wydaje sie wprost wymarzona dla php, czy JAVA.

P.S teraz wiem jak po imieniu nazywac rzeczy, ktore robilem intuicyjnie oraz co nalezy wprowadzic, w moim przypadku, aby udoskonalic ten sposob projektowania-kodowani. Thx. za linki

P.S 2 Seth: swoja droga: czy moge wykorzystac informacje z Waszej dukumentacji w wykladzie na temat technik tworzenia serwisow internetowych, ktory za niedlugo bede zmuszony prowadzic?
Z racji tego, ze musze przygotowac te wyklady i krok po kroku przedstwawic caly proces tworzenia, zastanawiam sie czy nie warto by bylo przerobic caly silnik ze zwyklych funkcji na klasy, a przy okazji poprawic klika drobnych bledow, ktore popelnilem w procesie projetkowanie ? - jestem ciekawe Twojego zdania.

chcilbym sie upewnic: moduly testujace dana klase piszemy, przed czy po napisaniu klasy, ktora beda testowaly ?

Druga sprawa: po dodaniu nowej wersji jakiegos modulu - czy sprawdzamy calosc projektu za pomoca testow adaptacyjnych, czy tylko ten jeden, zmieniony modul ?

Guru extreme programming zalecają napisanie testu przed rozpoczęciem pisania klasy. Jest to o tyle rozsądne, że wymusza przemyślenie interfejsu klasy

Sprawdzić zaś warto wszystko. W końcu między poszczególnymi modułami w projekcie istnieją różne zależności, na które dodanie nowej wersji modułu może mieć wpływ.

taaaaa

ale nadal ciekawi mnie czy piekna teoria XP sprawdza sie w praktyce, ale cos nikt nie chce sie pochwalic, czy to wogole testowa, w jakiej grupie, przy jak duzym projekcie etc

swoja droga: mysle ze XP trzeba by troszke zmodyfikowac, bo czesc strawianych tam warunkow jest ciekza do spelnienia w zaleznosci od tego jak wyglada grupa wspolpracujaca, przykladem moze byc chociazby sama idea kodowania w parach - niezle to musi wygladac w momencie, gdy kazdy z czlonkow zespoly mieszka w innym miescie lub gorzej: w innym kraju...

Nie rozumiesz. XP ma pomagac w programowaniu a nie przeszkadzac. Jesli nie nadajesz sie do programowania w parach, mieszkasz za daleko, nie masz mozliwosci itp. to tego nie robisz.

To sa tylko zasady ktore maja ci pomoc w zdecydowaniu sie na cos co bedzie wlasnie Ci pomagac w programowaniu - sam musisz zdecydowac co bedzie dla ciebie najlepsze.

Ja np. programuje z kumplem w parach i nie mamy z tym problemow (programujemy raczej duze projekty) natomiast nie jest zawsze tak, ze siedzimy razem - w wiekszosci programowanie w parach odbywa sie wtedy kiedy musimy zrobic cos nowego, wymyslic cos, wykombinowac itp.

Z doswiadczenia wiemy jednak, ze nie wszyscy nadaja sie do programowania w parach - przede wszystkim trzeba sie lubic, rozumiec, miec podobny poziom zaawansowania w danym jezyku itp. Nie mozna usiasc sobie z byle kim i zaczac kodzic - najpierw trzeba sie poznac.

U nas programowanie w parach wyszlo samo - dopiero pozniej dowiedzielismy sie, ze opisuje je wlasnie XP. Dla nas bylo to naturalne, ze jak rozwiazujemy jakis problem to nie w pojedynke...