Pewnie wielokrotnie spotkaliście się z artykułami albo książkami, które mówią Wam, że:

• kod musi być piękny,
• design nie powinien być kruchy,
• powinno się używać wzorców projektowych,
• za żadne skarby nie powinno się używać singletona,
• używamy podejścia Test First bo daje najlepsze efekty,
• używamy sprawdzonych metodyk,
• …

Gdybyśmy o powyższe zapytali starszego programistę, odpowiedź najpewniej byłaby inna: “to zależy”.

“To zależy” jest kluczem do dalszych rozważań. Dziś opowiem Wam o przypadkach, w których powyższe dobre praktyki mają ograniczone możliwości. Więcej, postawię śmiałą tezę – czasami brzydki kod jest lepszym rozwiązaniem.

Wstęp

Pozwólcie, że rozpocznę od przedstawienia miejsca akcji, jakim jest pewien maraton programistyczny. Tak się składa, że z wielką przyjemnością uczestniczę od 4 lat w wewnętrznej edycji Deadline 24 w wersji dla pracowników firmy Future Processing. W ciągu 24 godzin trzyosobowe zespoły mają rozwiązać trzy zadania, których częścią jest rywalizacja z innymi zespołami.

Gdy pierwszy raz przystępowałem do konkursu, byłem żółtodziobem. Miałem kod do komunikacji z serwerem i absolutnie zero pojęcia, co trzeba zrobić. Poszedłem więc na żywioł. Dostałem jedno zadanie i miałem w ciągu 24 godzin zakodzić taki fragment kodu, który zwycięży na serwerze. No dobra – może nie zwycięży, ale zacznie zdobywać punkty dla mojego zespołu.

Co było moim zadaniem: skodzenie bota, który komunikuje się z serwerem, bazując na pewnym zestawie reguł dostarczonych przez organizatora.

Co przeszkadzało mi w wykonaniu zadania:

• presja czasu,
• presja zespołu,
• presja innych zespołów, z którymi rywalizowałem,
• nieznajomość konkursu na tyle, by wiedzieć jak zacząć,
• nieznajomość frameworka do komunikacji,
• oraz najważniejsza przeszkoda -> ja sam 🙂

Po 24 godzinach powstał jeden z najbrzydszych fragmentów kodu, jaki kiedykolwiek popełniłem, który zarazem do dziś budzi moją największą dumę i satysfakcję. Nauczyłem się dzięki temu maratonowi kilku ważnych rzeczy, którymi się z Wami podzielę. Oto -moim zdaniem – ważne rzeczy, których warto się nauczyć na bazie moich doświadczeń:

1. Liczy się misja – cel.

Kod jest tylko narzędziem. Nie przywiązuj się do niego emocjonalnie. Ważne jest określenie, co ma robić. Określenie, jaki jest jego job to be done.

W moim wypadku musiałem napisać bota, który będzie rywalizował z innymi botami. Nieistotne było w jaki sposób, w jakim języku. Istotne było tylko to, by robił to, czego od niego wymagałam. Nic więcej, nic mniej.

Celem w tym wypadku było zdobywanie punktów – robiłem tylko te rzeczy, które miały za zadanie dostarczyć więcej punktów, niż inne rywalizujące ze mną zespoły.

Gdybym próbował trzymać się wszystkich dobrych praktyk, pracowałbym zwyczajnie za wolno. W tym momencie nie przyszła utrzymywalność kodu miała znaczenie, a aktualne tu i teraz.

Przede wszystkim ma działać. Kod to nie forma sztuki, którą podziwiamy. Nikt nie doceni kodu, jeśli nie będzie działać. Pierwszy krok, który musiałem zrobić, to doprowadzić go do stanu, że będzie działał. Dopiero potem martwiłem się rzeczami mniej istotnymi.

2. Poznaj kontekst tworzenia aplikacji

Inaczej będziemy podchodzili do pisania kodu w zależności od tego, w jakiej sytuacji się znajdziemy. W wypadku tego maratonu kontekstem był ograniczony czas; kod który co najwyżej musiałem rozumieć ja i moi koledzy z zespołu.

Po zakończeniu konkursu, czyli po 24 godzinach kod przestaje być potrzebny i możemy mu pomachać na “do widzenia”.

