Tag: code quality

O co chodzi w KISS?

by cholewinskimichalin Architektura, Zapewnienie jakości

Cześć. Ostatnie wpisy głównie skupiają się na pisaniu czystego kodu więc i dziś zarzucę kolejnym akronimem. KISS – to akronim od Keep It Simple Stupid. Pewnie zastanawiasz się, po co ja o tym piszę… Uważam, że jest to jedna z najważniejszych zasad pisania czytelnego kodu.

KISS nie jest zbiorem zasad jak SOLID, bardziej jest podobny do zasady DRY, czyli mówi nam, że musimy o czymś pamiętać, ale nie definiuje konkretnych reguł. KISS mówi nam o tym, aby zawsze pisząc kod mieć, z tyłu głowy, aby wszystko, co piszemy, było maksymalnie proste i czytelne.

Ważne, aby kod, który piszemy, nie był przekombinowany. Czasem probując wdrożyć powszechnie znane dobre praktyki w postaci wzorców projektowych, sprawiamy, że kod przestaje być czytelny. W takich przypadkach warto szukać złotego środka.

Opowiem Ci teraz przykład z życia wzięty, gdzie nie zastosowałem się do tej zasady. Pewnego razu dostałem zadanie rekrutacyjne. Zadanie polegało na napisaniu prostej aplikacji symulującej działanie maszyny vendingowej. Samo zadanie nie było trudne, ale niesamowicie ambitny Michał postanowił nadać klasom bardzo ładnie nazwy. Jednym z obiektów był sejf na monety wrzucane do maszyny. Nazwałem go zgodnie z tym co wyszukałem w google – Peter, a mogłem po prostu Safe.

Rezultat był taki, że feedback z zadania był negatywny a komentarz brzmiał “Przez pół godziny zastanawialiśmy się, co oznacza Peter w kontekście Twojej aplikacji”.

Podsumowanie

Wniosek z tego taki, że najprostsze rozwiązania są najlepsze i nie ma co za bardzo kombinować. Z programowaniem jest trochę jak z maturę z matematyki. Jeśli zadanie jest na 2 punkty, a Ty robisz już piątą linijkę obliczeń, to znaczy, że już przekombinowałeś (-aś).

Jeśli artykuł Ci się podobał, zapraszam do polubienia profilu na facebooku oraz obserwowania na instagramie. Zapraszam również do grupy Wsparcie w programowaniu i zadawania pytań oraz do kontaku.

Czy zasada DRY powinna być zawsze stosowana?

by cholewinskimichalin Architektura, Zapewnienie jakości

W tym całym IT strasznie dużo akronimów. Nawet samo słowo akronim brzmi trochę tajemniczo jak mu się bardziej przyjrzeć. Ale o co chodzi z tym DRY? Jest to skrót od słów Don’t Repeat Yourself. Nie trzeba wiele tłumaczyć, o co chodzi. Kluczowe w tej zasadzie jest to, aby pisać kod w taki sposób, aby nie trzeba było kopiować takiego samego bądź bardzo podobnego kodu. Jak myślisz… czy powinniśmy się kurczowo trzymać tej zasady?

Dlaczego tak?

Dobre praktyki mówią o wydzielaniu małych reużywalnych metod tak, aby nie trzeba było kopiować kodu. W idealnym świecie żaden większy kawałek kodu nie powinien być zduplikowany w obrębie jednej aplikacji. To bardzo dobre podejście i jak najbardziej powinniśmy tak tworzyć kod, aby jego części były tak zbudowane, aby można je było wykorzystać w innych miejscach. To trochę jak z niektórymi częściami samochodowymi pasującymi do wielu marek lub uniwersalnym pilotem do telewizora.

Dlaczego nie?

Często zdarza się w aplikacjach, że ktoś przesadzi z podejściem do reużywalności kodu i buduje bardzo skomplikowane generyczne rozwiązanie. Nie od dziś wiadomo, że coś, co jest do wszystkiego, jest do …

Budowanie generycznych rozwiązań powoduje, że kod przestaje być elastyczny i nietypowa zmiana biznesowa może wprowadzić bardzo dużo zamieszania do aplikacji i wywołać dużą frustrację wśród developerów.

Brak odporności na zmiany takich generycznych rozwiązań dobrze widać w projektach prowadzonych w podejściach zwinnych. Tam chyba żadne supergeneryczne rozwiązanie nie przetrwało próby czasu.

Podsumowanie

Odpowiadając na pytanie z tytułu, zachowam się jak rasowy konsultant i odpowiem “To zależy!”. Podejście do tego problemu zależy od wielu czynników. Jeden programista powie, że DRY trzeba stosować na każdym kroku, a inny powie, żeby nie stosować wcale. Nie no, ogólnie to zdecydowana większość się stosuje do tego. Moje doświadczenie podpowiada, aby nie wypływać za daleko na głębokie wody generyczności. Lepiej pozostać na suchym lądzie, ze swoimi małymi metodami i zrozumieniem, że duże ilości skomplikowanego kodu nie uczynią projektu lepszym. Najważniejsze w tym wszystkim jest zdrowe podejście i unikanie przewidywania, co się wydarzy w przyszłości, tylko budowanie rozwiązania na tu i teraz. Wtedy raczej nie przyjdzie nam do głowy budowania czegoś zbyt skomplikowanego i rzekomo do wszystkiego.

Jeśli artykuł Ci się podobał, zapraszam do polubienia profilu na facebooku oraz obserwowania na instagramie. Zapraszam również do grupy Wsparcie w programowaniu i zadawania pytań oraz do kontaku.