Thursday Feb 03, 2022

Zasady Projektowania Oprogramowania DRY i KISS

W tym artykule zamierzam zbadać zasady projektowania oprogramowania i ich korzyści, dlaczego zasady projektowania są dla nas przydatne i jak je wdrożyć w naszym codziennym programowaniu. Zbadamy zasady projektowania oprogramowania DRY i KISS.

Zasada DRY: Don’t Repeat Yourself

DRY to skrót od „Don’t Repeat Yourself” (nie powtarzaj się), podstawowej zasady tworzenia oprogramowania mającej na celu ograniczenie powtarzania informacji. Zasada DRY jest określana jako, „Każdy fragment wiedzy lub logiki musi mieć pojedynczą, jednoznaczną reprezentację w systemie.”

Naruszenia DRY

„We enjoy typing” (lub, „Wasting everyone’s time.”): „Lubimy pisać na maszynie” oznacza pisanie tego samego kodu lub logiki raz za razem. Trudno będzie zarządzać kodem, a jeśli logika się zmieni, to musimy wprowadzać zmiany we wszystkich miejscach, w których napisaliśmy kod, marnując w ten sposób czas wszystkich osób.

Jak osiągnąć DRY

Aby uniknąć naruszenia zasady DRY, podziel swój system na części. Podziel swój kod i logikę na mniejsze jednostki wielokrotnego użytku i używaj tego kodu, wywołując go tam, gdzie chcesz. Nie pisz długich metod, ale podziel logikę i spróbuj użyć istniejącego fragmentu w swojej metodzie.

Korzyści z DRY

Mniej kodu jest dobre: oszczędza czas i wysiłek, jest łatwy w utrzymaniu, a także zmniejsza szanse na błędy.

Jednym z dobrych przykładów zasady DRY są klasy pomocnicze w bibliotekach korporacyjnych, w których każdy fragment kodu jest unikalny w bibliotekach i klasach pomocniczych.

KISS: Keep It Simple, Stupid

Zasada KISS jest opisowa, aby kod był prosty i przejrzysty, co czyni go łatwym do zrozumienia. W końcu języki programowania są dla ludzi, aby zrozumieć – komputery mogą zrozumieć tylko 0 i 1 – więc utrzymuj kodowanie proste i proste. Utrzymuj swoje metody na niskim poziomie. Każda metoda nie powinna mieć więcej niż 40-50 linii.

Każda metoda powinna rozwiązywać tylko jeden mały problem, a nie wiele przypadków użycia. Jeśli masz wiele warunków w metodzie, podziel je na mniejsze metody. Będzie to nie tylko łatwiejsze do odczytania i utrzymania, ale może pomóc znaleźć błędy o wiele szybciej.

Naruszenia KISS

Wszyscy prawdopodobnie doświadczyliśmy sytuacji, w której dostaliśmy pracę do wykonania w projekcie i znaleźliśmy trochę niechlujnie napisany kod. To prowadzi nas do pytania, dlaczego oni napisali te niepotrzebne linie. Wystarczy spojrzeć na dwa fragmenty kodu pokazane poniżej. Obie metody robią to samo. Teraz musisz zdecydować, której z nich użyć:

public String weekday1(int day) { switch (day) { case 1: return "Monday"; case 2: return "Tuesday"; case 3: return "Wednesday"; case 4: return "Thursday"; case 5: return "Friday"; case 6: return "Saturday"; case 7: return "Sunday"; default: throw new InvalidOperationException("day must be in range 1 to 7"); }}public String weekday2(int day) { if ((day < 1) || (day > 7)) throw new InvalidOperationException("day must be in range 1 to 7"); string days = { "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }; return days;}

Jak osiągnąć zasadę KISS

Aby uniknąć łamania zasady KISS, staraj się pisać prosty kod. Pomyśl o wielu rozwiązaniach dla swojego problemu, a następnie wybierz najlepsze, najprostsze i przekształć je w swój kod. Kiedy znajdziesz długi kod, podziel go na wiele metod – kliknij prawym przyciskiem myszy i refaktoryzuj w edytorze. Staraj się pisać małe bloki kodu, które wykonują pojedyncze zadanie.

Korzyści z KISS

Jeśli mamy jakąś funkcjonalność napisaną przez jednego programistę i została ona napisana niechlujnym kodem, a jeśli poprosimy innego programistę o dokonanie modyfikacji w tym kodzie, to najpierw musi on zrozumieć ten kod. Oczywiście, jeśli kod jest napisany prosto, wtedy nie będzie żadnych trudności w zrozumieniu tego kodu, a także będzie łatwy do modyfikacji.

Podsumowanie

Podczas pisania jakiegokolwiek kodu lub modułu, pamiętaj o zasadach projektowania oprogramowania i używaj ich mądrze, uczyń z nich swój nawyk, abyś nie musiał pamiętać o nich za każdym razem. Pozwoli to zaoszczędzić czas rozwoju i sprawi, że twój moduł oprogramowania będzie solidny, co może być łatwe do utrzymania i rozszerzenia.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Back to Top