Przerwa kawowa nr 13: Co powinien wiedzieć każdy nowicjusz w programowaniu; 4 sposoby włączenia myślenia projektowego do procesu rozwoju

Co powinien wiedzieć każdy początkujący programista

Źródło: Stackoverflow Jako programista usłyszysz wiele różnych teorii na temat tego, jak powinien wyglądać kod. Niektórzy uważają, że im mniej linii kodu ma aplikacja, tym łatwiej jest ją przeczytać. Ale to tylko częściowo prawda. Wolę oceniać jakość kodu za pomocą następujących kryteriów:

1. Kod powinien być spójny, informacyjny i dobrze udokumentowany.
2. Kod powinien wykorzystywać stabilne, nowoczesne funkcje.
3. Kod nie powinien być niepotrzebnie skomplikowany ani uszkodzony.

Jeśli zdecydujesz się zmniejszyć liczbę linii kodu kosztem jednego z powyższych kryteriów, stanie się to problemem. Nie rób tego.

Czytanie cudzego kodu jest trudne

Rzeczywiście, stosunek czasu spędzonego na czytaniu i pisaniu kodu jest większy niż 10 do 1. Ale nie można obejść się bez czytania kodu innych osób. Będziesz musiał przeczytać kod innej osoby. Im szybciej udoskonalisz swoje umiejętności, tym lepiej. Spróbuj przestudiować kod innych osób, korzystając z otwartych repozytoriów GitHub. Możesz ćwiczyć w dowolnym momencie: po prostu znajdź projekt, który Ci odpowiada i zagłębij się w każdą linijkę. Innym sposobem na poprawę umiejętności czytania kodu innych osób jest rozpoczęcie kopiowania stylu. Kiedy piszesz kod w stylu kogoś innego, nie tylko poprawia to twoje umiejętności czytania, ale także sprawia, że ​​kod jest dla ciebie bardziej znajomy. Spróbuj.

Nigdy nie napiszesz „idealnego” kodu

Przez cztery lata pracowałem jako samodzielny programista, zanim zacząłem pracować w zespole. Przez większość tego czasu wierzyłem, że każdy doświadczony programista napisał doskonały kod. Moim zdaniem nauczenie się pisania idealnego kodu to tylko kwestia czasu i wysiłku. Ale kiedy dołączyłem do zespołu, stało się jasne, że nikt nie pisze „idealnego” kodu. To prawda, że ​​kod ostatecznie włączany do systemu był prawie zawsze „idealny”. Dlaczego się to stało? Wszystko zależy od analizy kodu. Pracuję z zespołem naprawdę genialnych inżynierów. To jedni z najbardziej kompetentnych i pewnych siebie programistów, jakich można zatrudnić za pieniądze. Ale każdy z nich (łącznie ze mną) dostałby prawdziwego ataku paniki, gdyby ktoś kiedykolwiek zasugerował umieszczenie w aplikacji nieprzetestowanego kodu. Nawet jeśli myślisz, że jesteś kolejnym Billem Gatesem, będziesz popełniać błędy. Nie mówię nawet o błędach logicznych, mówię o literówkach, brakujących znakach. Rzeczy, których Twój mózg czasami po prostu nie łapie. Rzeczy, które można dostrzec jedynie świeżym okiem. Staraj się współpracować z ludźmi, którzy zwracają uwagę na szczegóły i są chętni do krytyki Twojej pracy. Na początku będzie trudno przyjąć krytykę, ale jest to jedyny niezawodny sposób na poprawę jakości kodu. Staraj się nie przyjmować defensywy podczas przeglądania kodu i nigdy nie traktuj krytyki osobiście. Nie jesteś swoim kodem.

Nie powinieneś pisać kodu 8 godzin dziennie

Nikt nie może dokładnie powiedzieć, ile czasu dziennie spędza na pisaniu kodu. Ale w rzeczywistości niewiele osób pisze kod dłużej niż 4 godziny dziennie. Osoby, które się z tym nie zgadzają, stanowią albo wyjątek od reguły, albo pracują w firmach, które źle traktują swoich pracowników. Programowanie to intensywna i wyczerpująca psychicznie praca. Całkowicie błędne jest myślenie, że ktoś będzie pisał kod 8 godzin dziennie, 5 dni w tygodniu. W rzadkich przypadkach konieczne będzie dotrzymanie terminu, ale mówiąc rzadko, mam na myśli prawie nigdy. Nie pozwól, aby praca Cię przytłaczała i zmuszała do pracy w godzinach nadliczbowych. Nie sugeruję, że masz pracować tylko cztery godziny dziennie. Pozostałe cztery godziny najlepiej przeznaczyć na takie rzeczy jak:

• nauka nowych narzędzi, funkcji, aplikacji;
• omawianie procesów pracy ze współpracownikami;
• pomoc kolegom, którzy mają trudności w pracy;
• planowanie zadań;
• analiza kodu;
• spotkania biznesowe/spotkania.

