1. "My name is ..." Poprawne nazewnictwo 📣

Jak świat długi i szeroki, każdy programista zderzy się z tym tematem. Temat poprawnego nazewnictwa jest poruszany codziennie przez tysiące programistów.

Najważniejsza zasada jest taka, aby nazywać zmienne, metody, klasy, pliki oraz wszystko inne w taki sposób, aby niosły za sobą przekaz oraz kontekst w jakim dana konstrukcja jest wykorzystywana.

Podejście takie poprawia czytelność kodu, ułatwia debugowanie, pozwala szybciej zapoznać się z tym za co dany kod jest odpowiedzialny.

Sprawdźmy zatem jakie częste problemy pojawiają się z nazewnictwem, gdy programista zaczyna swoją przygodę z Angularem.

2. Jak dobrze typujesz? 👉👆👇👈

Wielu programistów na początku przygody z Angularem notorycznie zapomina o dodawaniu typów do zmiennych i metod.

Wielokrotnie słyszałem od swoich studentów: "Po co dodawać te typy skoro bez nich aplikacja także działa i kod się kompiluje."

Angular i Type Script po to wprowadza silne typowanie, aby z niego korzystać. Takie podejście zapobiega wielu błędom związanym z odwoływaniem się np. do zmiennych w obiekcie, które nie są zdefiniowane. Silne typowanie zapobiega także przypadkowemu przypisaniu do zmiennej, która jest typu "string" wartości np. typu "boolean" oraz poprawia czytelność kodu.

Przykład jak zostać dobrym "typerem" poniżej.

3. Widać mnie, nie widać. Operatory widoczności 👀

Operatory widoczności są równie często pomijane jak silne typowanie. Przy operatorach widoczności sprawa jest dosyć intuicyjna i bardzo prosta.

Posiadamy dwa główne operatory widoczności jak public oraz private. Istnieje jeszcze typ protected, natomiast jest on związany z dziedziczeniem i jest rzadziej wykorzystywany. W naszym przypadku przerobimy dwa operatory jakimi są public oraz private.

Istnieje jedna bardzo prosta, ale ważna zasada, która pozwoli Ci w łatwy sposób stwierdzić czy zmienna/metoda powinna posiadać operator public czy private.

"Jeżeli konstrukcje jak zmienne, metody będą wykorzystywane w..."
(kliknij poniżej, aby zobaczyć więcej 👀).

4. Importujesz wszystko, czy tylko to co niezbędne? 📦

Króciutki temat związany z importami. Często zdarza się, że podczas pisania kodu mamy jakiś pomysł, który po chwili okazuje się nietrafiony. Zaczynamy pisać jakąś metodę, która zwraca dany obiekt i w tym momencie IDE automatycznie dodaje import tego obiektu do naszego komponentu. Po głębszym zastanowieniu okazuje się, że powinniśmy napisać tę funkcjonalność inaczej, po czym usuwamy taką metodę, natomiast import nadal pozostaje i jest niewykorzystywany.

Można oczywiście takie nieużywane importy usuwać ręcznie, natomiast istnieje pewien skrót klawiszowy, który zrobi to za Ciebie.

Skrót, który wyczyści za Ciebie importy w mgnieniu oka to:
(lewy ctrl + lewy alt + ...)

5. Czy zrobiłeś porządki? Pozostałości w kodzie 🧹

Tutaj, tak samo jak w przypadku importów, zdarza się, że mamy pewien pomysł na rozwiązanie, po czym okazuje się, że koncepcja uległa zmianie. Zaczynamy pisać kolejną metodę lub dodajemy inną zmienną, a pierwotną koncepcję pod wpływem euforii pozostawiamy.

Pod wpływem weny zdarza się, że piszemy kod nie zważając na formatowanie, odpowiednie wcięcia w kodzie oraz odstępy. Po kilku godzinach testowania napisanego kodu, okazuje się, że nasze nowe rozwiązanie działa świetnie.

Szczęśliwi wracamy do kodu i okazuje się, że są w nim nieużywane pozostałości oraz wygląda on jak pobojowisko. Tutaj z pomocą także przychodzi skrót klawiszowy, który pomoże Ci sformatować kod, natomiast nieużywane metody i zmienne trzeba będzie usunąć ręcznie.

Aby sformatować kod w mniej niż sekundę, skorzystaj ze skrótu:
(lewy ctrl + lewy alt + ...)

6. Komentarze i logi. Uważaj na brzydkie wyrazy! 🤬

Programowanie często bywa frustrujące oraz nie jest najspokojniejszym zawodem na świecie. Zdarza się, że po wielu godzinach, dniach, a nawet tygodniach okazuje się, że rozwiązanie nie działa i nie wiemy jak sobie poradzić z danym problemem. Dodajemy kolejne console.logi, aby sprawdzić zagmatwane zależności między metodami, ale nadal nie możemy rozgryźć co powoduje problem.

Takie sytuacje bywają stresujące oraz niejednokrotnie mamy ochotę rzucić przy tym soczystym ciągiem wulgaryzmów. Nie ma się czego wstydzić i jest to w pewnym sensie część pracy programisty.

O ile wulgaryzmy pojawią się w Twojej głowie, albo wybrzmią cicho pod nosem nie ma większego problemu, natomiast uczulam Cię na fakt, aby nie zostawiać takich pamiątek w kodzie.

Gdy w końcu uda się rozwiązać problem pamiętajmy, aby usunąć wszelkie pozostałości po stoczonej bitwie.

7. Wycieki pamięci! Odsubskrybowałeś strumienie? 🏊🏻

Wiele poradników pokazuje jak dokonać subskrypcji na strumieniu przy wykorzystaniu operatora subscribe(). Nie wszystkie natomiast zwracają uwagę na fakt, że przy dokonywaniu subskrypcji należy pamiętać, aby się od takiego strumienia odsubskrybować.

Jeżeli temat strumieni jest Ci obcy, zapraszam Cię do obejrzenia wideo:
Angular: wprowadzenie do aplikacji biznesowych. Podstawy w 45 minut.
Przedstawiam tam temat strumieni na prostej analogii do wody płynącej w rurach. Dzięki pokazaniu tematu w obrazowy sposób, łatwiej zorzumiesz o co w tym wszystkim chodzi.

Do wartości strumienia możemy dobrać się na dwa sposoby. Jeden z nich to wykorzystanie operatora subscribe() w komponencie oraz drugi z nich to wykorzystanie wbudowanego pipe'a async w szablonie.

Sprawdź jakie są różnice oraz jak poprawnie obsubskrybować się ze strumienia, gdy korzystasz z operatora subscribe().

8. Sytuacje niepożądane. Obsługa błędów 🚫

Jest to kolejny ważny aspekt, na który warto zwrócić uwagę. Najczęstszym podejściem do wykonywanego zadania jest obsłużenie tzw. "happy path" czyli sytuacji, gdy pobraliśmy dane i nie było po drodze żadnych problemów.

Jako, że nie żyjemy w świecie idealnym warto mieć z tyłu głowy, że sytuacje niepożądane mogą nas spotkać.

Wystarczy źle przekazany parametr, niedostępność serwera, literówka i nasza aplikacja ze stanu "pobrałem i zaprezentowałem dane" przechodzi w stan "dlaczego mam biały ekran i nic się nie dzieje?".

"Obsługa błędów" brzmi groźnie, natomiast nie jest tak straszna i skomplikowana jak może się to pierwotnie wydawać.

CatchError będzie Twoim przyjacielem przy obsłudze sytuacji niepożądanych.

9. DRY - Czy jesteś "suchy"? 💨

DRY to akronim od stwierdzenia: "Don’t repeat yourself."

Jest to jedno z podstawowych założeń w programowaniu. W skrócie chodzi o to, aby nie powielać kodu. Jeżeli posiadasz pewną funkcjonalność, która np. oblicza jakąś wartość lub zmienia kolor ramki, albo wykonuje jakiekolwiek inne operacje i zauważysz, że w Twoim kodzie kopiowałeś i używałeś takiego samego kodu w kilku miejscach, to jest to znak, że powinieneś taką część kodu wynieść np. do oddzielnej reużywalnej metody.

Co zyskujemy?

Dzięki takiemu podejściu zyskujemy dwa najważniejsze elementy:

1) Reużywalność
2) Łatwiejsze wprowadzanie zmian

10. Czy kod spełnia wymagania biznesowe? 💼

Gdy już przejrzysz kod pod kątem technicznym i uznasz, że jest on dopracowany, warto na zakończenie wrócić do wymagań biznesowych.

"Wymagania biznesowe" to dumnie brzmiąca nazwa, natomiast są to po prostu pewne założenia w jaki sposób funkcjonalność powinna działać oraz jak wyglądać.

Nie ma znaczenia czy tworzysz kod komercyjny czy na potrzeby własne, ponieważ zawsze są pewne założenia związane z wynikiem Twojej pracy.

W projekcie komercyjnym, będziesz opierał swoje działania na analizie biznesowej oraz na opisie zadania i tzw. kryteriach akceptacji.

Taki opis/dokument pozwoli Ci jednoznacznie stwierdzić czy to co wytworzyłeś pokrywa się z oczekiwaniami.