Nie ma czegoś takiego jak dobry kod
Długość wpisu: 3 min
Napisałem jakiś czas temu na Twitterze, że nie ma czegoś takiego jak “dobry kod”. Nauczyłem się, że mogę co najwyżej osiągnąć stan “dobrego kodu w obecnej sytuacji”.
Gdy zaczynałem pracę w IT, to myślałem, że gdy kod będzie robił, co ma robić i nie będzie zawierał bugów, to wystarczy, żeby nazwać go dobrym kodem (śmieszne, wiem).
Teraz wiem, że w IT jedyną pewną i jednocześnie najważniejszą rzeczą jest zmiana. Dlatego “dobry kod w obecnej sytuacji” szybko przestaje być “dobry”, bo “obecna sytuacja” się zmienia. Zmienia się kontekst: dochodzą nowe wymagania, nowe osoby do zespołu (o różnym doświadczeniu), pojawiają się deadline’y, bugi, awarie. Szybkość reagowania na te zmiany jest istotna i kod musi cały czas się dostosowywać.
Długo zastanawiałem się nad dobrą metryką do mierzenia dobrego kodu i ciągle wracam do tego obrazka:
Podoba mi się, bo uwzględnia kwestię tego, jak dobrze pracuje się z Twoim kodem osobom w zespole oraz tym, którzy dopiero do niego dołączają.
Często powtarzam, że czasem lepiej jest napisać bardziej “brzydki” i mniej fancy kod, który jednak zrozumie więcej osób, również tych mniej doświadczonych. Dzięki temu będą mogli szybciej wprowadzać zmiany, gdy klient lub użytkownicy sobie tego zażyczą.
Taki kod będzie może mniej DRY, mniej owzorcowany, będzie stosował proste rozwiązania, które nie zaspokajają każdego edge case’a, ale jednocześnie zminimalizuje ilość WTFów, bo będzie łatwiejszy w zrozumieniu.
Jest takie fajne zdanie, że “kod to narzędzie komunikacji, komputer zrozumie każdy kod, programista już nie”. Dlatego zawsze podczas pisania kodu pytam samego siebie, czy osoba, która będzie po mnie czytać ten kod, zrozumie, co miałem na myśli.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
Na tym obrazku wyżej brakuje mi jeszcze jednego pokoju, który reprezentowałby liczbę WTFów klienta i użytkowników, którzy zażyczyli sobie zmian w aplikacji. Im bardziej problematyczne dla zespołu będzie wprowadzenie tych zmian, tym więcej WTFów poleci ze strony klienta.
To trochę utrudnia ocenę, bo trzeba czasem priorytetyzować, czy ważniejszy jest developer experience, czy dostarczony kod, ale pokazuje pełniejszy obraz sytuacji oraz zmienne, na które trzeba brać pod uwagę.
Te wszystkie przemyślenia doprowadziły mnie do tego, żeby zacząć kwestionować, czym jest dobry kod i prowadzić mój własny spis zmiennych, które muszę wziąć pod uwagę i na które muszę uważać.
Poniżej jedna z takich kolekcji, na podstawie bardzo fajnej serii Three Flaws of Software Design:
- You don’t need that yet.
- Do you need that yet?
- Which requirement is driving this particular code?
- Do you need it?
- When it is going to be needed?
- The first thing you don’t need are…
- Your input does not include…
- What is the requirement? Developers assume requirements.
- Phrase “We will never need to …” is wrong.
- Code should be designed based on what you know now.
- Write useful core first.
Używam tego do kalibracji mojego bullshit detectora i cały czas widzę pozytywny wpływ takiego kwestionowania swoich założeń.
Takie pytania i zasady pomagają mi pisać “wystarczająco dobry kod w obecnej sytuacji” Dzięki nim jestem w stanie cały czas upraszczać kod aplikacji, dodawać tylko to, co jest potrzebne i wyrzucać to, czego nie potrzebujemy. Przy okazji udało mi się też dzięki temu wkurzyć swego czasu kilku seniorów, którzy chcieli owzorcować i pokomplikować kod, a to może być dla niektórych nawet większą przyjemnością niż czysty kodzik.