Pogarszający się kod, a refaktoryzacja

Czy mieliście czasem wrażenie, że wraz z upływem czasu, kod w projekcie staje się coraz gorszy? Że się starzeje? Że jest coraz trudniejszy w utrzymaniu? Że pojawia się coraz więcej miejsc gdzie został zaciągnięty dług techniczny i nie został on potem spłacony?
Albo może mieliście w swoich projektach takie miejsca, których nikt nie chciał dotykać? Wyglądały strasznie i każdy się bał, że gdy coś tam zmieni, to coś innego wybuchnie?

Zapewne cześć tego kodu została napisana przez nas, część przez naszych kolegów i koleżanki. A jeszcze inna część nie wiadomo przez kogo, bo Ci ludzie dawno odeszli z firmy albo jest to projekt odziedziczony po innej firmie.

Ja sam napisałem wiele takiego kodu. Kodu, z którego nie jestem dumny. Kodu, o którym wolałbym zapomnieć. Jednak czy ten kod napisałem celowo w ten sposób? Czy siadałem do komputera z myślą 'ale dzisiaj narobię baboli’? Oczywiście, że nie! I pewnie u większości z was było dokładnie tak samo.

Chyba każdy z nas zawsze stara się napisać najlepszy kod jaki potrafi na danym moment (z uwzględnieniem czasu jaki ma na jego napisanie).
Założę się, że tak samo kod pisali programiści, którzy już z nami nie pracują albo programiści w firmach, po których odziedziczyliśmy projekt. Oni też zapewne starali się napisać najlepszy kod jaki potrafią. Zatem jak to się stało, że ten kod tak wygląda?

Dlaczego mamy słaby kod?

Czasem taki kod powstaje w projektach, gdzie nie ma code-review i dana osoba nie wie, że coś da się zrobić lepiej, bo nikt jej jeszcze o tym nie powiedział.
Czasem mamy bardzo krótki deadline na dostarczenie jakiejś funkcjonalności i wtedy z oczywistych względów jakość kodu schodzi na drugi plan.
Czasem kod, który tworzymy ma być zwykłym PoC (Proof of Concept), a potem staje się on rozwiązaniem produkcyjnym.
Najczęściej jednak odpowiedzią jest to, że dziś jesteśmy lepszymi programistami, niż byliśmy rok temu i pisząc dany kod teraz napisalibyśmy go lepiej.

Jak sobie radzić w takich sytuacjach? Czy da się zrobić coś, aby jednak ten kod wyglądał lepiej, bez konieczności przepisywania całego systemu?

Tu z pomocą przychodzi nam zasada skauta.

Zasada Skauta

Wśród skautów panuje taka zasada, aby zawsze zostawiać obozowisko czystsze niż się je zastało.

A jak to się ma do kodu?

Zawsze gdy coś zmieniamy, to powinniśmy starać się zostawić po sobie kod w lepszym stanie, niż go zastaliśmy. Dlatego podczas codziennych prac nad kodem, gdy modyfikujemy jakąś funkcjonalność czy naprawiamy jakiś błąd, powinniśmy zastanowić się, czy ten kod da się napisać lepiej, czy da się tu coś poprawić. Jeśli odpowiedź brzmi 'tak’, to dobrze jest poświęcić te 5% czasu na dodatkowe zmiany, aby kod całej aplikacji z każdym dniem wyglądał odrobinę lepiej. Nie koniecznie trzeba od razu wszystko przepisywać. Nawet niewielkie zmiany w perspektywie jednego dnia, mogą dać ogromną poprawę jakości kodu w perspektywie miesiąca lub roku.

Ale terminy…

Oczywiście bywa tak, że są terminy i ciężko jest znaleźć te dodatkowe 5% czasu. Jednak musimy pamiętać o tym, że te dodatkowe kilka procent czasu teraz, może zaoszczędzić nam wielokrotnie więcej czasu w przyszłości.
System jest jak ogródek – jeśli nie będziemy o niego dbać regularnie, to zarośnie i ciężko będzie go odzyskać. Dlatego należy pielęgnować go na bieżąco.