Najważniejsze pytanie, jakie powinien zadawać sobie programista

Niezależnie od tego, czy piszesz kod, zarządzasz pracą innych inżynierów, czy opracowujesz schematy architektury, jest jedno pytanie, które powinno znajdować się w absolutnej czołówce Twojego myślenia. Powinno kształtować każdą decyzję techniczną, którą podejmiesz. Dla inżyniera jest to rozważanie numer jeden.

Czy wybrałem dobry wzorzec?

Czy to dobry wzorzec? A co, jeśli ktoś inny zrobił to już trzydzieści razy? Uniwersalność kodu jest podstawową zasadą, która pomaga chronić jakość oprogramowania.

Spójrzmy na przykład. Rozważmy następującą klasę.

public class MyThing {
    public void doAThing() {
        String name = "Chris"
        
        service1.doSomething(name)
        String response = service2.doSomething(name)
        service3.doSomething(response)
    }
}

Jesteś zmęczony, a musisz dodać kolejne imię, więc co robisz? Zdajesz się na stare dobre CTRL+ A, CTRL+ C, CTRL+ V.

public class MyThing {
    public void doAThing() {
        String name = "Chris"

        service1.doSomething(name)
        String response = service2.doSomething(name)
        service3.doSomething(response)

        String name2 = "James"

        service1.doSomething(name2)
        String response2 = service2.doSomething(name2)
        service3.doSomething(response2)
    }
}

Ale co się stanie, gdy upowszechnimy ten kod? Czy wybierasz dobry wzorzec? Przenieśmy się na chwile do przyszłości.

public class MyThing {
    public void doAThing() {
        String name = "Chris"

        service1.doSomething(name)
        String response = service2.doSomething(name)
        service3.doSomething(response)

        String name2 = "James"

        service1.doSomething(name2)
        String response2 = service2.doSomething(name2)
        service3.doSomething(response2)

        String name3 = "Alice"

        service1.doSomething(name3)
        String response3 = service2.doSomething(name3)
        service3.doSomething(response3)
        
        // And then there's Mark, Mary, Melinda and Quentin
    }
}

Bum! Patrz, jestesmy w przyszłości, i co my tu mamy? Bałagan. 

Nie możemy zakładać, że kiedyś "ktoś przyjdzie i to naprawi". Nikt tego nie zrobi. Wręcz odwrotnie, musisz założyć, że presja biznesowa jest stale na wysokim poziomie. Nikt nie zrobi czegoś, co nie jest jego odpowiedzialnością. To Ty musisz być zmianą, którą chcesz zobaczyć w kodzie.

A co, jeśli pomyślałeś zawczasu o wzorcu i zrobiłeś wszystko jak należy?

public class MyThing {
    public void doAThing() {
        List<String> names = List.of("Chris", "James")

        for(String name: names) {
            service1.doSomething(name)
            String response = service2.doSomething(name)
            service3.doSomething(response)
        }
    }
}

Nie jest to idealne rozwiązanie, nie jest nieomylne, ale to krok w dobrym kierunku. Ma ręce i nogi. Może będzie wymagać lekkiego dopracowania w przyszłości, ale na razie upewniasz się, że nie będzie żadnego problemu z ustawionymi frameworkami.

W żyłach zdrowego kodu płyną wzorce

Kiedy ustalasz jasne wzorce wykonywania zadań, inżynierowie nie muszą się tak bardzo martwić.

Tworzysz bibliotekę wiedzy, która jest przekazywana przez kod. Jeśli Twoja firma chce się nauczyć, jak sprawić, aby inżynieria poruszała się szybciej, przedstaw im to.

Jeśli próbujesz poradzić sobie z trudami w kodzie, zacznij myśleć o wzorcach.

Bądź odważny i rozwiązuj problemy od razu, gdy na nie trafiasz. Oceniaj je rzetelnie i wyrażaj swój kod w najlepszy możliwy sposób.


Oryginał tekstu w języku angielskim przeczytasz tutaj.