archiwum wpisów z maja 2004

Pair Programming - good intention gone bad

Pair Programming — jedna z podstawowych i jednocześnie najbardziej kontrowersyjnych praktyk stosowanych w XP. Mam wrażenie, że w przeważającej większości znanych mi przypadków to po prostu nie zadziała. Nie twierdzę, że to pomysł do niczego — Pair Programming może działać i może być wydajną techniką (może nie od razu 1+1=3, ale przynajmniej 1+1> 2). Jednak równocześnie istnieje mnóstwo powodów, dla których może się okazać absolutną klęską.

standard kodowania

O standardach pisania kodu programu powiedziano już bardzo wiele. Jest to jeden z najbardziej wyrazistych aspektów ludzkiego wymiaru programowania — styl kodu nie ma przecież żadnego znaczenia dla kompilatora i jego "jakość" to wyłącznie subiektywne odczucia programisty. A jednak sprawa od zawsze budzi wiele emocji — kod może być "elegancki" i "ładny" albo "brzydki" i wtedy taktowany jako produkt niskiej jakości (niezależnie od jakości skompilowanego programu). Nic dziwnego zatem, że powstają nawet oficjalne wytyczne na temat stylu kodowania, np. Suna dla Javy lub Microsoftu dla .NET-u oraz dziesiątki innych opracowań (prywatnych lub korporacyjnych), które zazwyczaj bazują na powyższych lub innych sławnych źródłach typu "C++ Coding Standard" Todda Hoffa.

niemodna optymalizacja

Tempo postępu technologicznego w informatyce jest (przynajmniej dla mnie) jednym z największych zaskoczeń ostatnich dziesięcioleci. Moc obliczeniowa komputerów wzrasta tak szybko, że nieraz jest to "poniżej ludzkiej godności", jak zwykł mawiać mój kolega. Znaczenie określenia "dobry sprzęt" zmienia się błyskawicznie i wyobrażam sobie, że ludzie chcący za tym nadążyć nie zajmują się niczym więcej. Niestety wraz ze sprzętem dewaluuje się pojęcie "dobrego" oprogramowania. Przyzwyczajeni do szybkich i tanich komputerów przestajemy zwracać uwagę na takie szczegóły jak optymalizacja kodu, wykorzystania pamięci czy szybkości obliczeń. Problemy z wydajnością oprogramowania nagminnie rozwiązuje się bezczelnie prostym stwierdzeniem — "poda się w specyfikacji większą ilość wymaganej pamięci, to kosztuje grosze". I niestety to jest prawda, co tylko umacnia trend ignorowania pojęcia optymalizacji. Jednak paradoksalnie rozczarowanie przychodzi w momencie kiedy zechce się napisać coś "naprawdę zgodnego z trendami", ponieważ "trendy" to dzisiaj urządzenia mobilne.

XP name considered harmful

Bez względu na to jak obiecujące byłyby koncepcje związane z Extreme Programming, nigdy nie będę w stanie wprowadzić takiego pojęcia oficjalnie w poczet technik stosowanych w firmie. Do powodów, które sobie wyobrażam, należą przede wszystkim takie:

Blog Reader Add-In for Visual Studio .NET

Blog Reader Add-In for Visual Studio .NET — czytnik RSS zintegrowany z Visual Studio, czyli co zrobić, żeby lepiej udawać, że pracujesz ;-).

IntelliSense

Najważniejsza, obok kolorowania składni, funkcjonalność edytora kodu — przewidywanie co chcesz napisać i podpowiadanie gotowych rozwiązań. Czy to się nazywa IntelliSense, code completion, code hinting czy jeszcze jakoś inaczej — bez znaczenia. Ważne, żeby było i żeby działało sprawnie, bo od tego zależy jakość, szybkość powstania, a nieraz w ogóle zaistnienie kodu.

Agile Modeling

Kiedy pierwszy raz zetknąłem się z pojęciem Agile Modeling spotkałem różne mniej lub bardziej rozbudowane wprowadzenia czy też próby skrótowego przedstawienia tego pojęcia (choć niejako z definicji skrótowo przedstawić się go nie da), w tym również poniższą listę:

programista, a może projektant?

Teoria książkowa aka sformalizowany świat idealny przedstawia taki łańcuch rozbieżnych kompetencji — klient, analityk, projektant, programista, tester. W łańcuchu tym wymagania i uwagi klienta co do funkcjonalności systemu są pieczołowicie zbierane przez analityka i przekazywane projektantowi, który tworzy szczegółowy projekt tego co ma być wykonane. Następnie projekt ten trafia do programisty w celu jego urzeczywistnienia i na końcu do testera dla konfrontacji efektu z założeniami. Taki schemat zakłada separację ról, czyli jest praktycznie wzorowany na kaskadowym modelu cyklu życia projektu informatycznego. I jest równie absurdalny jak sam model kaskadowy.

engineering?

Pytanie o zasadność słowa engineering w wyrażeniu software engineering nie jest bynajmniej nowe ani dziwne. Jest wręcz uzasadnione, a uzasadnione pytania tego kalibru zawsze są kłopotliwe. Jeśli nie niebezpieczne...