Jesteś kompletnie zielony, więc cykl pracy wygląda mniej więcej tak:

1. nowy problem
2. google
3. znajdujesz tutorial (lub odpowiedź na stack-overflow), który go (lub wystarczająco podobny) rozwiązuje
4. implementujesz rozwiązanie zgodnie z tekstem
5. dostosowujesz do swoich potrzeb
6. powtarzasz cykl

Po pewnym czasie listę można zredukować o punkt 4 – od razu przystępujemy do modyfikacji. Po kolejnych cyklach pomijamy punkt 2 i wiemy, że analogie są w napisanym przez nas kodzie- musimy sobie przypomnieć “jak to się robiło”. Coraz mniej też jest problemów, które w ten sposób potrzebujemy rozwiązać aż w końcu sięgamy po tą technikę tak rzadko, że już nie można mówić o Tutorial Driven Development. Czujemy się swobodnie z nową technologią, a z tąd już prosta (choć długa) droga do zostania ekspertem.

foto: Sigurd R

Ps. Ten wpis miał być humorystyczny, ale w trakcie pisania uświadomiłem sobie, że opisuję koncepcję Shu-ha-ri).

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.

Ale wróćmy do głównego wątku. Jeśli nie byłeś nigdy członkiem takiego zespołu, a chciałbyś takim zarządzać, to czytaj uważnie.

Z natury jestem leniwy. Ale jestem dość specyficznym leniem, który nie lubi nic nie robić. Dlatego w ogóle zostałem programistą – lubię automatyzować i ulepszać rzeczy, które są nudne i żmudne do ręcznego wykonywania.

Zatem zaczął mi doskwierać pewien proces. Przy pewnym projekcie dość często musimy aktualizować utrzymywane systemy, które mają kilka instancji(w tej chwili 3, a ma być więcej). Wygląda to mniej więcej tak:

1. zaloguj się na serwer
2. cd instancja#1
3. git pull
4. wpisz hasło
5. odpal migrację
6. cd ../instancja#2
7. git pull
8. wpisz hasło
9. odpal migrację
10. cd ../instancja#3
11. git pull
12. wpisz hasło
13. odpal migrację
14. TADA!

Serio. Pierwszym krokiem było napisanie skryptu, które te kroki odpala samodzielnie. Zaczęło to wyglądać tak:

1. zaloguj się na serwer
2. ./update-me.sh
3. wpisz hasło
4. wpisz hasło
5. wpisz hasło

Drugim krokiem było skonfigurowanie GITa tak, aby nie wymagał hasła na niektórych maszynach (przy pomocy kluczy rsa) Proces uprościł się do

1. zaloguj się na serwer
2. ./update-me.sh

Jaki jest efekt? Pierwszy, który się narzuca to oszczędność czasu. Zakładając, że taki update odbywał się 3 razy dziennie to zaoszczędziliśmy jakąś minutę. Nie wydaje się to rozsądne, gdyż oba zadania zajęły mi kilka godzin. Z księgowego punktu widzenia mamy stratę.

Jednak uważny obserwator mógł stwierdzić, że mamy w tym projekcie instancję główną i “towarzyszące”. W pierwotnym, ręcznym, procesie pozostałe dwie często zostawały w tyle. Rodziło to problemy przy testowaniu i mergowaniu zmian.

Dodatkowo prosty update to częsty update, zatem i testerzy nie muszą się dopraszać, żeby zaktualizować wersje, bo zwyczajnie są w najnowszej wersji.

Wracając do mojej tezy: Zespół to maszyna, programiści to (nie tak łatwo wymienialne) trybiki, procesy to miejsca, gdzie trybiki i inne części się ścierają. Niedoświadczonemu operatorowi może się wydawać, że przestoje spowodowane oliwieniem maszynerii to stracone pieniądze. W końcu przez te X godzin mogła wyprodukować Y $$$.

Refaktoring, automatyzacja i inne usprawnienia oliwią procesy w zespole programistów. Gdy nie ma niepotrzebnych tarć można rozwinąć optymalną prędkość, a awarie są mniej prawdopodobne.

Ciekawa analiza czterech gigantów: Apple, Google, Microsoft i Google.

I dlaczego Amazon jest na dobrej drodze, aby osiągnąć dominację na rynku?

Pozwolę sobie zacytować charakterystykę wielkiej czwórki z tego artykułu

Why Amazon will lead the big four:

• Apple sells content and writes software to sell hardware. It is a hardware company.
• Microsoft sells content and makes hardware to sell software. It is a software company.
• Google sells or gives away content and software to sell advertisements. It is an ad sales company.
• Amazon sells or gives away hardware and software to sell content. It is an online retailer — a content

company.

Interesujące przemyślenia dotyczące technologii flash i jej przyszłości

Czy flash ma przyszłość?. Co myśli o tym Steve Jobs i Dean Hachamovitch (jeden z leaderów zespołu w Microsofcie)?

Bardzo ciekawy fragment, który oddaje filozofię Apple, jako całości:

If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

Przyznam się, że też za flashem nie będę płakał. Nigdy nie miał sensownego wsparcia na platformy linuxowe. Do niedawna domyślnie każdy element flash miałem zablokowany (flashblock)…

Dla tych, którzy lubią społeczne aspekty sieci i marketingu…

Poradnik jak przygotować skuteczną infografikę. Jeśli przygotujesz jakąś przy pomocy tych wskazówek – pochwal się proszę w komentarzu.

Dla estetów i całej reszty

Ci pierwsi dostaną argumenty za, ci drudzy mają okazję przekonać się dlaczego jest istotna i skąd czerpać odpowiednią wiedzę o typografii.

I na koniec, żeby było coś o projektach stricte informatycznych.

Kto rozwija plany testów dla oprogramowania open-source? Kto aktualizuje zrzuty ekranów w instrukcji użytkownika i pomocy online? Oraz kto tłumaczy dokumentację na polski i turecki? Kto weryfikuje, czy dana funkcjonalność nie łamie Amerykańskiej Ustawy o Niepełnosprawnych, bądź Niemieckich Praw odnośnie Prywatności? Wtedy, gdy pracowałem nad Linuxem, odpowiedzią było “Nikt. Nie ma czegoś takiego jak plan testów, drukowana instrukcja użytkownika, jedyną dokumentacją, jaka istnieje, to ta po angielsku, oraz nikt nie przejmuje się zgodnością z jakimikolwiek prawami.” Może coś się pozmieniało od tamtego czasu.

Dowiedz się dlaczego open source’owi lżej na sercu?

Przy okazji (jeśli dotarłeś aż tutaj, to znaczy, że artykuł jest wystarczająco ciekawy)

Noszę się z zamiarem kupna kindle’a (nie tabletu), żeby między innymi mieć szybki dostęp do dobrej literatury branżowej (czyli anglojęzycznej) i artykułów takie jak te powyżej. Zatem jeśli mój blog wydał Ci się pomocny, jeśli wydaje Ci się, że jest coś wart – możesz rozważyć zafundowanie mi bonu podarunkowego amazona. 1$ jest super kwotą – możesz zapłacić na przykład z paypall’a. Możesz mi go wysłać na adres podaruj.mi.kindle@gmail.com :)
Jeśli masz blog, to w wiadomości umieść swój adres – umieszczę go na swojej stronie, jeśli zechcesz.
Będę też zachwycony, jeśli dołączysz też jakąś osobistą wiadomość od siebie.

Często zdarza mi się słyszeć lub czytać takie zgłoszenie. Sęk w tym, że dodane X spowodowało wiele procesów automatycznych w aplikacji, czyli dodanie A, usunięcie B i zmianę statusów w C i D. Tak wyglądają złożone systemy informatyczne, o czym wielu użytkowników zwyczajnie nie wie (po to ukrywamy tą logikę w aplikacji, abyś Ty mógł wydajnie pracować nie myśląc o tych wszystkich szczegółach).

Zatem tracimy czas, żeby przeanalizować potencjalne skutki usunięcia X oraz na szukanie sposobów na przywrócenie spójności systemu po tej operacji chirurgicznej. Aż w końcu okazuje się, że samo istnienie błędnego X w systemie w niczym nie przeszkadza – ma być zwyczajnie niewidoczny na wydruku Z, który idzie do klienta.

Gdybyś od razu powiedział szczerze czego potrzebujesz – dałbym Ci to w 5 minut!

No właśnie… gdybyś nie mówił mi co mam robić, a zamiast tego powiedział mi czego potrzebujesz. Umówmy się: Ty jesteś specjalistą od używania systemu, ja jestem specjalistą od mechaniki jego działania. Nie mówisz swojemu mechanikowi, którą śrubę ma dokręcić – mówisz mu, że tu stuka… a ma nie stukać.

Bądź precyzyjny w kwestii swoich potrzeb.

Wchodząc w szczegóły techniczne może się wydawać, że zyskujemy precyzję, ale tak naprawdę tracimy kontekst. Kontekst pozwala mi znaleźć takie rozwiązania Twoich rozterek, które będą współgrały z aktualnymi mechanizmami aplikacji, zamiast je rozrywać na kawałki.
Gdy go nie ma, musimy wyjść najpierw od szczegółu, do ogółu i z powrotem. To dłuższa i niepotrzebna droga.

Jakość zewnętrzna to wszystko to, co widzi użytkownik. To funkcje jakie spełnia aplikacja. Nie chodzi jedynie o usability i kwestie związane z wyglądem zewnętrznym. Też o jakość zaimplementowanych możliwości. Czy po kliknięciu drukuj pojawia się dialog drukowania, czy pdf do ściągnięcia, którego można wydrukować po otwarciu? Czy cały proces biznesowy jest obsługiwany, czy może o część elementów dbają użytkownicy? Czy elementy z zewnętrznych systemów importują się perfekcyjnie, czy w 10% potrzebna jest interwencja użytkownika lub nawet programisty?

Niższa jakość zewnętrzna nie zawsze oznacza, że jest źle. To jest decyzja, którą podejmuje właściciel produktu (product owner) pod warunkiem, że dysponuje pełną informacją o sytuacji. Jeśli wie, że perfekcyjny import opóźni wdrożenie o cały miesiąc, a “prawie dobry” oznacza wykorzystanie okazji biznesowej już teraz (relatywnie niewielkim nakładem pracy ludzi) – może wybrać opcję “prawie dobrą”. Oczywiście może poprosić o wersję idealną przy kolejnej iteracji.

Jakość wewnętrzna zkolei to coś, czego zrozumienie przychodzi ciężko czasem nawet programistom. To brak długu technicznego (przykład), podatność kodu na zmiany wymagań, niewrażliwość na regresję (wprowadzanie błędów wraz z nowym kodem, powracanie tych już naprawionych).

Jakość wewnętrzna aplikacji jest nienegocjowalna w zespołach Agile.

Gdy jest ona niska, nowe błędy są odkrywane przy każdym wdrożeniu, Twoja aplikacja choruje, a zespół traci czas na jej łatanie – wolniej implementuje nowe elementy. Sponsor/właściciel produktu nie wykorzystuje w pełni nadarzających się okazji na rynku. To wszystko trwa aż do dramatycznego momentu, kiedy okazuje się że nie da się już produktu rozwijać. Pomyśl tylko… zespół programistów dwa lata rozwijał aplikację i teraz musi zacząć od nowa. Aplikację, na którą wydałeś setki tysięcy złotych. I jedyne co masz, to doświadczenie Twoich programistów (o ile cały zespół nie wymienił się w tym czasie przynajmniej raz). Dla nich to świetne szkolenie, ale z Twojego punktu widzenia niezbyt opłacalne.

