Zasady SOLID na Backendzie: Identyfikacja popularnych błędów

0:02W poprzedniej lekcji powiedziałem ci o dziesięciu błędach, które można popełniać

0:05pracując nad kodem i starając się współpracować z zasadami SOLID.

0:09A teraz nie zostawiam Cię samego albo samej, bo dam Ci kilka wskazówek,

0:14jak te błędy zidentyfikować.

0:16Więc punkt pierwszy to będzie analiza.

0:19Analiza jest zawsze pierwszym punktem u mnie i w każdym

0:24projekcie powinna być najpierw przeprowadzona analiza analiza

0:28odpowiedzialności klas.

0:30Więc na początku, żeby uniknąć tych przerośniętych klas, małych interfejsów,

0:35przeanalizuj ich odpowiedzialności.

0:37Zobacz, czy kluczowe klasy w systemie mają zbyt duże odpowiedzialności lub zbyt

0:42małe, bo może się okazać, że jakiś proces biznesowy, który tak naprawdę jest jedną

0:46odpowiedzialnością, jest rozbity na kilka różnych elementów niepotrzebnie.

0:51I można to opakować w jedną klasę, w jedną odpowiedzialność.

0:55Taka analiza odpowiedzialności może odbywać się na podstawie np.

0:58schematu, może na podstawie kodu jakiejś statycznej analizy kodu.

1:02Łatwo znaleźć jakieś narzędzia, które pozwalają nam

1:05sprawdzić, czy nawet IDE nam teraz udostępnia takie narzędzia, czy to pilot,

1:10czy czat CBT czy inne tego typu narzędzia, które pomagają nam analizować kod,

1:16są w stanie wychwycić miejsca, gdzie ta odpowiedzialność klas jest albo

1:20rozmyta, albo zbyt mała, albo zbyt duża.

1:23Więc punkt pierwszy to jest analiza.

1:25Analiza jest podstawą dobrego designu w kodzie.

1:27Druga kwestia, która idzie niejako z analizy, to ewaluacja

1:31hierarchii dziedziczenia.

1:32Mówiłem wcześniej, żeby stosować raczej kompozycję, a nie dziedziczenie.

1:36Że to dobry punkt w kierunku budowania systemu, który jest elastyczny

1:40i łatwy w utrzymaniu.

1:41I taka ewaluacja hierarchii dziedziczenia jest istotna.

1:45Jest ważna, bo często kończymy z klasami, które dziedziczą w jakimś chorym łańcuchu

1:50i tak naprawdę nie wiemy co po kim dziedziczymy.

1:52A zmiana w klasie bazowej ma olbrzymi impakt na wszystkie potomne klasy.

1:57W dużej mierze w nowoczesnym programowaniu, w nowoczesnym kodzie

2:00odchodzimy od takiego bardzo głębokiego dziedziczenia.

2:04Natomiast wciąż jest to obecne w projektach Legacy i sam osobiście

2:08widziałem to wiele razy, więc taka ewaluacja jest konieczna, żeby

2:11unikać niepotrzebnych błędów.

2:14No i jak mamy ewaluacja, mamy analizę, no to wystarczy to wszystko

2:17udokumentować i będziemy happy.

2:20A więc dokumentacja nowych zmian, dokumentacja starych zmian, dokumentacja

2:24wsteczna kodu jest bardzo istotna.

2:26Pisanie samo do komentującego się kodu, pisanie testów, które są dokumentacją dla

2:31kodu i wreszcie taka zwykła papierowa dokumentacja w konferencje jest

2:36niezbędna do tego, żeby uniknąć błędów.

2:39Dokumentacja to jest rzecz, której programiści i programiści nie cierpią, nie

2:42cierpią pisać, ale naprawdę w wielu przypadkach ratuje nam skórę.

2:46Kolejną kwestią będzie sprawdzenie martwych interfejsów.

2:50W kodzie możemy znaleźć dużo klas, które mają metody niewykorzystywane

2:54przez nikogo innego.

2:55I tutaj znowu odwołam się do zasady, gdzie zostawiamy kod lepszym niż go zastaliśmy.

3:00Jeśli natrafisz na metodę, która nie jest używana, a przypominam, że

3:03nowoczesne narzędzia do pisania kodu.

3:06Nowoczesne idee zaznaczają takie metody, które nie są nigdzie wywoływane,

3:11wobec czego mamy prostą drogę do usunięcia, do wyczyszczenia takiego kodu i

3:15przez to kończymy z mniejszymi interfejsami.

3:19Usuwamy te martwe i nieużywane interfejsy.

3:22Możemy dokumentować swoje zależności w systemie i mapować je.

3:26Jeśli mamy już dokumentację taką zwykłą, papierową lub w formie diagramów,

3:31warto nanieść na nią wszelkiego rodzaju zależności, listy parametrów.

3:35Takie dokumentacje mogą żyć w plikach HDMI, w konsumencie, w czymkolwiek, ale

3:40powinny być zawsze dostępne dla programistów i napisane łatwym i

3:44przystępnym językiem, tak aby ten dostęp i korzystanie z tej dokumentacji

3:50było jak najbardziej uproszczone.

3:53No i ostatnia kwestia to identyfikacja tzw.

3:55kod SMS śmierdzącego kodu, brudnego kodu, błędów w kodzie albo takich warstw w

4:01kodzie, które w konsekwencji na pewno będą prowadziły do problemów.

4:05Identyfikacja tych co mieli to intuicja.

4:08Doświadczenie to dobra znajomość zasad SOLID.

4:12Łatwo nam znaleźć kod Miele, jeśli dobrze znamy te 5 zasad, o

4:17których mówiłem wcześniej.

4:18Bo bo choćby na podstawie zasady SRP identyfikujemy proste klasy, ale też

4:23identyfikujemy te, których odpowiedzialność jest zbyt duża, gdzie

4:27zależności nie są wydzielone lub gdzie interfejsy się nie pokrywają i

4:31nie umożliwiają podstawienia.

4:34Te 6 wskazówek pozwoli Ci zidentyfikować błędy i ich unikać, więc trzymam

4:38kciuki za Twój czysty kod.

4:39Dobry i solidny kod i stabilne, elastyczne systemy, które tworzysz.