Gorąco polecam również robienie regularnych przerw w ciągu dnia i ćwiczenia (przynajmniej trochę). Pozytywne skutki ćwiczeń zostały udowodnione już dawno.

4 sposoby włączenia myślenia projektowego do procesu rozwoju

Source Tech Beacon Aby stworzyć produkt spełniający potrzeby Twoich klientów, musisz rozważyć, czego chcą. Jeśli napisałeś aplikację z mylącą nawigacją lub niepotrzebnie długim interfejsem ładowania, przygotuj się na przyszłe niepowodzenia. Jako programista być może będziesz musiał głębiej zagłębić się w projekt produktu, nad którym pracuje Twój zespół. Ten rodzaj współpracy jest bardzo przydatny, ponieważ każda osoba zauważa rzeczy, których druga osoba może nie zauważyć. Mam dla Ciebie 4 wskazówki, jak programista i projektant mogą współpracować.

1. Zaangażuj się od samego początku

Nie zakładaj, że projekt zawsze jest na pierwszym miejscu, a rozwój na drugim miejscu. Może to być prawdą, ale nie oznacza to, że programiści nie powinni być zaangażowani w proces projektowania. Programista jest w stanie dostarczyć ważnych informacji technicznych na temat możliwości realizacji projektu, a projektanci lepiej rozumieją pragnienia użytkowników. Lepiej jak najwcześniej dowiedzieć się, która funkcja jest technicznie niemożliwa lub nie spełnia wymagań użytkownika. Jeśli projektanci i programiści współpracują, problemy można wykryć i rozwiązać natychmiast, a nie po zatwierdzeniu projektu. Wiele firm stosuje podejście oparte na współpracy przy tworzeniu oprogramowania. Oznacza to, że członkowie zespołu są odpowiedzialni nie tylko za swój własny etap lub fragment kodu, ale biorą zbiorową odpowiedzialność za wszystko, od projektu po testowanie.

2. Poznaj proces UX

Osoby niezaznajomione z UX (doświadczenie użytkownika) mogą nie zrozumieć, dlaczego zespoły ciągle zmieniają projekty ze względu na pozornie drobne szczegóły. Każdy etap procesu UX ma jeden cel: zapewnić użytkownikowi jak najlepsze doświadczenia. Dlatego warto od samego początku zwrócić uwagę na stworzenie procesu UX. Może obejmować:

• zbadanie celu projektu;
• tworzenie modelu szkieletowego - prosty projekt, który pozwala określić główne cechy produktu;
• dodawanie drobniejszych szczegółów do projektu projektu, takich jak interfejs użytkownika;
• testowanie projektów przez użytkowników. To chyba najważniejszy etap rozwoju UX. Dostarcza to cennych informacji o produkcie, zanim poświęcisz czas na jego opracowanie;
• Iteracja: korzystając z analizy wyników testów, wykonaj iterację projektu, aby poprawić wygodę użytkownika.

Zespoły powtarzają etapy projektowania i testowania kilka razy, aż nie pozostaną żadne zmiany lub dopóki czas na to pozwoli. Zwykle oznacza to, że będziesz mieć wiele wersji projektu.

3. Śledź rozwój projektu

Bardzo źle jest, gdy projektanci tworzą projekt bez konsultacji z programistami. To przynosi efekt przeciwny do zamierzonego. Dla DevOps ważne jest ustalenie reguł, aby programiści mieli dostęp do planów projektowych w łatwo dostępnych formatach, takich jak PNG lub PDF. Efektywna współpraca pomiędzy programistami i projektantami ma kluczowe znaczenie dla pomyślnego wdrożenia aplikacji. Za wszelką cenę unikaj ślepego przekazywania gotowego projektu. Lepiej naprawić błąd na początku niż na końcu.

4. Uzgodnij, na jakim etapie projekt zostanie Ci pokazany

Kiedy programiści proszeni są o stworzenie minimalnej wersji produktu (MVP), muszą od samego początku znać wymagania dotyczące wersji ostatecznej. Jest to konieczne, aby uniknąć problemów związanych z nieuzasadnionymi oczekiwaniami. Projektanci muszą pokazać deweloperowi obie wersje projektu: zarówno MVP, jak i wersję ostateczną. Pomoże to wdrożyć MVP, biorąc pod uwagę to, czego klient oczekuje w wersji finalnej. Kiedy projektanci i programiści współpracują ze sobą, zyskują wiele korzyści. Każdy z nich posiada wiedzę, którą można zastosować w doświadczeniach drugiego. Programiści mogą zapewnić cenny wgląd w to, jakich funkcji nie można zaimplementować w projekcie. Z drugiej strony współpraca z programistą odciąży projektanta od konieczności przerabiania projektu, co w konsekwencji pozwoli zaoszczędzić czas całego zespołu.