Software Craftsmanship


Czy możliwe jest połączenie programowania, postrzeganego jako profesjonalizm i techniczna perfekcja, z oczekiwaniami biznesu, który chce wytwarzać oprogramowanie szybko i tanio? Idea Software Craftsmanship pokazuje, że to całkiem realne. Konieczna jest tylko zmiana sposobu myślenia o programowaniu.


Projekt programistyczny nie może się udać bez współpracy z dobrymi programistami, którzy nie tylko potrafią tworzyć dobrej jakości oprogramowanie, ale również są w stanie pomóc biznesowi w osiągnięciu tego, co ten chce osiągnąć, oferując mu odpowiednie opcje, informacje zwrotne i konstruktywną krytykę.

S. Mancuso,
„Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja”
wyd. Helion


Marzec 2009 roku to kluczowy czas dla idei Software Craftsmanship. Zaledwie trzy miesiące wcześniej w przysypanym śniegiem Libertyville w stanie Illinois toczy się burzliwa dyskusja nad głównymi założeniami Software Craftsmanship. Wydawało się, że spotkanie nie zakończyło się niczym konkretnym, a jednak trzy miesiące później świat ujrzał:


Manifest Software Craftsmanship.


W rzeczywistości było to spisanie zasad, którymi wielu programistów kierowało się w praktyce już wiele lat wcześniej. Nie przez przypadek nawiązano tutaj do Manifestu Agile z 2001 roku. Nowy manifest rozwijał kilka zasad właśnie z tamtego dokumentu zwinnego programowania. Sygnatariusze manifestu Software Craftsmanship, nazywający siebie Rzemieślnikami Oprogramowania, położyli nacisk na następujące wartości:


  • Nie tylko działające, ale również dobrze napisane oprogramowanie.
  • Nie tylko reagowanie na zmiany, ale również ciągłe dodawanie wartości.
  • Nie tylko osoby i interakcje, ale również społeczność profesjonalistów.
  • Nie tylko współpraca z klientem, ale również produktywne partnerstwo.

Według Rzemieślników Oprogramowania nie chodzi o to, aby tworzyć kod, ale o to, aby tworzyć dobry produkt. Z tego wynika potrzeba większego zaangażowania programisty w wytwarzanie oprogramowania na wielu poziomach, zwiększenie jego wymagań i oczekiwań, ustalenie poziomu, poniżej którego nie wolno zejść. Dobry rzemieślnik nie robi przecież bubli.


Takie rzemieślnicze podejście do programowania rodziło się równolegle do idei Agile i wyrosło z tego samego przekonania, że konieczna jest zmiana sposobu myślenia o pracy Software Developera. Tworzenie oprogramowania, które działa, to już o wiele za mało. Dla Rzemieślników Oprogramowania ważna jest także jakość oprogramowania, to, czy wykonuje się testy w procesie produkcji i czy kod jest w ogóle zrozumiały dla innych programistów. Tak zrodziła się społeczność Software Developerów, którzy nie tylko reagowali na zmiany, korzystając z koncepcji Agile, ale przede wszystkim stawiali na dodawanie wartości do realizowanego projektu.


Programista-rzemieślnik


Software Craftsmanship wyrosło tak naprawdę na idei średniowiecznego i renesansowego postrzegania pracy i profesji. W tamtych czasach prawdziwi specjaliści byli rzemieślnikami, mistrzami należącymi do tego lub innego cechu. Bez względu na to, czy wyrabiali beczki, czy inne produkty, dokładali przede wszystkim starań, aby ich towary spełniały najlepsze standardy. Dziś nurt Software Craftsmanship czerpie właśnie z tamtej tradycji rzemiosła, z tradycji profesji, które wyznaczały ściśle określone kodeksy i wzorce wytwórcze (dziś powiedzielibyśmy: wzorce projektowe). Można napisać, że manifest Software Craftsmanship jest właśnie takim syntetycznym kodeksem programisty-rzemieślnika, ale również szerzej – specjalistów IT, którzy na co dzień realizują różne zadania, jak na przykład Project Managerowie, specjaliści QA, architekci oprogramowania itd. Ten nurt kładzie duży nacisk na potrzebę wysokiej dbałości w wytwarzaniu oprogramowania, ale także wnosi nową wartość do pracy Software Developerów, do pracy całych zespołów projektowych, a w końcu również przenosi na nowy poziom współpracę z klientem.


Ruch ten wprowadza też słownictwo zapożyczone z cechowego. Pojawiają się określenia takie jak uczeń, czy w przypadku pracującego zawodowo programisty: czeladnik, mistrz (mentor). Uczeń to osoba odbywająca przyuczenie w zakładzie mistrza. Cechy określały długość takiego stażu na 3-7 lat. Po tym czasie można było awansować na czeladnika. Tytuł ten był potwierdzeniem umiejętności, jednak dopiero stopień mistrzowski umożliwiał prowadzenie własnego zakładu. Jak widać w tym systemie, aby zostać mistrzem trzeba było kilkunastu lat pracy. Podobnie Rzemieślnicy Oprogramowania twierdzą, że zgłębianie tajników informatyki to nie jest kwestia 2-3 lat, a raczej 10 lat świadomej praktyki. Aby zapewnić podobną strukturę do cechowej potrzebna jest współczesnym rzemieślnikom dobrze działająca społeczność. To ona umożliwia przekazywanie wiedzy z mistrza na ucznia.


Innym zapożyczonym terminem jest kata. To japońskie słowo oznacza “forma” i jest określeniem ściśle sformalizowanych ćwiczeń stosowanych w tradycyjnych sztukach walki. Stosuje się je, aby doskonalić kontrolę nad swoim ciałem, by wyrabiać prawidłowe wg. tych sztuk walki ruchy, postawy. Tak samo Rzemieślnicy Oprogramowania uważają, że nie wystarczy pracować by się doskonalić jako programista. Trzeba spędzać czas na ćwiczeniach, które mają na celu przede wszystkim rozwój swoich zdolności. Programistyczne kata nie jest jednak tak sformalizowane. Może oznaczać branie udziału w projektach open source, robienie projektów na własny użytek poza pracą, eksperymentowanie z nowym językiem programowania, prowadzenie bloga. Ważna jest świadomość celu danej aktywności.


Praktyka


W dniu pisania artykułu manifest podpisało 23 376 software developerów w całego świata. Liczba ta rośnie niemal liniowo od 2009 roku. Jednak wielu najgorętszych zwolenników idei przypomina, że nie wystarczy sygnować manifestu by stać się prawdziwym Rzemieślnikiem Oprogramowania. Teoria często nie idzie w parze z praktyką. Można taką sytuację przedstawić na wykresie, gdzie na jednej osi pionowej mamy przyjęcie teorii Software Craftsmanship, a na poziomej wprowadzenie ich w praktykę.

Pierwszy przypadek to gdy ktoś odrzuca (najczęściej nieświadomie) to podejście, a także nie produkuje kodu spełniającego kryteria nurtu. Nazwaliśmy tego programistę “jako tako i fajrant”, co chyba pokazuje potencjalne efekty jego pracy. Kolejny programista to “praktyk”. Odrzuca on etos Software Craftsmanship, gdyż uznaje go za zbędny dodatek. W praktyce będzie jednak dbał o swój kod i rozwój z czysto pragmatycznych pobudek - po prostu dzięki temu jest mniej stresu. Osobę, która w pełni zgadza się z teorią ruchu, ale nie radzi sobie z jej zastosowaniem nazwaliśmy “teoretykiem”. Z wymienionych tutaj typów ten jest najbardziej niebezpieczny. Niestety etos i piękne słowa nie zastąpią kodu i czynów. Być może nawet taka osoba zostanie na początku uznana za mistrza - jednak efekt jej prac będzie daleki od doskonałego. Na koniec zostawiliśmy “Prawdziwego Rzemieślnika”, czyli osobę, u której teoria podparta jest praktyką. Ciężko jest powiedzieć ile osób z tych, które podpisało manifest poszło tą drogą.


Post Software Craftsmanship


Idea straciła nieco na blasku w tym sensie, że szczyt jej popularności przypadł na 2010-2011 rok, gdy był to częsty temat na wpływowych blogach programistycznych. Mimo to co roku odbywają się konferencje na ten temat. Np. już 27 października odbędzie się kolejna edycja Software Craftsmanship North America. Z pewnością manifest odcisnął swoje piętno na IT, przyczynił się do stworzenia etosu programisty. Dziś koncept programowania jako rzemiosła wydaje się być zintegrowanym w głównym nurcie. W momencie, w którym coraz więcej osób decyduje się na zostanie programistą z czysto materialnych pobudek warto wrócić do oryginalnego manifestu. Przypomnieć sobie jego założenia, zrozumieć czym może być nasza profesja.


Sandro Mancuso, autor cytowanej już tutaj książki „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja”, napisał, że Rzemieślnik Oprogramowania to ktoś, kto przeszedł długą drogę do mistrzostwa. To developer, który nie tylko zmienił sposób myślenia o programowaniu, ale włożył wiele pracy w rozwój własnych umiejętności i wpłynął na postrzeganie programowania przez innych. Trudno nie pokusić się tutaj o słowo „mentor”, nawet jeśli może się to wydawać przesadą. Warto jednak pamiętać, że prawdziwe rzemiosło w programowaniu, nawet na najwyższym poziomie, nie gwarantuje sukcesu projektu. Natomiast jego brak to główna przyczyna porażki.