Znam trzy narzędzia, które dbają o wysoką jakość wewnętrzną.

Pierwszy (nietechniczny) już podałem: jakość wewnętrzna nie podlega negocjacji. Gdy product owner chce importu, ale nie ma czasu zaimplementować go perfekcyjnie – nie jest opcją zaimplementowanie go na szybko w technologii spagehetti code. Możesz negocjować zakres funkcji do zaimplementowania, nigdy jakość wewnętrzną. Klient nawet nie powinien znać opcji “super szybkiej”, z dwóch powodów:

1. na pewno by ją wybrał, ponieważ…
2. nie wie, że to zabije jego projekt

Posługując się analogią budowlaną: Klient chciałby mieć tańszy dom. Wykonawca proponuje zamiast wylania fundamentów (co trwa i kosztuje) wsypanie do wykopu śmieci, które ma z poprzedniej budowy. Klient oczywiście się nie zgadza, bo to śmiertelne zagrożenie dla jego rodziny. Oczywiście w naszym kraju to jest niemożliwe – kierownik budowy poszedłby do więzienia. IT nie ma nadzoru budowlanego – nieszczęście w szczęściu ;)

Pozostałe (techniczne): refaktoring kodu i testy. Refaktoring (czy refaktoryzacja) usuwa dług techniczny, który zawsze zaciągasz rozwijając aplikację. Aktywnie z nim walczy, stale przebudowując kod usuwając powtórzenia i poprawiając architekturę systemu.

Jednak refaktoring jest strasznie trudny. Nowe funkcje mogą wprowadzić nowe i przywrócić stare błędy. Zmiana kodu, która nie wprowadza nowych funkcji, ale wprowadza błędy w ogóle nie jest sexy. Dlatego potrzebujesz automatycznych testów.

Testy jednostowe, testy integracyjne i wszystkie inne jakie jesteś w stanie zautomatyzować mogą ochronić Cię przed regresją kodu. Dzięki nim programista nie boi się refaktoringu – zmienia, klika – widzi wielki zielony napis “OK” i jest szczęśliwy.

Takie podejście zwraca się w długim terminie. Życzę wszystkim, aby mieli okazję pracować którzy potrafią tak daleko patrzeć.

Niestety – często wychodzi i trudno go złapać. Twoi magazynierzy bez wózka nie mogą wykonać wszystkich swoich zadań i w końcu okazuje się, że siedzą bezczynnie. Po jakimś czasie znajdujesz chochlika, albo udaje Ci się do niego dodzwonić. Niestety wskazówki przez telefon są nieprecyzyjne, więc szukanie wózka zajmuje więcej czasu.

Kiedy magazynierzy nie pracują towaru zaczyna brakować na półkach – klienci odchodzą do konkurencji i tracisz pieniądze.

Jesteś menadżerem. Co zrobisz?

Ważne! Nie możesz się pozbyć chochlika. W magicznej krainie każdy supermarket musi mieć chochlika – bez niego znika ;)

Masz jakiś pomysł?

Ja zrobiłbym wszystko, aby zatrzymać chochlika na magazynie w godzinach pracy. Zapłać mu, urządź mu przytulną norkę – sprowadź wszystkie wygody, których potrzebuje, aby nie chciał wychodzić.

Jeśli się nie uda – kup mu komórkę i błagaj, żeby miał ją włączoną i zawsze przy sobie.

Mimimalizuj szkody, które się wydarzają, gdy chochlika nie ma pod ręką!

W projekcie IT właściciel produktu (product owner) jest takim chochlikiem. Nigdy nie wyjawi Ci wszystkich szczegółów na temat funkcji, której potrzebuje. Nie złośliwie – po prostu myśli o swoim biznesie, a nie o zależnościach i ograniczeniach w oprogramowaniu, które ten biznes ma wspierać. To Twoje zadanie.

