Notatka z nauki: PyWaw #92 – Od legacy do czystej architektury

przez Karol Bocian | 27 listopada, 2020

W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami.

Notatka

Materiał Od legacy do czystej architektury opowiada o tworzeniu oprogramowania w koncepcji czystej architektury. Wynotowałem z tego materiału:

  • Czysta architektura to oprogramowanie, w którym nasza logika biznesowa jest niezależna od bazy danych, frameworków, interfejsu użytkownika. W jej centrum jest domena aplikacji, największa wartość biznesowa.
  • Kończ rzeczy, ucz się na tym i bierz kolejną rzecz, aby ją skończyć i znowu się nauczyć czegoś. Przez kończenie rzeczy uczysz się i robisz kolejne rzeczy lepiej. Kończ rzeczy szybko i często. Rób krótkie pętle informacji zwrotnej.
  • Mity refaktoryzacji:
    • Trzeba mieć na to sprint – nie trzeba, refaktoryzację można robić cały czas.
    • Trzeba mieć na to pozwolenie kierownictwa – nie trzeba, już je w sumie masz, jeżeli robisz zadania związane z utrzymaniem.
    • Trzeba refaktorować całą aplikację – nie trzeba, można (a nawet należy) robić to krok po kroku.
    • Nie ma na to czasu – ale jest czas na wprowadzanie usprawnień zmniejszających czas naprawy błędów i wdrażania nowych funkcjonalności.
    • Trzeba robić tylko nowe funkcje – jeżeli nie musisz obsługiwać błędów i poprawek, to racja – nie Ty zajmujesz się refaktoryzacją legacy code.
    • Zrobimy refaktoryzacje później – to później jest dziś, a często było wczoraj. Jutro nigdy nie nadchodzi, zawsze jest dzisiaj.
    • Mamy nietechnicznego Product Ownera / Kieorwnika i nie rozumie refaktoryzacji – należy z ludźmi z kierownictwa rozmawiać ich językiem – językiem korzyści biznesowej.
    • Refaktoryzacja jest stratą czasu i nie wnosi wartości dla biznesu – niektóre refaktoryzacje nie wnoszą nic do biznesu, więc są zbędne. Niektóre jednak wnoszą. Należy to umiejętnie pokazać.
    • Refaktoryzacja służy do pozbycia się słabego kodu, a bardziej zmienieniu słabego w lepszy.
  • Refaktoryzacja to:
    • Nasza codzienna praca – zasada skauta – trochę popraw obecną sytuację. W każdej chwili próbuj trochę coś poprawić.
    • Pracuj małymi kroczkami – zrób małą poprawkę i commituj to. Kod będzie już trochę lepszy. Łatwiej też robić refaktoryzację w małych krokach. Próbowanie zmienić wszystko na raz i wszystko od razu usprawnić kończy się zazwyczaj revertem wszystkich zmian.
    • Nierobienie od razu ideału, lecz dążenie do ideału – zrób mały kroczek polepszający. Ideału i tak nigdy nie osiągniesz.
  • Refaktoryzacja do czystej architektury:
    • Krok 0 – poznanie obecnej sytuacji.
    • Krok 1 – zrób testy.
    • Krok 2 – zmień kod, aby był testowalny. Użyj np. tych przekształceń: extract function, change function declaration, replace control flag with break, replace control flag with exception, extract class.
    • krok 3 – upiększaj.
  • Jeżeli w kodzie masz śmietnik, to:
    • Nie przepisuj, lecz refaktoryzuj (krok po kroku).
    • Zastanów się nad procesem wytwarzania oprogrowania – dlaczego uzyskaliście w śmietnik?
    • Popraw proces wytwarzania oprogramowania, aby osiągać czysty kod i piękną architekturę, a nie śmietnik.
    • Refakturyzuj i poprawiaj.
  • Rozbijaj refaktoryzację (i wszystko) na małe kroki.
Podsumowując:
  1. Działaj w małych krokach.
  2. Poprawiaj kod, aby był testowalny.
  3. Pisz testy.
  4. Poprawiaj kod (refaktoryzuj).

Wszystkie posty związane z notatkami z nauki:

Źródła

Obraz główny

Materiał

Kategoria: Notatki z nauki

O Karol Bocian

Programowanie i świat agentów programowalnych, który poznał na Wydziale Matematyki i Nauk Informacyjnych, wciągnął go w przemysł IT. W trakcie swojej praktyki zawodowej Karol zrozumiał, że nie ważne co się robi i kim się jest, ale wiedza z zarządzania przydaje się wszędzie. Rozpoczął studia na kierunku Zarządzanie i Inżyniera Produkcji. W przypadku Karola zarządzanie to nie tylko teoria czy praca, ale prawie każdy element jego życia, to jego pasja.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *