Real-Worls Solutions for Developing High Quality PHP Frameworks and Applications

• pracuje na systemach z zaszłościami (Legacy Systems)
• myśli, że refaktoring takich systemów nie jest możliwy
• testy automatyczne muszą być równie przyjemne jak hemoroidy
• boi się, że aplikacja, w którą zainwestował już sporo powoli staje się niemożliwa w utrzymaniu
• myśli, że system, którego używa od lat trzeba przepisać od zera

Pozycja zdecudowanie nie jest przeznaczona dla tych, którzy zaczynają swoją przygodę z PHP. Jeśli jednak już okrzepłeś i szukasz czegoś więcej – polecam gorąco.

Wiem, że brzmi to może jak banał, ale to nie jest jakaś wytyczna ustalona raz na początku projektu. Zrozumienie tego zajęło mi 4 lata. Nie możesz się umówić, że od teraz, od tego projektu, od tej funkcji będziesz pisał kod wysokiej jakości.

Możesz umówić się, że będziesz pisał kod o jakości najlepszej na jaką Cię w tym momencie stać.

Jednak w międzyczasie nauczysz się czegoś nowego. Wysokiej jakości kodu to taki, którego jakość rośnie ciągle. Nie tylko wraz z dodawaniem nowych linii. Również trafiając na kod z przed roku warto pochylić się nad nim.

Czy masz zespół, który stosuje zasadę skautów?

Chciałbyś być członkiem takiego zespołu?

Jak zawsze – staraj się myśleć, żeby nie popaść w przesadę.

Gorąco polecam ją wszystkim, nie tylko programistom:

Nigel Baker – 10 tips for ScrumMasters from Andy Brandt on Vimeo.

Drugą moją ulubioną prezentacją była przygoda z testami akceptacyjnymi i narzędziem Sweetest Bartek Bańkowski i Szczepan Faber uraczyli nas żywym i ciekawym podejściem do tematu. Aż żałuję, że moja znajomość Javy ogranicza się do znajomości składni. Chciałoby się móc korzystać z ich narzędzi w moim aktualnym środowisku.

To były dwie najlepsze prezentacje z tych, które miałem możliwość zobaczyć. Nie było możliwe uczestniczyć w nich wszystkich z tego względu, że dwie ścieżki odbywały się równolegle. Niestety w takiej konfiguracji ktoś taki jak ja zainteresowany zarówno ścieżką “Craft” jak i “People” miał ciężki orzech do zgryzienia.

Czekam na letni AgileTuning. Zdecydowanie warto.

Ah! Dodam jeszcze, że lokalizacja też była wybrana świetnie – piękne miejsce w hotelu koło zamku w Przegorzałach. Mimo, że liście zamiast zielone i na drzewach były bure i na ziemi – miejsce wydało mi się bardzo malownicze. Jeśli o mnie chodzi to letni tuning też powinien się tam odbyć.

Edit:
Wideo z tej prezentacji możecie już obejrzeć tutaj.

Myślę, że czasem świadomość, że istnieje coś takiego pozwala na bardziej świadome wytwarzanie kodu i zaciąganie ciut mniejszego długu. Powodzenia!

Poniżej inne ciekawe nowe artykuły, które powinny zainteresować programistów:
projektowanie kodu:
Stosuj zasady programowania funkcjonalnego
projektowanie interfejsu:
Zapytaj “Co zrobiłby użytkownik?

<?php
$i = 0;
foreach ($tracks as $track):
	$class = null;
	if ($i++ % 2 == 0) {
		$class = ' class="altrow"';
	}
?>
	<tr<?php echo $class;?>>
		<td>
			<?php echo $track['Track']['id']; ?>
		</td>
		<td>
			<?php echo $track['Track']['name']; ?>
		</td>
		<td>
			<?php echo $track['Car']['name']; ?>
		</td>
		<td>
			<?php echo $track['Track']['begin']; ?>
		</td>
		<td>
			<?php echo $track['Track']['end']; ?>
		</td>
		<td>
			<?php echo $track['Track']['length']; ?>
		</td>
		<td class="actions">
			<?php echo $html->link(
			   __('Edycja', true),
			   array(
			      'action' => 'edit',
			      $track['Track']['id'] ,
			      $track['Car']['id']
			   )
			  );
			?>

		</td>
	</tr>
<?php endforeach; ?>
</table>

Chce Ci się pisać ten kod kilkadziesiąt razy w jednym projekcie? Mnie też nie. Dlatego napisałem prosty element, który to trochę automatyzuje (nazwałem go “list”):

