Użytkownik na początku i końcu oprogramowania

W dziedzinie tworzenie oprogramowania osiągnęliśmy bardzo wysoki poziom. Nowoczesne języki programistyczne całkowicie zdominowały rynek tworzenia nowych produktów, a problemy takie jak zarządzanie pamięcią w programach, albo implementacja prymitywnych algorytmów ustąpiła miejsca myśleniu nad realizacją celu biznesowego.

Oczywiście systemy operacyjne oraz środowiska, ze względu na swoją naturę, wciąż korzystają z prymitywnych technologii. Pojawia się pytanie — czy każdy, kto chce z tych systemów i środowisk skorzystać (czyli każdy programista) musi dobrze rozumieć budujące je technologie? A może jest wprost przeciwnie? Może powinniśmy się skupić na przeniesieniu idei do świata komputerów w jak najbardziej klarowny sposób. Dlaczego mamy znać mechanizmy działania środowiska skoro nie jest to nasza odpowiedzialność i część naszej pracy?

Dylemat sprowadza się do prostego pytania: czym jest programowanie? Czy jest listą instrukcji, wyrażeniem logicznych idei, czy po prostu tworzeniem produktu dla innych? Czy programowanie ma jakiekolwiek znaczenie bez odniesienia się do świata zewnętrznego (czyt. użytkownika)?

Trzy rodzaje programistów:

1. Poetą. Program ma być zwięzły i pięknie napisany.
2. Hakerem. Szuka granic, kruczków w wykorzystywanych API/SDK. Programując wykorzystuje nieoczywiste sposoby przez co program robi to co chcesz i jak chcesz.
3. Twórcą. Tworzy oprogramowanie by to służyło ludziom.

Programowanie jako poezja

Pierwszy sposób traktuje programowanie w zasadzie jako zaimplementowanie matematyki. Rodzaj poezji, gdzie idee w najczystszej formie przenosimy na środowisko, w którym ma być uruchomione. Fakt, że ów program będzie uruchomiony na jakimś środowisku, który może wpływać na jego działanie to tak naprawdę nieistotny szczegół implementacyjny. Najważniejsze jest przekazanie idei w odpowiedniej, wyrafinowanej formie. Kod źródłowy musi być czytelny, zgodny ze standardami architektonicznymi i "gęsty" - dokładnie odzwierciedlać idee i zamierzenia programisty, zwięźle oddawać to, co zostało ujęte w specyfikacji.

Programiści myślący o programowaniu w ten sposób preferują języki wysokiego poziomu — dzięki nim łatwiej można określić swój zamiar.

To jak napisany program wchodzi w interakcje z ludźmi, jest sprawą drugorzędną. Aspekty wizualne są nieistotne, problemy z działaniem, jeśli nie wynikają z błędnego przedstawienia idei, nie stanowią wiarygodnego argumentu przeciwko słuszności implementacji.

Jeśli używałeś React do tworzenia stron internetowych, powinieneś wiedzieć, że model niezmienności i wyrażeniu widoku jako czystej funkcji od danych do DOM pochodzi od programowania funkcyjnego. Właściwie większość nowoczesnych idei w programowaniu została stworzona przez ludzi myślących o programowaniu jako poezji.

Programowanie jako hakowanie

Żaden program nie może istnieć bez środowiska, na którym będzie uruchamiany. Jakość programu nie wynika z dobrze napisanego kodu, lecz z tego, że program wykorzystuje sprzęt w sposób efektywny. Kod źródłowy powinien być na tyle czysty i czytelny na ile jest to potrzebne. Najważniejsze jest wykorzystanie środowiska w optymalny sposób. Wydajność jest kluczowym czynnikiem w określaniu czy program został dobrze napisany. Program jest poprawny, jeśli działa tak jak oczekujemy by działał — elegancja wykonania jest ważniejsza niż poprawność. Jeśli teoretyczny problem nie może wystąpić przez specyfikę środowiska, nie jest to prawdziwy błąd.

Program powinien działać szybko i sprawnie. Warto jednak pozwolić, by ograniczenia sprzętowe kierowały doświadczeniami użytkownika. Jeśli dysponuje on słabym sprzętem, to odpowiednio program będzie działał słabiej — jest to akceptowalne zachowanie.

Ciekawy jest holistyczny charakter tego podejścia. Dla programistów funkcjonujących w tym trybie myślenia, wszystko co może nieoczekiwanie zmienić działanie programu, jest niebezpieczne. Z tego powodu programiści — hakerzy tak bardzo nienawidzą mechanizmów jak "GarbageCollector" lub języków typu "Java Script". Preferują za to języki niskiego poziomu, ponieważ dają im ogrom możliwości w decydowaniu o zarządzaniu pamięcią i działaniem programu.