Kontekst jest bardzo istotny, bo on nadaje niektórym działaniom priorytet. Inny kod będziecie pisać gdy:

• jesteście w wieloosobowym zespole,
• piszecie kod pod kątem rekrutacji,
• piszecie kod na zaliczenie przedmiotu.

W każdym z przypadków liczy się coś innego:

• wieloosobowy zespół -> kod musi być czytelny i zrozumiały dla innych członków. Musi wpasować się w standardy,
• program rekrutacyjny -> musi udowodnić, że znacie technologie, że potraficie w skończonym czasie napisać kod zgodny z jakimiś standardami, że znacie dobre praktyki i wzorce,
• program zaliczeniowy -> ma udowodnić, że znacie i potraficie użyć coś, co było tematem zadania.

W moim wypadku świadomie wybrałem by stworzyć “brzydki” kod. Bo tego wymagał kontekst.

3. Sięgnij po te narzędzia, po które byś sięgnął w czasie kryzysu

Wielokrotnie słyszałem: rób zawsze tak, używaj zawsze tego narzędzia, co już samo w sobie jest powodem do zastanowienia. Każde narzędzie ma swój określony zakres użycia, np. raczej nie użyjecie młotka do wkręcania śrub.

Dodatkowo specyfika konkursu pokazała mi jedno – z których narzędzi korzystam, gdy wpływa na mnie tak dużo czynników stresogennych.

Popatrzcie – jestem kompetentny w korzystaniu z dużej ilości narzędzi, a jednak w momencie kryzysu sięgnąłem tylko po kilka z nich. Wykorzystywałem:

• C#,
• Visual Studio,
• R# -> do uruchamiania testów,
• Nunita,
• Gita.

Dlaczego tak się stało? Dlatego, że znam je na tyle dobrze, aby wiedzieć:

• że mnie nie zawiodą,
• że sprawdzą się w tej sytuacji,
• że uratują mi życie wielokrotnie w ciągu tych 24 godzin.

Konkurs ma taką specyfikę, że czasami wrzucałem drobną zmianę i czekałem na jej efekt do 20 minut, a czasami nawet dłużej.

Powyższy zestaw narzędzi pozwalał mi:

• na ciągłą pracę w środowisku, które znam,
• na poruszanie się pomiędzy różnymi wersjami kodu,
• nie myśleć o narzędziach, tylko działać. Pamięć mięśniowa sama uruchamiała builda, testy, deploy,
• na weryfikowanie, czy moja hipoteza będzie działać. Bez testów musiałbym czekać 20 minut na wystąpienie czegoś, co mogłem napisać i przetestować, a dopiero potem wrzucić.

Podsumowując:

Cel, kontekst definiują sposób wyboru narzędzi, rozwiązania i podejścia.

• Nie ma narzędzi, które sprawdzają się zawsze. Użycie słowa “zawsze” to klucz do problemów. Za każdą dobrą praktyką jest ukryta jakaś intencja.
• Najważniejszą rzeczą, o której powinniście pamiętać, jest to, że dostarczacie kod, który działa. Nikt nie będzie rozpływał się nad kodem, który się nie kompiluje lub nie robi tego, co ma. Nawet gdyby to był najlepszy kod, jaki w życiu napisaliście.
• Jeśli macie mało czasu, to nikt rozsądny nie będzie Was winił za kod, w którym brak wyszukanych wzorców, czy dobrych praktyk.
• Kontekst tworzenia jest tym, co wymusi na Was odpowiednie podejście.
• Jeśli narzędzie jest dobrze Wam znane i odpowiednie do kontekstu, to sięgnijcie po nie w czasie kryzysu. Narzędzie jest tylko i wyłącznie po to, by Wam pomóc i zdjąć z Was ciężar myślenia o tym, jak użyć narzędzi, po to byście mogli się zająć rozwiązywaniem problemu.

Brzydki kod to nie taki, który źle wygląda, ale taki, który nie robi tego, co powinien. Zrozumienie kontekstu tworzenia jest bardzo ważne. Mniej ważna jest uroda kodu, niż okoliczności jego użycia. Są pewne przypadki – takie jak mój – że nawet najbrzydszy kod może umożliwić Wam osiągnięcie celu.