// app/views/elements/list.ctp
<?php
   $i = 0;
   foreach($elements as $key => $element):
   $class = null;
   if ($i++ % 2 == 0) {
      $class = ' class="altrow"';
   }
?>
   <tr <?php echo $class?>>
      <?php foreach($fields as $path): ?>
         <td>
            <?php echo Set::classicExtract($element, $path) ?>
         </td>
      <?php endforeach; ?>
         <?php if(isset($links)): ?>
            <td>
               <?php foreach($links as $name => $url): ?>
                  <?php
                     if(!is_array($url["params"])) {
                        $url["params"] = array($url["params"]);
                     }
                     foreach($url["params"] as $key => $path){
                        $url[$key] = Set::classicExtract(
                           $element,
                           $path
                        );
                     }
                     unset($url["params"]);
                  ?>
                  <?php echo $html->link($name, $url)?>
               <?php endforeach; ?>
            </td>
         <?php endif; ?>
   </tr>
<?php endforeach; ?>

Jego użycie jest dość proste. Dla przykładu wygenerujemy ten sam “output” dla pierwszego listingu z tego postu:

echo $this->renderElement(
         "list",
         array(
            "elements" => $tracks,
            "fields" => array(
               "Track.name", "Car.name", "Track.begin",
               "Track.end", "Track.length"
            ),
            "links"=> array(
               "edycja" => array(
                  "controller"=> "tracks", "action"=> "edit",
                  "params" => array(
                     "Track.id", "Car.id"
                  )
               )
            )
         )
      )

Opiszę poszczególne parametry przekazywane do tego elementu:

• “elements” – kolekcja (w tym wypadku tablica) elementów zwrócona na przykład przez $this->Track->find(“all”)
• “fields” – pola, które mają się pojawić w komórkach tabeli
• “links” – tu definiujemy jakie linki mają się pojawić w ostatniej kolumnie (zazwyczaj tam znajdują się “opcje”). Indeksy kolejnych elementów to nazwy linków (tutaj “edycja”).
  • “controller” i “action” są identycznie używane jak w metodzie HtmlHelper::link()
  • “params” jest dość ciekawy. Jeśli chcemy w wygenerowanym linku mieć jeden parametr (najczęściej id), robimy to tak:

                "edycja" => array(
                   "controller"=> "cars", "action"=> "edit", "params"=>"Car.id"
                ),
    

    gdy parametrów ma być więcej – ścieżki do nich przekazujemy w tablicy (tak jak w przykładzie):

                    "edycja" => array(
                       "controller"=> "tracks", "action"=> "edit",
                       "params" => array(
                          "Track.id", "Car.id"
                       )
                    )
    

    Można także używać parametrów typu “named”, wystarczy podać dodatkowo indeksy:

                    "edycja" => array(
                       "controller"=> "tracks", "action"=> "edit",
                       "params" => array(
                         "parametr_1"=> "Track.id", "parametr_2"=> "Car.id"
                       )
                    )
    

Zachęcam do korzystania z tego elementu i zgłaszania wszelkich niedociągnięć :)

Przede wszystkim – iteracje (trzytygodniowe).
Właśnie zakończyliśmy pierwszą. Odbyła się prezentacja iteracji, na której niestety nie było klienta. Był za to szef w roli klienta wewnętrznego- to on bywał na spotkaniach z klientami, więc był najlepszym substytutem na jaki nas było stać.

Ze scrum używamy dziennika zaległości produktowych (product backlog), który ciągle się rozrasta. Na razie sukcesem jest to, że przed końcem pierwszej iteracji w dzienniku mieliśmy wystarczająco elementów, żeby zacząć następną.

Tak wygląda wykres burndown dla zakończonej właśnie iteracji:

Staramy się stosować stopniowe zbieranie wymagań i stopniowy rozwój architektury z tym, że to drugie przetestowaliśmy już wcześniej w mniejszych pod-projektach. Pomijając fakt, że jest to zwyczajnie przyjemne podejście – gdybyśmy chcieli zebrać wszystkie wymagania, to trwałoby to do końca października. Gdyby jeszcze do tego projektować wszystko “z góry” – następny miesiąc by minął do startu projektu.

Po pierwszej retrospekcji doszliśmy do wniosku, że zbyt mało energii zostało włożone w etap planowania iteracji. Tym razem bardziej się na tym skupiliśmy. Jednak efekty, jeśli będą widoczne, to dopiero podczas kolejnej iteracji.

Udało nam się też wykonać krok w kierunku ciągłej integracji (CI):
- używamy MySchemaShell do migracji struktury bazy danych
- własnego narzędzia dla startowych danych testowych (też programik Shell) + do generowania obiektów ACL
- Selenium dla prostych (na razie) testów interfejsu, dla zabezpieczenia się przed sytuacją, gdy jest dwie godziny do prezentacji iteracji, nie ma odważnego do przeklikania systemu w celu znalezienia wpadek. No i te wpadki znajduje klient. Te testy trochę trwają, ale na pewno mniej niż ręczne “śmiganie po stronie”.

Co do testów jednostkowych – na razie jest plan, aby umieszczać je w krytycznych miejscach. Co w praktyce oznacza testowanie reguł biznesowych umieszczonych w warstwie modelu.

Jeśli pojawi się więcej ciekawostek – na pewno nie omieszkam napisać.

1. Agile Software Development. Gra zespołowa. Alistair Cockburn
   
   

   Agile Software Development. Dużo teorii i dużo informacji

   
   
   Bardzo dobra pozycja, choć dość trudna w odbiorze. Charakteryzuje się dość wysokim poziomem abstrakcji. Ale dzięki niej można zrozumieć dlaczego agile działa, a nawet kiedy nie działa i dlaczego. Autor jest też twórcą rodziny metodyk Crystal i z tej książki dowiesz się o nich co nieco. Jeśli na temat stosowania Agile chcesz poznać wszystkie sekrety i mechanizmy stojące za jego siłą – to pozycja dla Ciebie. Jeśli nie jesteś gotowy na teoretyczną przeprawę – rzuć okiem na pozycje poniżej.

2. Agile Development. Filozofia programowania zwinnego. James Shore, Shane Warden
   

   Agile Development. Równowaga między teorią a praktyką stosowania XP

   
   To nieco lżejsza pozycja, bardziej traktująca o tym jak używać (w tym przypadku XP), a nie jak działa. Z tej książki poznasz dokładnie wszystkie elementy XP, łącznie z tymi najbardziej subtelnymi. Dowiesz się dlaczego programowanie w parach jest równie skuteczne, co dziwaczne (na pierwszy rzut oka). Jeśli jesteś szefem programistów – zrozumiesz dokładniej co programiści robią podczas pracy. Dowiesz się, że jeśli nie klepią w klawiaturę, to jeszcze nie oznacza, że nie pracują. Pozycja obowiązkowa dla tych, którzy chcą z powodzeniem stosować XP. Dla osiągnięcia mistrzostwa prawdopodobnie po pół roku używania XP warto by do niej wrócić.
3. Head First Software development. Dan Pilone, Russ Miles
   
   

   Head First Software Development. Zestaw praktyk w lekkiej i przystępnej formie

   
   Najlżejsza pozycja w zestawienia, jednak również wartościowa. Nie przedstawia z sobą żadnej konkretnej metodyki. Choć może raczej nie przedstawia żadnej nazwanej metodyki. Jest to zbiór prostych praktyk, które usprawnią działanie Twojego zespołu. Przykłady zamieszczone są w języku Java, ale pozycja przydatna nawet dla tych co Javy nie znają (jak ja, kiedy zaczynałem tą książkę czytać). Wiele ćwiczeń, pytań i wszystkiego, co sprawi, że nawet jeśli zdiagnozowano u Ciebie ADHD – wciągnie Cię i niewielkim wysiłkiem poznasz podstawy zwinnego wytwarzania oprogramowania.

Miłej lektury.

Ps. jeśli sam(a) chcesz mi coś polecić – wrzuć to koniecznie do komentarza – nie mogę się doczekać.

]]> http://blog.grzegorzpawlik.com/2009/06/jaka-ksiazke-warto-przeczytac-aby-poznac-agile/feed/ 2 http://blog.grzegorzpawlik.com/2009/06/refactoring-pracy-magisterskiej/ http://blog.grzegorzpawlik.com/2009/06/refactoring-pracy-magisterskiej/#comments Sun, 14 Jun 2009 12:49:08 +0000 Greg http://blog.grzegorzpawlik.com/?p=253 Continue reading →]]> Sobota (wczoraj)

http://helion.pl/view/4113g/agilsd.htm

To było jak olśnienie. Okazuje się, że refactoring to nie jest coś co tylko programiści mogą robić. Oto jak było.

Od miesiąca nie przybyło w mojej pracy magisterskiej więcej niż 2 strony. Nie mogłem się zabrać. Jak się zabierałem – szybko kończyły mi się pomysły, nie miałem ochoty więcej rozwijać wątków. Miałem wrażenie, że nic nowego tam nie dodam. Aż wczoraj wracając z wykładu przedmiotu “Koncepcje zarządzania” (o Lean management, banchmarkingu, outsourcingu itp. – inspirujące tematy) pomyślałem, że trzeba coś z tym zrobić.

