Refactoring
DRY, KISS, SOLID, czyli akronimy programistyczne
DRY, KISS, SOLID, czyli akronimy programistyczne.
Wszyscy je znamy, ale czy na pewno?
Jaką wartość i wiedzę niosą ze sobą?
Dowiedz się. Sprawdź. Zobacz.
DRY, KISS, SOLID, czyli akronimy programistyczne.
Wszyscy je znamy, ale czy na pewno?
Jaką wartość i wiedzę niosą ze sobą?
Dowiedz się. Sprawdź. Zobacz.
Wykonanie dużego refaktoringu, nie jest zadaniem prostym. Wymaga skupienia, doświadczenia i dyscypliny. Robiłem to wielokrotnie, z różnymi rezultatami. Z każdym następnym razem staję się coraz bardziej doświadczony. W trakcie swojej pracy udało mi się wypracować kilka zasad, które czynią tę czynność łatwiejszą i bezpieczniejszą. Część z nich to dobre praktyki przy refaktoringu, a cześć to po prostu zasady tworzenia dobrego kodu, które w tej sytuacji pomagają mi ogarnąć kod. Wszystkie jednak odpowiadają na pytanie: „Jak refaktorować?”. Zapraszam serdecznie!
Akronim SRP jest bardzo popularny. Jednak jak wiele członków programistyczengo świata tak naprawdę go rozumie i stosuje? A jaka jego część tworzy kod według tych zasad? Czy jesteś w stanie opisać jak według Ciebie powinna wyglądać klasa spełniajca tę zasadę? Poniżej opisałem jak ja stosuje się do Single Responsibility Principle i dlaczego lubię, gdy klasa ma tylko jedną metodę.
Spotkałem kilka razy w życiu klasy, które były do wszystkiego. Taka jedna świetna „reużywalna” klasa, która jest używana w wielu kontekstach. Opisywałem już taki przykład w poście Jak refaktorować – 7 – Replikacja i ćwiartowanie. Może zamiast wielokrotnego użycia kodu, powinniśmy zwrócić większą uwagę na separację poszczególnych komponentów.