Refaktoryzacja bardzo często kojarzy się z czymś skomplikowanym i czasochłonnym, dziś trzy lekkie lekcje zadające kłam tej teorii. Wszystko w myśli tego zdania:

modyfikowanie elementów systemu w celu wpasowania ich w przyjęte standardy i wzorce

Youtube na końcu wpisu.

Część pierwsza

Tak samo

Spójrz na taki kod i postaraj się znaleźć wszystkie metody który Twoim zdaniem dodają coś do bazy danych.  (zignoruj na chwilę ogromną ilość metod w jednej klasie to temat na inny wpis)

Skupiając się tylko na części Create z CRUDa da się odnaleźć:

AddCommentRequestByUserForArticle, AddEventRssSkipped, AddEventRssViewed, AddFullArticleRequestByUserForArticle, AddNotReadRequestByUserForArticle, AddReadLaterRequestByUserForArticle, AddShareRequestByUserForArticle, AddVoteDownRequestByUserForArticle, AddVoteUpRequestByUserForArticle, AssignUserRole, CopyAllUnreadElementsToUser, CreateNewSociaLogin, CreateNewSubscription, CreateNewSubscriptionForUserAndChannel, CreateNewUser, MarkRssClicked, AddEventRssClicked, MarkRssNavigated, AddEventRssNavigated, InsertReadRssToRead, MarkAllReadForUserAndSubscription, MarkChannelRead, SaveChannelCreatedEventToDatabase, SaveContactAdministrationEventEventToDatabase, SaveContactAdministrationToDatabase, SaveEvent, SaveToDatabase, SaveExceptionToDatabase, Subscribe, AddEventPersonActivityClicked, AddEventPersonActivityNavigated, AddEventPersonActivitySkipped, MarkChannelUpdateClicked, MarkChannelCreateClicked

Widać różnie prefiksy który się pojawiają do opisania akcji, który ma za zadanie zapisanie danych do bazy danych: add/assign/copy/create/mark/save/. Metody powstawały w różnych okresach i pewnie jak by się przyjrzeć to odpowiednie prefiksy pasują do tych z warstwy wyżej. Na przykład jeśli metoda w serwisie nazywała się MarkClicked to nazwa na warstwie repozytorium też się tak nazywała. Może to byłe wtedy fajne i dobre. Tworzyłem kolejną metodę w serwisie o nazwie AddJakiśNowyEvent to pojawiała się metoda AddJakiśNowyEvent w repozytorium i było jasne że one ze sobą pracują.
Tylko że teraz, proszę ja ciebie gdy mam takie dwie metody MarkAsRead oraz MarkAsViewed, i obie przekazują dane z serwisu do repozytorium, praktycznie ten sam zestaw danych. Jedna z nich robi insert druga z nich robi update – zgadniesz która?

Dlaczego o tym mówię? Projekt tworzę sam, powinienem wszystko ogarniać, wszystko wiedzieć, móc wszystko 😉 Zdarzają się jednak niespodzianki czy duplikowanie kodu. Już odpowiadam dlaczego – ponieważ nazwy metod nie są spójne (i nie do końca jasne?). Jak wyczuć że MarkAsRead robi INSERT ale już MarkAsViewed robi UPDATE? Dopóki jest to dla mnie świeży temat to jasne – będę pamiętać. Ale gdy skończę daną funkcjonalność zapomnę i będę musiał sprawdzać, albo co gorsza poprawić bugi z tym związane. Gdybym od razu podszedł to tematu trzymając się na przykład założenia, że skoro moja aplikacja to nic innego niż fantazja nad CRUDem i że nazwy metod mogłyby zaczynać się od na przykład prefiksów create/read/update/delete miałbym wtedy jedno “miejsce” gdzie mógłbym szukać insertów do bazy danych. Mógłbym mieć metody w repozytorium który nazywały by się w takim stylu:

CreateEventRead, CreateRoleForUser, CreateRssForUser, CreateContactToAdministration, UpdateRssByWithClick, UpdateRssEntriesWithSkipEvent, ReadRssEnties, ReadUserPublicProfile, DeleteReadEvent, …

Takie podejście kosztuje chwilę czasu, aby lekko przeformatować swoje myśli, ale mam nadzieję że wprowadzi ono porządek do projektu, oraz ułatwi wcześniejsze wykrycie kodu który już jest, co powinno zmniejszyć poziom jego duplikacji.

Część druga