Miesiącami już czytam o zwinnym wytwarzaniu oprogramowania. Niedawno w książce “Agile Software Development. Gra zespołowa” doszedłem do miejsca, w którym autor, Alistair Cockburn, opisał jak wykorzystał podejście zwinne przy rozbudowie domu (!). Wracając ze wspomnianego wykładu pomyślałem- skoro piszę pracę o zwinnym wytwarzaniu (oprogramowania), to może napiszę ją w sposób zwinny?

Po pierwsze postanowiłem znokautować swój pierwszy problem: nie wiedziałem na jakim etapie jestem. Brakowało mi informacji mimo, że mój zespół składał się tylko ze mnie – potrzebowałem radiatora informacji mimo, że jedynie ja miałbym z niego korzystać. Kupiłem korkową tablicę (miałem ochotę na “suchościeralną”, ale a/ była sobota i jeden sklep papierniczy był otwarty w okolicy b/ to wersja ekonomiczna: 60x40cm ok.20zł). Po powrocie do domu, przy pomocy dratwy przymocowałem ją do regału nad monitorem. Jest “Wystarczająco stabilna”

Miałem już radiator, teraz pora zacząć od podstaw: ustalić misję, cel projektu. Na niedużej kartce (takiej do notowania) napisałem mazakiem “Cel pracy”
i przykleiłem do niej 3 karteczki z powodami dla których w ogóle się tym zajmuję, zamiast na przykład wspinać się po górach. Po chwili uznałem, że warto ustalić im ważność. Dopisałem w nawiasie “wysokość ma znaczenie” i narysowałem podziałkę ;). Poniżej wrzucę efekty, jak tylko będę miał w rękach aparat.

Po drugie potrzebowałem “opowieści”, głównie po to, aby móc stosować “energiczną pracę”. Znam siebie na tyle, że wiem iż kiedy mam niepustą kolejkę zadań do wykonania – wtedy pracuję wydajniej. Zawsze mogę sięgnąć po następne zadanie – nie tracę czasu na zastanawianie się “co teraz?”. Na tablicy pojawiły się karteczki z nazwami danych obszarów: “Do zrobienia”, “W trakcie”, “Zrobione” :)

Postanowiłem postawić sobie krótkie zadanie do wykonania, aby szybko otrzymać nagrodę w postaci jego wypełnienia. Cały czas tytuł mojej pracy nie był ostateczny. Choć należałoby powiedzieć raczej, że był bardzo wstępny. Źle się z tym czułem, bo też mi się nie podobał, trącił trywialnością. Brzmiał “Możliwość zastosowania Zwinnej metodyki budowania aplikacji internetowych w firmie X”. Nawet gdyby zmiana tytułu miała polegać na zmianie błędu “zwinnej metodyki” na “zwinnych metodyk” – to był sukces, którego potrzebowałem.
Jednak podczas wypełniania karteczki z opowieścią, w której chciałem opisać mniej więcej co jest do zrobienia pojawił się pomysł i zanotowałem:

Może warto zmienić na “Nowoczesne metodyki wytważania wytwarzania oprogramowania; Agile; możliwość zastosowania w mikroprzedsiębiorstwach na podstawie firmy X”

Potem dokleiłem karteczkę “elasyczne, zwinne zamiast *nowoczesne*” i drugą “drugi temat pozwala skupić się na Agile zamiast na firmie”.

Efekty mi się podobały. Pomyślałem, że ta zmiana powinna zostać skonsultowana z moim promotorem. Zmniejszyłem nieco obszar “Zrobione”, który nie jest istotny pod względem informacyjnym – rosnący tam pęk zadań ma sprawiać, że będę się czuł pracowity :D; dodałem obszar “Skonsultować z promotorem” i tam wbiłem zadanie z tytułem.

Przyszedł czas na zadanie numer dwa. Jakiś czas temu M (nie wiem, czy pozwoli ujawnić swoje imię), kolega z pracy, zagaił mnie o magisterkę. Sam jest prawie rok po obronie. W dyskusji wyjawił, że gdy już miał spis treści – bardzo łatwo mu się pisało, gdyż po prostu pisał o tym o czym dany podrozdział miał traktować. Ja miałem odczucie, że mój spis treści jest zabałaganiony. Dlatego zadanie numer 2 brzmiało: “Uporządkować spis treści”.

Spis treści jest krajobrazem mojej pracy, dlatego go wydrukowałem, aby móc nad nim kontemplować. Wyglądał mniej więcej tak:

Wstęp

1. Zapotrzebowanie na metodyki
2. Ogólnie o metodykach
3. Przykłady metodyk zwinnych
4. Typowe problemy w firmie X
5. Metodyki zwinne (Agile)
6. Konfrontacja teorii z rzeczywistością

Po pierwsze postanowiłem połączyć rozdział 2 z 3 – w końcu były niemal o tym samym. A treść zawarta w rozdziale 2 sprawiała, że nie miałem o czym pisać w rozdziale 3. To samo tyczyło się rozdziałów 4 i 6 – nabazgrałem między nimi linię opatrzoną opisem “połączyć”.
Rzuciłem okiem na nowy pomysł tytułu, który mi się spodobał bardziej. Pomyślałem, że fajnie przesunął ciężar pracy z implementacji metodyki w firmie X, na opisanie metodyk zwinnych. Pomyślałem, że spis powinien oddawać kolejność zaproponowaną w tytule, tym bardziej, że tytuł oddawał to o czym chciałem pisać. Nabazgrałem kilka strzałem z przesunięciem rozdziału 5 na przedostatnią pozycję. Teraz spis miał sens – drzewa były “zielonym do góry;)”. Policzyłem jeszcze ile będzie “nowych” rozdziałów, żeby ich nie było za mało. Z 8 liczba spadła do 6. Projekt uległ uproszczeniu, stał się bardziej przejrzysty.

Zatem zabrałem się za przenoszenie akapitów w pracy w taki sposób, aby wygenerowany spis treści był taki jak chciałem. W trakcie tych czynności pomyślałem, że przeprowadzam właśnie refactoring mojej pracy magisterskiej. Ucieszyłem się i z tej radości napisałem “refactoring :)” na przylepnej, żółtej karteczce i ustawiłem sobie opis na skype “refactoring pracy magisterskiej”. Taka była moja radość.

Gdy skończyłem – wpiąłem zadanie w miejsce “Skosultować z promotorem”; wygenerowałem dwa pdfy ze starym i nowym spisem treści i wysłałem maila do doktora B, z nowym pomysłem tytułu, uzasadnieniem i spisami treści.

W międzyczasie pojawił się pomysł na kolejne zadanie. Otóż czytając książki (źródła ;)) nauczony doświadczeniem – sporo bazgrałem, zaznaczałem ciekawe fragmenty itd. Gdybym tego nie zrobił – straciłbym przemyślenia, które pojawiały się podczas czytania (często w krakowskich tramwajach). Nie miałbym też ochoty drugi raz brnąć przez lekturę (nie chodzi o to, że nieciekawą – ale mam znam kilka większych przyjemności niż czytanie dwa razy tej samej książki, na przykład przeczytanie dwóch książek raz :D).

Teraz miałem 6 książek: 2 przeczytane w całości (w tym “Marsz ku klęsce” Yourdona), jedną przeczytaną tak daleko jak wydało mi się konieczne, 2 w trakcie czytania oraz jedną ledwie liźniętą. Łącznie mają już w sobie kilka dobrych gram grafitu ołówków z ikei (mały czasem może więcej). Problem polegał na uporządkowaniu tej wiedzy. Trzecie zadanie “Uporządkowanie źródeł” zostało wbite w strefę “do zrobienia”. Pojawiło się na niej 6 karteczek – jedna dla każdego tytułu.

W międzyczasie moja ukochana wróciła z zajęć, więc praca była tego dnia skończona. Całe szczęście – nie przeszkadza jej spora tablica korkowa zasłaniająca pół regału :D

Niedziela.

Zabrałem pierwszą i wkleiłem w miejsce “W trakcie”. Przeglądałem wypatrując zakreśleń, gdy je namierzałem – opisywałem o czym jest i wklejałem zakładkę. Mniej więcej w połowie przyszedł czas na przerwę: picie zimnej kawy, głośne słuchanie muzyki, telefon do przyjaciela (serio).

Teraz karteczka “Cockburn” jest skreślona (znaczy skończona) i wróciła na kartkę opowieści. Zabrało mi to nieco ponad 3 godziny. Jednak na pierwszy ogień postanowiłem wziąć zadania trudniejsze, żeby po dwóch największych skarbnicach grafitu mimo zmęczenia móc na luzie dokończyć pracę. “W trakcie” jest teraz Shore, ale zanim zacznę – miałem ochotę napisać ten post.

Teraz wracam do porządkowania źródeł. Gdy w tej sprawie coś się pojawi jeszcze ciekawego, na pewno o tym napiszę.

]]> http://blog.grzegorzpawlik.com/2009/06/refactoring-pracy-magisterskiej/feed/ 3