Zrób wszystko, żeby product ownera mieć pod ręką. Jeśli to jest niemożliwe – zorganizuje gorącą linię. Uświadom mu, że bez jego wiedzy projekt stoi. Programiści muszą zgadywać i zawsze zgadną źle. Albo zaimplementują coś zbyt luźno i trzeba będzie poprawić (a błąd, który trafił na produkcję jest droższy!) albo zbyt restrykcyjnie i stracą cenny czas na implementację zbyt skomplikowanych ograniczeń. Czasem zgadną dobrze, ale nikt nie nie trafia szóstki co losowanie…

Jeśli nie możesz w każdej chwili skontaktować się z product ownerem – nie jesteś zwinny. Albo Twoje ruchy są zbyt ograniczone strachem przed podjęciem błędnej decyzji… albo próbując iść do przodu wyrządzasz szkody, jak słoń w składzie porcelany.

Nie każ swoim programistom czekać na wyjaśnienia. Posadź z nimi product ownera. Jak nie chce – wprowadź programistów do siedziby jego firmy.

Co to znaczy, że zespół jest zwinny?

Po pierwsze – to nie jest kwestia tego czy jesteś zwinny czy nie. Pytanie brzmi: jak bardzo jesteś zwinny?

Zwinny – potrafiący sprawnie reagować na zmiany. Głównie wymagań klienta, które wynikają ze zmian otoczenia (biznesowego, technologicznego).

Zespół jest zwinny, jeśli ma z tyłu głowy informację “wszystko się zmienia”. Jeśli zespół marudzi, że klient powiedział tak i powinien się tego trzymać, to ma problem ze zwinnością.

To są podstawy, każda z metodyk ma swoje narzędzia, którymi wspiera zwinność zespołu.

Niektóre elementy ważne dla Twoje zwinności:

• Twój kontakt z właścicielem produktu
• Wewnętrzna jakość

O szczegółach napiszę później nieco więcej, więc Będę pisał o kolejnych elementach, więc podepnij się proszę pod kanał rss (albo pozwól na powiadamianie przez e-mail)

System do tej pory, dla każdego rodzaju rezerwacji wyliczał status rezerwacji (nowa, w trakcie, zakończona) w sposób dynamiczny. Rezerwacja stolika w restauracji jest zakończona, kiedy w systemie widnieje płatność za posiłek. Dla koparki to już za mało: musi zostać wystawiona faktura, istnieć przelew, a poza tym musi zostać dołączony dokument odbioru sprzętu w dobrym stanie.

Teraz okazuje się, że warto (ze względu na wydajność) zapisywać status jako cache, aby nie musieć wyliczać go za każdym razem. Rozważmy teraz dwa podejścia do migracji.

System z niskim (albo żadnym) poziomem abstrakcji, czyli pliki sql…

Masz dobre narzędzie, w którym możesz przeprowadzić migrację struktury bazy. Bez problemu napiszesz zapytanie alter table, dodasz pole. Jednak jeśli chcesz w tym samym systemie zmigrować dane (czyli dla wszystkich istniejących już rezerwacji na produkcji wyliczyć status i ustawić go w nowym polu) masz dwa wyjścia.

Albo napiszesz logikę biznesową odpowiadającą za wyliczanie statusów po raz drugi, albo napiszesz osobny skrypt, który będzie miał dostęp do obiektów biznesowych, gdzie zwyczajnie wywołasz metodę i jej wynik zapiszesz w nowym polu.

Pierwsze rozwiązanie jest oczywistą stratą czasu, no i oczywiście ryzykujesz wprowadzenie nowych błędów do systemu. W drugim przypadku, musisz zapamiętać że przy wdrożeniu nowego rozwiązania należy odpalić skrypt migracji. Jedna migracja z drugą nie są powiązana, a być powinny – uruchomienie jednej bez drugiej, albo w osobnej kolejności nie ma sensu.

Liquidbase

Tu warto wspomnieć o systemach, które wprowadzają pewien poziom abstrakcji (np. liquidbase), jednak jest to jedynie abstrakcja od silnika bazy danych. Nadal niestety nie mają one dostępu do obiektów biznesowych.

System o wysokim poziomie abstrakcji, zintegrowany z całą aplikacją

Oczywiście mam tu coś konkretnego na myśli. Najlepszym przykładem jaki znam są migracje w Ruby on Rails. Rozwiązanie wyglądałoby mniej więcej tak (pseudoPHPkod)

 class Migration1 {
   function up() {
     /* struktura */
     dodaj_pole_do_tabeli("rezerwacja", "status", "integer");
     /* dane */
     $rezerwacje = pobierz_wszystkie_rezerwacje(); //2
     foreach($rezerwacje as $rezerwacja) {
         $rezerwacja->status = $rezerwacja->wyliczStatus();
         $rezerwacja->zapisz();
     }
   }
   function down(){
     usun_pole_z_tabeli("rezerwacja", "status")
   }
 }

Widać tu wyraźnie, że migracja jest jednym spójnym krokiem. Migracja struktury i następująca zaraz po niej migracja danych. Sama klasa migracji ma bezpośredni dostęp do warstwy logiki biznesowej i może z niej bez przeszkód korzystać.

Piszę to dlatego, ze próbowałem pierwszego sposobu, gdyż jest on łatwiejszy w implementacji, gdy twój framwork nie ma zaimplementowanego sposobu drugiego. I przekonałem się, że warto albo zmienić framework na taki, który oferuje sposób drugi. Albo włożyć więcej energii w dostosowanie środowiska pracy aby jednak migracje były na wysokim poziomie abstrakcji.

Ich wyszukane nazwy mogą być jednak odstraszające, klienci mogą nie być zachwyceni, że muszą się czegoś nowego nauczyć. Dlatego podoba mi się określenie “How to demo?”.

Opisz co musiałbym zrobić z systemem, żeby udowodnić Ci, że Twoje wymaganie zostało zaimplementowane?

Na przykład historyjka

Logowanie do systemu:
wchodzę na stronę główną, wpisuję poprawne dane do logowania, po kliknięciu zaloguj widzę spersonalizowaną stronę startową (spersonalizowana, to taka, która mówi ‘witaj, Grzegorz’, o ile zalogował się Grzegorz)

Proste, prawda?

Oczywiście UMLowiec powie, że trzeba w tym Use Casie dodać alternatywne, błędne ‘przebiegi’. Ja jednak powiem, że załatwią to osobne historyjki:

Nieudane logowanie do systemu
wchodzę na stronę główną, wpisuję niepoprawne dane do logowania, system pokazuje formularz logowania z dodatkowymi informacjami:
- błędna para login/hasło
- zapomniałeś hasła? (to jest link)

i dalej,

Przypomnienie hasła
Po kliknięciu “zapomniałeś hasła” klient jest proszony o podanie adresu e-mail na który się zarejestrował, oraz kodu z obrazka. Gdy email jest w bazie, a kod prawidłowy klient dostaje e-mail z wygenerowanym, tymczasowym hasłem

następnie:

Logowanie przy pomocy tymczasowego hasła
…

Dalej sam już dasz sobie radę.

Myślę, że takie układanie historyjek jest szybkie, poza tym klient nie musi się tego uczyć – wystarczy, że przy odrobinie naszych wskazówek nauczy się oddzielać zadania od siebie, aby historyjki były krótkie (a przez to proste).
Oczywiście zdarzają się skomplikowane zadania biznesowe – jednak zaprawieni i wytrenowani w łatwiejszych przypadkach możecie z przyjemnością zagłębić się w ten nowy wymagający i fascynujący (mam nadzieję) temat.