dLa sPrAwNeGo cZyTeLnIkA TeN TeKsT NiE PoWiNiEn sPrAwIć pRoBlEmU. Ddoponioe tne tkest ad sęi tżeak oydtaczć.
bUt tHe mOmEnT YoU StArT TyPiNg iN FoReIgN LaNgUaGe, ThInGs gEt mEsSy. Adn dno’t gte em satetrd wtih tsih apaporch.

Literówki

Słynne literówki, których ten blog jest pełen. Powodują że wyszukanie czegoś graniczy z cudem. Niby coś jest w kodzie, a nie można tego znaleźć, bo nie często popełnia się tę samą literówkę dwa razy (chyba, że jesteś mną). Czasami zdarza się zamienić literki miejscami, czasem się jedną zje, a czasem wybierze się odmianę amerykańską zamiast brytyjskiej, znam ludzi, który się o to czepiają.

color or colour

Należy to od razu się to naprawić i wrzucić do repozytorium. Mnie osobiście bardzo bolą literówki związane z bazą danych, a jeszcze bardzie literówka w bazie na produkcji- albo raczej jej naprawa, oj joj joj jak boli.

Kejsówki

Bo kto mi zabroni? Drobna rzecz a kłuje w oko, gdy nazwy w definicjach tych samych pól różnią się przyjętą w konwencji wielkością znaków. Bardzo często pojawia się notowanie identyfikatora obiektu przez ID lub Id. Czy UserID lub UserId. To kolejna rzeczy która może utrudnić szukanie (jeśli włączony jest case-sensitive), czy zaburzyć łagodny i delikatny flow aplikacji gdy trzeba porównać UserId z ID użytkownika. To co ważne tutaj: nie ma jedynego słusznego rozwiązania, ważna jest przyjęta konwencja, jeśli ID to wszędzie ID, jeśli Id to wszędzie Id.

KONWENCJA PLAŻO!

ps.
Spójrzcie podobnie na swoje UserViewModel lub UserViewmodel, czy nazwy zmiennych uvm, uservm, userVM, userVm czy może macie jeszcze inaczej? Może to też warto wyprostować i pilnować tego w projekcie.

Część trzecia

Klamry

Klamerki i ogólnie przyjęte formatowanie kodu. Dla lepszej czytelności i spójności kodu gdy widzisz, że gdzieś w kodzie ich brakuje zmień ten stan i dodaj je. Bez względu na przekonania takie czy inne, weź klawiaturkę w rękę i dodaj { a potem }. Spójrz na kod poniżej

Na pierwszy rzut oka się może wydawać, że kod jest płaski, a jego skomplikowanie niskie. Rajt? No to po dodaniu klamerek wygląda tak:

I gdy kod po dodaniu klamerek zaraz za ifem/elsem powoduje u Ciebie odruch wymiotny, bo przecież:

To zaciśnij usta mocno i pomysł skąd się bierze ten wzorzec? Czy dodanie { } to spowodowało, czy może on tam był ukryty, a dopiero dzięki klamrom wreszcie go dostrzegłeś? Dziękujemy wam o klamerki za wywabienie potwora z ciemności. Poprawimy to w sprincie technicznym, albo żyć będziemy w pogardzie dla samych siebie po wsze czasy.

Enter

Tak samo gdy znajdziesz długie jedno linijkowce, zachęcam by je lekko połamać i sprawdzić na ile właściwych linijek kodu się mogą zamienić. Spójrz na kod poniżej i pomyśl, który z nich prościej jest Ci przeczytać?

Poprzez użycie entera w krótkich punktach wskazujesz to co chcesz aby stało się z danymi pobieranymi z źródła danych

Enter znowu

Enter poza takim oczywistym połamaniem długich linijek oznacza jeszcze jedną ważną rzecz, jest on naturalnym rozgraniczeniem myśli/intencji. Możemy zapisać kod w taki sposób:

Ale możemy sobie trochę pomóc w czytaniu tego co piszemy i lekko zmodyfikować tę metodę, na przykład w taki sposób:

Widać teraz wyraźny podział metody na kilka odpowiedzialności (!). Płyną z tego dwie korzyści, po pierwsze sama metoda jest czytelniejsza, po drugie kolejny raz wychodzi, że kod który powstaje nie do końca zna regułę SRP. Na szczęście sprint techniczny mamy już zaplanowany.

Koniec

Jak się okazuje możemy wykonać taką refaktoryzację, która nie będzie kosztowała miliona cebul, nie będzię wymagać od nas skupienia się i szukania wzorców, z których moglibyśmy skorzystać aby uczynić nasz kod piękniejszym. Ot zwykła poprawa czytelności kodu.

Film do wpisu: