TheCodestReview #5 - dwutygodnik poświęcony inżynierii oprogramowania

W ostatnim odcinku podjudzałem do skomentowania artykułu o znaczeniu humoru w miejscu pracy, ale w międzyczasie doszedłem do wniosku, że zasługuje on na znacznie więcej uznania, więc wkrótce napiszę o tym cały wpis na blogu.    

Rzeczy, które sprawiły, że byłem zajęty przez ostatnie kilka tygodni: 

a) Przed świętami wystartowałem z premierowym odcinkiem Seria webinariów "Kuloodporny CTO" (bądź na bieżąco z 2. odcinkiem w lutym poświęconym SaaS) CTOsszczegóły wkrótce na moim LinkedIn).

b) Dostrojenie naszego planu rozwoju na 2021 r. w celu wyjścia poza naszą podstawową działalność Ruby i JS oraz rozwoju Magento i Produkt Kompetencje w zakresie projektowania wewnętrzny.

Dość autopromocji, zapraszam do piątego odcinka naszej serii #TheCodestReview. 

Tematy moje zespół przygotował się na ten czas: 

1. Skalowalna i łatwa w utrzymaniu architektura front-end.
2. Konwencjonalne zatwierdzenia.
3. Aktualizacje wydania Ruby 3.0.0.

Komentarze do aplikacji frontendowej i konwencjonalne commity są dostarczane w tym tygodniu przez naszych inżynierów React, podczas gdy Ruby 3.0.0 przez nasz Ruby dream team.

Obecnie wielu programistów, aby zaoszczędzić czas, korzysta z gotowych bibliotek UI i komponentów wielokrotnego użytku. Jest to dobra praktyka i pomaga nam zaoszczędzić dużo czasu, ale kiedy nasz projekt staje się większy - zrozumiesz, że nie wystarczy radzić sobie z kod.

Istnieją dwa dobre wzorce z programowania back-end - Domain Driven Development (DDD) i Separation of Concerns (SoC). Możemy je również wykorzystać w architekturze front-endu.

W DDD staramy się grupować podobne funkcje i oddzielać je w jak największym stopniu od innych grup (modułów).

Podczas gdy w przypadku SoC na przykład oddzielamy logikę, widoki i modele danych (np. przy użyciu wzorca projektowego MVC lub MVVM).

Istnieje wiele dobrych praktyk i wzorców do wykorzystania, ale ten sposób jest dla mnie preferowany.

Gdy użyjemy tego wzorca, otrzymamy następujący obraz:

Na początku użytkownik jest przekierowywany do właściwego modułu przez routing aplikacji. Każdy moduł jest całkowicie zamknięty. Ponieważ jednak użytkownik oczekuje, że będzie korzystał z jednej aplikacji, a nie z kilku małych, będzie istniało pewne sprzężenie. Sprzężenie to dotyczy określonych funkcji lub logiki biznesowej.

I mamy tę strukturę:

folder app - warstwa aplikacji

assets - folder na zdjęcia, czcionki, ikony itp.

komponenty - tutaj powinny znajdować się komponenty do ponownego użycia, które nie mają skomplikowanej logiki

config - tutaj będziemy przechowywać stan globalny

lib - folder dla skomplikowanych funkcji i obliczeń logicznych

moduły - oto nasze moduły

pubsub - miejsce do przechowywania schematów opisujących strukturę danych.

style - dla naszego kodu css/scss

Ta struktura pomoże nam poradzić sobie z rosnącą aplikacją i zmniejszyć liczbę błędów. Pomoże również w tworzeniu wygodniejszych części roboczych z oddzielnymi modułami, testowaniu ich i ułatwianiu refaktoryzacji i debugowania (z powodu oddzielnych modułów).

Jeśli spojrzymy głębiej na architekturę modułów i ich powiązania z API - otrzymamy coś takiego:

W folderze "app" utworzymy kolejny folder "api" z kodem do wywołań API i danymi, które zapiszemy w "config/store". Tutaj przechowujemy statyczne i niezmienne dane, których używamy w całej aplikacji.

Również w folderze "pubsub/schema" opiszemy konkretne typy danych dla JavaScript przedmioty.

Wszystkie moduły zawierają dane, z których musimy korzystać (użytkownicy, trasy, tabele, akcje itp.). Każdy moduł jest połączony z warstwą aplikacji i pobiera wszystkie niezbędne dane.

Front-end jest pierwszym punktem wejścia dla naszych użytkowników. Wraz z rosnącą liczbą funkcji w naszych projektach front-endowych, będziemy również wprowadzać więcej błędów. Ale nasi użytkownicy oczekują braku błędów i szybkich nowych funkcji. Jest to niemożliwe. Jednak korzystając z dobrej architektury, możemy spróbować osiągnąć to w jak największym stopniu.

Konwencjonalne zatwierdzenia Sathyabodh Mudhol na DZone

Powód, dla którego warto zaangażować się w pracę w lepszy sposób

Wyobraź sobie, że jesteś w punkcie startowym w firmie, w której właśnie zostałeś zatrudniony. Wszyscy ludzie są dla ciebie mili i wszystko wydaje się w porządku, aż do momentu, w którym zostajesz wprowadzony do bazy kodu z czasów, gdy JavaScript był językiem, a Netscape ładował stronę przez coś, co wydawałoby się wiekiem.

Dziedziczenie kodu wydaje się być ogromnym problemem podczas wprowadzania nowych programistów do projektu. Czytanie kodu to jedno, ale zrozumienie, w jaki sposób aplikacja została opracowana, to nie to samo. Często commity okazują się przydatne i nadają kontekst temu, dlaczego te console.logs nie zostały przechwycone przez linter lub dlaczego to paskudne // TODO jest tam dla dzieci dewelopera, który początkowo utworzył adnotację.

Zacznijmy od tego, dlaczego konwencjonalne zatwierdzenia są lepsze niż niestandardowe reguły zatwierdzania.

Jeśli zatrudniamy nowych deweloperów do projektu, w którym większość commitów składa się z komunikatów typu to powinno działać lub Sleepy fix for footer ASAP, co pojawia się w Twojej głowie?

Powiedziałbym, że czerwone flagi, ponieważ:

• Nie wiemy, co dokładnie powinno działać
• Dlaczego ktoś naciskał na coś, będąc zaspanym i potencjalnie błędnym?
• Czy poprawka została wprowadzona w pośpiechu, skoro widzimy adnotację ASAP?

Ponieważ zespół może mieć niestandardowe reguły stosowane do zatwierdzania zmian, jest mniej miejsca na błędy, ponieważ zatwierdzenie musi być solidne. Nie jest to już sposób na wymeldowanie się. To podpis, który mówi innym ludziom, że znałeś treść zatwierdzenia. Nie trzeba wspominać, że jeśli praca, którą wykonałeś, nie jest poprawnie podpisana, najprawdopodobniej spowoduje to błąd i wyświetli komunikat

Istnieje szansa, że Twój zespół chciałby skonfigurować regułę zabraniającą używania określonych słów kluczowych, więc ASAP lub wszelkie przekleństwa mogą znaleźć się na czarnej liście.

Oprzyrządowanie

To, co jest naprawdę pomocne na początku projektu, to przedstawienie wszystkim, w jaki sposób zespół deweloperów chcieliby, aby nowi deweloperzy zatwierdzali swoje zmiany. Następnie skonfiguruj narzędzie, które pomoże im nadążyć za tym, co wszyscy uzgodniliście.

Jednym z narzędzi, z którymi miałem okazję pracować, było commitlint i sprawiło, że konwencjonalne zatwierdzenia stały się moją praktyką, gdy przychodzę do nowych projektów, które nie mają reguł, a zespół jest otwarty na pomysł ich wprowadzenia.

Mając do czynienia z ustawieniami i rozpowszechniając je w całym zespole, możesz po prostu utworzyć pakiet npm i po prostu mpn i -D go w każdym projekcie. To z pewnością pomoże wszystkim w projekcie być na tej samej stronie przez cały czas i w razie potrzeby chodzić od projektu do projektu, rozumiejąc, jakie były ostatnie zmiany (i dlaczego zostały wprowadzone).

Przyjaciele z wieloma korzyściami

Więc teraz, po skonfigurowaniu wszystkiego i zrozumieniu, dlaczego dobrym pomysłem może być rozpoczęcie korzystania z CC, najlepszą częścią byłoby programowanie wokół zasad, które właśnie zastosowałeś! Używamy ustandaryzowanego sposobu zatwierdzania, zwracamy większą uwagę na to, czego naprawdę dotyczy zatwierdzenie, więc dlaczego nie skonfigurować haków, które pozwolą na szybkie testowanie na etapie przejściowym, gdy obecna jest flaga? Nie chcemy przeciążać usług i ciąć kosztów w razie potrzeby, a istnieją pewne powody, aby testować na serwerze podobnym do produkcyjnego zamiast na localhost.

Załóżmy, że pracujesz nad PWA i SSL jest potrzebny do przetestowania pełnego potencjału i masz SSL na swojej platformie testowej. Wszystko, czego teraz potrzebujesz, to dobry commit. Coś w stylu feat(PWA): manifest icons workbox setup upload uruchomiłoby całą maszynerię testowania i przesuwania kółek zębatych. Nie potrzebujemy tego, gdy po prostu przesyłamy statyczne dane, takie jak manifest.json, więc dodajemy flagę [TEST_SKIP] jako postfiks do naszego zatwierdzenia. Dzięki temu nasz CI może po prostu przesłać nowe zasoby do środowiska testowego i pominąć testowanie. Możesz przeczytać więcej na ten temat tutaj

Po pewnym czasie będziesz w stanie dostrzec inne korzyści, takie jak łatwość generowania CHANGELOG i lepsze wersjonowanie dzięki wersjonowanie semantyczne. Jeśli to nie wystarczy, aby przekonać cię do zmiany sposobu pisania wiadomości commit, być może zanurzenie palców w świeżej zimnej wodzie i próba użycia ich w prywatnym repozytorium na chwilę zmieni zdanie.

Szczęśliwego konwencjonalnego zaangażowania!

Aktualizacje wydania Ruby 3.0.0 przez Ruby Community

Długo oczekiwane przez społeczność wydanie Ruby 3.0.0 ujrzało światło dzienne w Boże Narodzenie, aby wszyscy deweloperzy Ruby mogli znaleźć je pod choinką, gdy tylko obudzą się rano. W The Codest kultywujemy kulturę dzielenia się wiedzą, organizując cotygodniowe spotkania deweloperów, podczas których nasi inżynierowie omawiają trendy technologiczne i nowe odkrycia warte uwagi. Poniżej znajduje się link do slajdów z dnia demonstracyjnego, w którym nasz starszy inżynier Ruby omówił kilka ważnych zmian w Ruby 3.0.0 z jego subiektywnego punktu widzenia:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

Co więcej, nasz mentor Ruby przyczynił się do powstania nowej wersji poprzez pull request, który został pomyślnie scalony. Więcej na temat metod kontroli prywatności można znaleźć poniżej w krótkim artykule naszego szefa działu rozwoju.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

Bardzo dziękuję za przeczytanie i jeśli dotarłeś tak daleko, doceniam Twój czas, a każda opinia jest mile widziana na LinkedIn lub na mój e-mail.

Wracamy z kolejnym odcinkiem pod koniec lutego z recenzją podcastu z wywiadem z CTO z Shopify, człowiekiem stojącym za zespołem inżynierów pracującym nad wspaniałą aplikacją Ruby monolith!

Do zobaczenia.

Czytaj więcej:

TheCodestReview #4 - cotygodniowy sok z inżynierii oprogramowania

TheCodestReview #3 - cotygodniowy sok z inżynierii oprogramowania

TheCodestReview #2 - cotygodniowy sok z inżynierii oprogramowania