Dlaczego zmiana jest najważniejszą rzeczą w programowaniu

Źródło: https://unsplash.com/@soymeraki

Długość wpisu: 5 min

Miałem kilka razy tak, że pracowałem ciężko nad jakimś ficzerem, dla którego dogadałem wszystkie wymagania, napisałem elegancki kodzik, pokryłem testami wszystkie edge case’y, a potem klient zobaczył efekty pracy i zasugerował, że w sumie trzeba to zaorać.

Bo nie tego się spodziewał, nie tego oczekiwał. #rip 🕯

Miałem też kilka razy tak, że feedback od użytkowników aplikacji spowodował dokładnie to samo - całkowite przepisanie lub nawet pozbycie się ficzera, któremu poświęciłem dużo pracy.

Możliwe, że też miałeś kilka takich sytuacji.

Może to naprawdę mocno wkurzyć człowieka. Przecież można było to przemyśleć, zaplanować, pogadać z użytkownikami i zrobić to dobrze od początku.

Z czasem zauważyłem jednak, że w wielu przypadkach, użytkownik i klient muszą najpierw samemu pomacać aplikację. Muszą zobaczyć co dla nich tworzymy i samemu się przekonać, że jednak czegoś nie chcą albo że ich pomysł wymaga sporych zmian.

I przecież o to chodzi w pisaniu aplikacji i tworzeniu produktów.

Masz pomysł, piszesz kodzik, dajesz go użytkownikom, oni weryfikują, czy Twoje założenia są poprawne i czy zamierzają tego używać. Dają feedback i gdy coś trzeba poprawić to poprawiasz.

Nawet jeśli użytkownicy na początku mówili jedno, to w zetknięciu z prawdziwą, działającą apką mogą mówić co innego. Nic nie jest idealne od początku. Większość dobrych aplikacji jest raczej daleka od ideału od razu po releasie.

A jednak wiele osób, tak jak ja kiedyś, irytuje się za każdym razem, gdy klient zmienia zdanie na temat tego, co ma robić jego aplikacja. Tak jakby to było zabronione albo wyjątkowe.

Oczekiwanie, że napisana przez Ciebie funkcjonalność nie będzie przechodzić gruntownych poprawek to czysta fantazja.

I my to wiemy od dawna.

Praca programisty jest od samego początku dostosowana do tego, żeby reagować na zmiany.

Zmiana jest najważniejszą rzeczą w procesie pisania aplikacji i zawsze powinniśmy jej oczekiwać.

Wszędzie zmiany

Gdy zacząłem się nad tym zastanawiać to faktycznie, zmiana jest wszędzie. Wszystko pod nią dostosowujemy.

Dobre praktyki tworzenia oprogramowania powstały po to, żeby łatwiej reagować na zmianę.

Zasadę DRY stosujemy po to, żeby nie wprowadzać zmian wymaganych przez klienta w 50 miejscach w kodzie, tylko w jednym.

Zasady SOLID stosujemy po to, żeby ułatwić sobie wprowadzanie zmian. Żeby nie przepisywać połowy systemu, tylko go skonfigurować. Wstrzyknąć inną zależność lub zmienić kod w jednej klasie, która ma fajnie wyizolowaną odpowiedzialność. Żeby móc wymienić moduł obsługujący bazę danych, bez przepisywania wszystkich modułów, w których jest używany. I tak dalej.

Stosujemy zasadę YAGNI, żeby nie pisać kodu, który jest niepotrzebny. Żebyśmy nie musieli go utrzymywać, zmieniać i poprawiać, gdy zaczną przychodzić zmiany.

Piszemy testy, żeby być pewnym, że nasze zmiany niczego nie popsuły.

Refactorujemy, żeby łatwiej było wprowadzić zmianę, albo żeby wprowadzenie zmiany było w ogóle możliwe.

Piszemy czysty kod, żeby Twojemu koledze lub koleżance było łatwo zmieniać kodzik, który napisałeś. Im szybciej zrozumie, co ma zrobić i jak działa to, nad czym pracuje, tym szybciej wprowadzi zmianę.

Używamy monorepo i polyrepo w zależności od tego, w jaki sposób chcemy wprowadzać zmiany. Czy będzie robił to jeden mały team, czy wiele? Często różni się to w zależności od strategii deployowania, jaką przyjmiemy.

Z samym deploymentem jest podobnie.

