Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

19 praktyk naprawdę dobrych programistów

Daniel Anderson Software Development Team Lead / Verastar
Sprawdź, jakie proste praktyki w swojej codziennej pracy stosują naprawdę dobrzy programiści i wprowadź je do swoich zawodowych przyzwyczajeń, aby być lepszym specjalistą.

Rule of 3.

To praktyczna zasada refaktoryzacji kodu, pozwalającą zdecydować, kiedy zreplikowany fragment kodu powinien zostać zastąpiony nowym kodem/procedurami/metodami.

Stwierdza ona, że możesz skopiować i wkleić kod raz, ale gdy ten sam kod jest replikowany trzy razy, powinien zostać wyodrębniony do nowej procedury.

Jej główną koncepcją jest uczynienie kodu/procedur/metod jak najbardziej ogólnymi, aby można było ponownie wykorzystać je w wielu miejscach.


Konsekwencja jest wszystkim

Bądź konsekwentny ze strukturą oraz stylem pisania swojego kodu. Może to pomóc w czytelności i łatwości utrzymywania Twojego projektu.

Spróbuj pracować wg standardów kodowania, które pomagają zachować spójność. Powinien dotyczyć on nawet takich kwestii jak nazewnictwo zmiennych.

Kolejną ważną kwestią jest struktura aplikacji. Powinno być oczywiste, gdzie programista musi wprowadzić zmiany lub dodać coś nowego.


Zredukuj zagnieżdżenia

Dodawanie kolejnych poziomów zagnieżdżenia if'em może bardzo szybko stać się nieczytelne i bardzo trudne do odczytania. Czasami możesz nie być w stanie tego obejść, ale zawsze wcześniej spójrz na strukturę swojego kodu.

To samo dotyczy zagnieżdżania else if. Unikaj tego w kodzie, jeśli to możliwe, ponieważ czasami może to utrudnić jego odczytanie.

Używanie tzw. guard clause to skuteczny sposób, aby w tym pomóc!

Taka klauzula to nic innego jak warunek, który w przypadku spełnienia sprawia, że wychodzimy z funkcji - zwracając wartość lub rzucając wyjątek.

Bez klauzuli ochronnej:

if (account != null)
{
    if (order != null)
    {
        if (order.term == Term.Annually)
        {
            // term annually
        }
        else if (order.term == Term.Monthly)
        {
            // term monthly
        }
        else
        {
            throw new InvalidEnumArgumentException(nameof(term));
        }
    }
    else
    {
        throw new ArgumentNullException(nameof(subscription));
    }
}


Z
klauzulą ochronną:

if (account == null)
{
        throw new ArgumentNullException(nameof(account));
}
if (order == null)
{
    throw new ArgumentNullException(nameof(order));
}
if (order.term == Term.Annually)
{
    // term annually (return here)
}
if (order.term == Term.Monthly)
{
    // term monthly (return here)
}
throw new InvalidEnumArgumentException(nameof(order.term));


Myśl w szerszej perspektywie

Rozumienie szerokiego kontekstu ułatwia śledzenie mniejszych szczegółów. Gdy zrozumiesz całość, ustalenie małego szczegółu nie zajmie Ci zbyt dużo czasu.


Poświęć trochę czasu na nazywanie rzeczy

Nazywanie rzeczy w kodowaniu jest jedną z najtrudniejszych rzeczy. Może to być nazywanie klasy, metody lub nawet zmiennej. Świetni programiści poświęcają czas na myślenie o odpowiednich nazwach, ponieważ wiedzą, że pomaga to w czytelności kodu.


Unikaj długu technicznego

Może w tym pomóc przeszacowanie. Lepiej spędzić więcej czasu na porządne napisanie czegoś, w przeciwnym razie wrócisz w to miejsce jeszcze wielokrotnie.

Dla początkujących - dług techniczny to koncepcja w rozwoju oprogramowania, która odzwierciedla domniemany koszt dodatkowej pracy związanej z wyborem łatwego (ograniczonego) rozwiązania teraz, zamiast stosowania lepszego podejścia, które zajęłoby więcej czasu.


Estymuj z zapasem

Może to być dziwne i w zależności od tego, w jakim dziale pracujesz, ten punkt może Ci się nie podobać. Wiedz jednak, że naprawdę dobrzy programiści przeszacowują swoje zadania, ponieważ wiedzą, że rzeczy zawsze trwają dłużej niż się spodziewamy. Dodanie bufora podczas estymacji może naprawdę pomóc Ci dowozić rzeczy dobre i na czas.

Może to naprawdę pomóc w przypadku poprzedniego punktu. Jeśli oszacujesz czas, który uwzględnia tylko naprostszy scenariusz lub dasz go sobie za mało nawet na podstawy, możesz doprowadzić do powstania długu technicznego.


Dokumentuj i komentuj

Pomagają one zachować kontekst i dzielić się wiedzą. Doświadczeni programiści potrafią odrzucić w trakcie code review kod bez komentarzy i dokumentacji, bez żadnego sprawdzania.