Programowanie jako tworzenie użytecznych rzeczy

Programiści tworzą oprogramowanie, ponieważ jest ono potrzebne innym ludziom. Programowanie samo w sobie jest środkiem do celu.

Kod źródłowy dla programistów z tego obozu musi być przede wszystkim czytelny i jasny, aby zapewnić proste i szybkie zmiany z następnych iteracjach. Najważniejsze jest dodanie funkcji oraz to w jaki sposób użytkownik korzysta z programu. Szybkość jest ważna, ale nie ważniejsza niż funkcja, jaką program ma spełniać. Wszelkie błędy są o tyle istotne, o ile wpływają na użytkownika. Program powinien działać tak, jak oczekuje tego użytkownik. Kwestia wizualna jest więc bardzo ważna.

Twórcy preferują języki wysokiego poziomu i środowiska z szerokim dostępem do bibliotek, by dostarczać funkcjonalności tak szybko, jak jest to możliwe.

Istnieją napięcia między Poetami i Hakerami a Twórcami. Głównym zarzutem, jest brak wiedzy dotyczący (między innymi) działania sprzętu czy nieznajomość idei z dziedziny programowania funkcyjnego. Z drugiej strony Twórcy są najbardziej “płodnym” rodzajem deweloperów — programy wytworzone przez tych programistów są zawsze użyteczne, posiadają świetny UI i UX, a błędy nie rażą użytkowników.

A jak to wygląda w praktyce?

Kiedy myślę o tworzeniu oprogramowania, zawsze dochodzę do wniosku, że dobrze stworzyć zespół składający się z programistów reprezentujących wszystkie typy myślenia. Prymem jednak jest dostarczenie wartości biznesowej i komunikacja z użytkownikiem. Wysoka jakość na tej przestrzeni tworzy użyteczny program, pozwala dobrze rozwinąć współpracę z zespołem UX/UI oraz tym odpowiedzialnym za dostarczanie wymagań biznesowych. Wartościową praktyką jest zagwarantowanie przestrzeni na tematy “poetyckie” i “hakerskie”. Doskonała czytelność “poetyckiego” kodu oraz zastosowanie nowatorskiego podejścia do architektury może wesprzeć zespół w szybszym dostarczeniu następnych funkcjonalności. Z kolei “hakerskie” optymalizacje zagwarantują właściwe działanie programu na sprzęcie użytkownika.

Z hakerami i poetami trzeba uważać. Nawiązuje tutaj do popularnego mema - Midwit, przedstawiający przez rozkład normalny, że czasem sposób postępowania, który wskazuje na bardzo prymitywny, jest tym właściwym i preferowanym przez najlepszych w dziedzinie. Początkujący i eksperci bardzo często podzielają opinie i zamiłowanie do prostoty w sposób, który rozwściecza “średniaków”.

Doświadczamy tego, kiedy w mediach widzimy, jak zwykły pracownik fizyczny zarabia krocie na kryptowalutach, jednocześnie widząc, że Elon Musk (osoba o ogromnym IQ i wiedzy) podziela zamiłowanie do Dogecoina. Podobnie jest w świecie tworzenia oprogramowania, kiedy doświadczeni programiści w intelektualnych debatach kwitują wszystko słowami “to zależy” i poklepują się po plecach za mądre i dojrzałe słowa. Jeszcze kilka lat wcześniej można było ich spotkać ochoczo cytujących “Wujka Boba”, a na każde odchylenie od “Clean Code” reagowali furią. Teraz programiści ze środka krzywej toczą wojny, o tym, który framework jest lepszy, podczas gdy Pieter Levels zarabia ponad $1M rocznie za pomocą jednego, prostego pliku PHP.

Książka "Getting Real" dostarcza sposób budowania oprogramowania. Żeby naprawić problemy związane z wydajnością i dostarczyć “jakość hakerską” muszą w danym produkcie powstać takie problemy. Jeśli mówimy o brzydko napisanym kodzie, musi on mieć wpływ na szybkość dostarczania produktu, a rozwiązanie musi być uzasadnione. Dostarczenie jakości w postaci optymalizacji hakerskich czy zagwarantowanie jakości kodu musi na końcu zapewnić benefit użytkownikowi, w przeciwnym razie nie ma to sensu.

Race to Running Software | Getting Real

Getting RealBasecamp

Scale Later | Getting Real

Getting RealBasecamp