Po co konfigurujemy CI i CD? Żeby szybko zobaczyć zmiany.

Od czego zależy, ile będziemy mieli serwerów? Od tego, kto będzie patrzył na zmiany.

Klienci mogą mięć swoją wersję, a testerzy swoją. Może testerzy potrzebują mieć nawet możliwość deployowania dowolnej wersji na żądanie. Tylko po to, żeby dobrze przetestować zmiany.

Po co dzielimy apkę na foldery? Żeby ułatwić sobie życie i wyizolować miejsca, w których będziemy wprowadzać zmiany.

Używamy gotowych narzędzi takich jak create-react-app lub piszemy własny konfig webpacka w zależności od tego, czy potrzebujemy wprowadzić jakieś nietypowe zmiany. Musimy podjąć decyzję, czy wszystkie zmiany wprowadzamy samemu, czy zostawiamy domyślny config CRA i tym samym ułatwiamy sobie aktualizację konfiguracji do najnowszych wersji.

Na podobnej zasadzie działają frameworki. Oddają nam gotowy zestaw narzędzi i zostawiają pole do wprowadzenia własnych zmian. Jeśli jednak jest to niewystarczające, to pozbywamy się frameworka i sklejamy rozwiązanie samemu, tylko po to, żeby ułatwić wprowadzenie ważnych dla nas zmian (m.in. dlatego korzystam z Gatsby, a nie z Wordpressa - mogę wprowadzać zmiany łatwiej i szybciej).

Reagowanie na zmiany mocno odbija się na procesie. Nurt agile wspomina dokładnie o tym:

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

~agilemanifesto.org

Używamy Jiry i innych tego typu aplikacji m.in. po to, żeby łatwo było śledzić zmiany.

Robimy dema klientowi, żeby ocenił czy potrzebuje jakiś zmian.

Planujemy, żeby zareagować na zmiany i zaplanować pracę nad nimi.

Robimy retro, żeby ocenić czy dobrze nam idzie, czy może potrzeba wprowadzić jakieś zmiany w procesie.

Używamy komunikatorów i piszemy dokumenty, żeby każdy w zespole widział o zmianach, które mogą ich dotyczyć.

Mógłbym tak ciągnąć jeszcze długo.

Ale co z tego, że zmiana jest najważniejsza?

Jeśli zmiany Cię irytowały, to pamiętaj, że nie ma sensu, żeby to robiły.

Najprawdopodobniej zapomniałeś albo nikt Ci nie powiedział, na czym polega programowanie. A polega na reagowaniu na zmiany.

Zmiana w programowaniu jest czymś naturalnym i oczywistym.

Jest to najważniejsza rzecz, która dyktuje to, jak piszemy kod i jak ustawiamy sobie procesy. Możemy jej tylko oczekiwać.

Po angielsku mówią na to ładnie “embrace the change”.

Dzięki temu zachowasz zimną krew i nie będziesz się denerwować, gdy klient zacznie zmieniać zdanie.

Wymagania zmieniały się zawsze i zawsze zmieniać się będą. Możemy nad tym zapanować tylko wtedy, gdy się z tym pogodzimy.

—

Mam nadzieję, że tym wpisem rozjaśniłem Ci trochę, czym tak naprawdę się zajmujemy i że już więcej nie będziesz się niepotrzebnie irytował. Zmiany są po prostu czymś, do czego każdy programista prędzej czy później musi się przyzwyczaić.

Mi nadal zdarza mi się negatywnie myśleć o zmianie. Mam nadzieję, że ten wpis będzie przypominać o zmianie nie tylko Tobie, ale też mi.

My - ludzie, ogólnie nie lubimy zmian, więc trzeba trochę popracować nad swoją głową, żeby przyzwyczaić się do nowej rzeczywistości.

W następnym wpisie pokażę Ci, że optymalizacja pod kątem zmiany jest potężnym narzędziem, które możesz wykorzystać do podejmowania lepszych decyzji projektowych. Jest też narzędziem, dzięki któremu możesz shackować brak doświadczenia, który czasem dopada każdego z nas.

Podziel się wpisem z innymi jeśli możesz, zależy mi na tym, żeby dotrzeć do jak największej liczby osób i możesz mi w tym bardzo pomóc. :)

Jak zwykle zapraszam do dzielenia się swoimi przemyśleniami w sekcji komentarzy, czy gdziekolwiek Ci wygodnie. 🖖