Śmiało usuwaj zły kod

Jest sporo niepewnych siebie programistów, którzy komentują ogromne bloki kodu i zostawiają to w tej formie. Kontrola wersji ma swój cel! Wielcy programiści nie boją się usuwania złych części aplikacji.


Poświęcaj czas na code review

Dobrzy programiści spędzą więcej czasu na code review, gdyż wiedzą, jakie to ma znaczenie.

  • Pomaga to w szybszym znajdowaniu błędów
  • Poprawia umiejętności programistyczne i pokazuje reszcie zespołu dobre praktyki.
  • Umożliwia dzielenie się wiedzą
  • Prowadzi do uspójnienia projektu i implementacji


Najlepszy proces code review, z jakim miałem do czynienia, to:

  • Małe zadanie z niewielkim ryzykiem powinno zostać sprawdzone przez programistę samodzielnie
  • Średnia, duża lub ryzykowna zmiana powinna zostać sprawdzona przez trzech programistów, z których jeden jest seniorem. Każdy przy swoim biurku.
  • Bardzo ryzykowna zmiana lub nowa część tworzonej aplikacji powinna mieć zarezerwowane spotkanie i trzech programistów, z których przynajmniej jeden jest głównym deweloperem, by przejść wspólnie przez każdą linię, wyciągając wspólne wnioski.


Pisz dobre testy

Zauważ, że bardziej doświadczeni i lepsi programiści poświęcają więcej czasu na pisanie dobrych testów. Pomagają one skalować aplikację z większą pewnością i zmniejszają liczbę błędów na produkcji.


Poświęć czas na projektowanie

Dobrzy programiści, zanim zagłębią się w kod, zastanawiają się i dzielą go na małe kawałki. Pomaga im to lepiej przygotować się na to, jak wszystko do siebie spasować i stworzyć bardziej przejrzysty kod.


Skoncentruj się na podstawach, nie na składni

To ważny punkt! Świetni programiści lubią zgłębiać podstawy, nie skupiając się nadmiernie na składni. Pomaga im to skuteczniej znajdować problemy. Może to również pomóc im googlować problemy z lepszym zrozumieniem.


Zaprzyjaźnij się z Googlem

Dobry programista jest ekspertem od wyszukiwania w Google. Ponieważ skupia się na podstawach, wie, jakich terminów Google szukać. Jest to trudne, jeśli nadal masz obsesję na punkcie nauki składni!


Upewnij się, że działa, upiększaj później

W przypadku słabszych programistów da się zauważyć, że spędzają oni sporo czasu na tym, aby kod ładnie się prezentował, żeby wkrótce dowiedzieć się, że nie działa on tak jak należy.

Dobrzy programiści działają na odwrót. Wcześnie identyfikują wszelkie problemy, zanim napiszą wszystko ładnie. Pomaga to w sprawniejszej realizacji projektów.


Zarządzaj ryzykiem i rozwiązuj problemy

Seniorzy potrafią zdefiniować ryzyko, upraszczać złożone problemy poprzez stosowanie wzorców projektowych i mogą samodzielnie rozwiązywać różne problemy na bazie wcześniejszych doświadczeń.


Pytaj

Dobrzy programiści chcą wiedzieć wszystko. Nie mają nic przeciwko zadawaniu pytań, nawet jeśli brzmią one niezwykle prosto. Mogą to być pytania techniczne lub biznesowe. Zrozumienie potrzeb biznesowych pomaga im tworzyć lepszy kod. Nie boją się zadawać pytań, ponieważ są pewni swoich umiejętności.


Jeśli to możliwe, nie loguj się do bazy danych

(Ten punkt zależy od typu aplikacji, którą tworzysz i tylko wtedy, gdy nie ma to wpływu na wydajność.)

Doświadczeni koderzy wiedzą, że ich zapytania bazy danych są wykonywane w prostych operacjach CRUD.

Twórz, czytaj (czyli odzyskuj), aktualizuj i usuwaj.

Następnie warstwa logiki biznesowej powinna to wszystko połączyć. Pomaga to programistom rozumieć, gdzie szukać logiki biznesowej. Może się to bardzo szybko skomplikować, jeśli masz logikę w zapytaniach do bazy danych i w kodzie!

KISS

Keep It simple Stupid

Doświadczeni programiści wiedzą, że najlepszym rozwiązaniem jest prosty kod. Nawet jeśli oznacza to czasami tworzenie większej ilości linii kodów. Wielu słabszych programistów tworzy “jednoliniowce”, jak poniżej.

return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];


To często działa, ale czytanie tego jest trudne!


Podsumowanie

To moje obserwacje z codziennej pracy świetnych programistów. Wiele z nich nie dotyczy samego kodowania, ale procesu i sposobu, w jaki podchodzą do zadań. Jestem pewien, że do tej listy można dodać znacznie więcej.

Napisz w komentarzu, czym Ty kierujesz się, dążąc do doskonałości w kodowaniu :)



Oryginał tekstu w jezyku angielskim przeczytasz tutaj.

2 komentarzy

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej