Elementy pracy programisty

We wpisach, które już pojawiły się na blogu omówiliśmy kilka tematów. Część z nich można by hucznie określić filozofią pracy programisty. Zastanawialiśmy się jakie cechy powinno się mieć, aspirując na to stanowisko i o tym jakimi ścieżkami kariery można podążyć. Dzisiejszy wpis jest kontynuacją serii, a skupię się w nim na stałych elementach pracy kodera. Zaczynamy.

Na samym początku małe wyjaśnienie. Jak zapewne się domyślasz, nasza praca jest bardzo zróżnicowana. Może to zależeć od firmy, klienta, konkretnego projektu, naszego doświadczenia
i wielu innych czynników. Proszę, miej więc na uwadze, że poniższe opisy mogą tylko częściowo pokrywać się z rzeczywistością, z którą będzie Ci dane się mierzyć. Jeśli to jest jasne, to przejdźmy do meritum 🙂

Programowanie nowych funkcjonalności

programowanie

Nazwa mówi sama za siebie. Musisz rozbudować istniejący system zgodnie z dokumentacją
i założeniami projektu. Wymaga to kreatywnego podejścia do rozwiązywania problemów i daje wiele satysfakcji. W tego typu zadaniach masz też duże możliwości technicznego rozwoju. Ponieważ odpowiadasz za swój kod, spełnianie wymagań to tylko niezbędne minimum. Powinien on być czytelny, schludny, zgodny z przyjętymi standardami oraz zasadami dobrego programowania. Młodszym doświadczeniem w osiągnięciu tych celów, zazwyczaj pomagają ci starsi stażem.

Optymalizacja/ refactoring

Zostając w temacie stricte programowania natrafiamy na drugi typ zadania jakie może zostać
Ci powierzone. W skrócie polega ono na przypisaniu działającej części systemu, na wersję, która jest jednym słowem lepsza. Pisząc to mam na myśli zastąpienie kodu wykonującego się zbyt wolno, napisanego niechlujnie lub trudnego w analizie i utrzymaniu. W przypadku takiej pracy kluczowe jest zrozumienie części programu przeznaczonej do poprawy oraz znalezienie sposobu na jej optymalizację.

Poprawianie bugów

W dużej mierze przypomina poprzedni akapit. Zdecydowałem się na rozdzielenie ich ze względu
na to, że zanim poprawimy błąd, najpierw musimy go zlokalizować. Może to zrobić sam programista, tester, klient czy użytkownik aplikacji. Często bywa tak, że jest to proces bardzo karkołomny, wymagający nałożenia się wielu czynników, a co najgorsze trudny do odtworzenia w momencie poprawiania. Jednak gdy to zadanie mamy już za sobą, praca właściwa- czyli naprawa błędu odbywa się podobnie jak refactoring, z tą różnicą, że musimy tutaj usunąć defektywny kod.

Pisanie testów

pisanie testow

Każda aplikacja powinna zawierać testy jednostkowe. Pomagają one zweryfikować poprawność działania systemu i minimalizują ryzyko oddania projektu z błędami. Osobą odpowiedzialną za ich pisanie jest programista. To zadanie także wymaga zrozumienia testowanej funkcjonalności oraz przewidzenia przypadków jakie mogą wystąpić. To często na tym etapie udaje się znaleźć błędy opisane wyżej. Jest to więc odpowiedzialne zajęcie, które może uratować w wielu sytuacjach.

 

Kontakty z klientem

spotkanie

To do niego należy ostatnia decyzja na temat każdej sprawy. To on płaci za Twoją pracę. I to on jest właścicielem oprogramowania, które tworzysz. Nic więc dziwnego, że nie jeden raz będziesz się z nim kontaktować. Zależnie od wielkości biznesu możesz mieć styczność z samym prezesem lub jednym
z przełożonych, np. dyrektorem IT. Takie kontakty można podzielić na trzy rodzaje:

  1. Wymiana e-maili/wiadomości – zwykle wykorzystywana do uzyskania szybkiej odpowiedzi
    na drobne pytania, jak i do ustalenia ważnych spraw
  2. Wideorozmowy – służą do omawiania większych tematów, jak np. prezentacja postępu prac nad powierzonym zadaniem, dyskusja nad przyszłością współpracy, czy rozdzielenie obowiązków. Generalnie jest to sposób na przekazanie większej ilości informacji niż mail w jak najkrótszej ilości czasu.
  3. Spotkania na żywo – najciekawszy rodzaj kontaktów. Pozwala poznać bliżej klienta oraz jego biznes, a co za tym idzie – potrzeby. Służy też budowaniu relacji oraz dyskusji na ważne tematy twarzą w twarz. Dodatkowym atutem jest sama podróż i jej wartość poznawcza. Zależnie od klienta możesz mieć okazje zwiedzić wiele krajów i chociaż przez chwilę mieć możliwość obcowania z ich kulturą. Jest to też szansa na podszlifowanie języka obcego używanego w codziennych rozmowach.

rozmowa telefoniczna

Code review

Jest to proces weryfikacji oddanego zadania pod kątem poprawności oraz jakości kodu. Zależnie
od Twojego doświadczenia i wiedzy o projekcie możesz zarówno być sprawdzanym,
jak i sprawdzającym.

Gdy Twój kod jest oceniany pamiętaj, aby nie traktować go jako rozwiązania idealnego. Zawsze zakładaj, że ktoś może mieć inny lub lepszy pomysł. Nie ma w tym nic złego! Trzeba wykazać się jednak odrobiną pokory, żeby to zaakceptować i poprawić kod – o ile zgadzasz się z opinią oceniającego. Krótka, a konstruktywna dyskusja zawsze jest wskazana. Pomoże obu stronom zrozumieć odmienne punkty widzenia.

Sprawdzający powinien natomiast przede wszystkim być obiektywny. Oceniać rozwiązanie niezależnie od autora i unikać komentarzy uderzających bezpośrednio w jego osobę. Częstym błędem jest także ocenianie jedynie wizualnej strony kodu, bez skupienia się na tym, czy rozwiązuje on problem! To właśnie powinien być najważniejszy cel code review. W kolejnym kroku można przejrzeć testy, sprawdzić czy kod wykonuje się optymalnie, a dopiero na końcu weryfikować wygląd kodu, zastosowane wzorce, itp.

Weryfikowanie rozwiązań może być szansą rozwoju dla obu stron, o ile będzie odbywało się
w atmosferze wzajemnego szacunku.

Analiza systemu

analiza systemu

Programiści często pracują nad wcześniej powstałymi systemami. Może to być praca polegająca
na ich utrzymaniu, usuwaniu błędów lub przepisywaniem platformy od zera. W każdym z przypadków kluczowe jest poznanie i dogłębne zrozumienia poprzedniej wersji. W przypadku starszych rozwiązań może to być zadanie karkołomne, pisane są one często w sposób nieuporządkowany i trudny do zrozumienia. Problemy rozwiązywane są nie za pomocą złożonych mechanizmów języka, znacznie upraszczających zapis, a prostych obejść (tzw. workaround), które po czasie są trudne do analizy
i utrzymania. Wprowadzenie małych zmian w takim kodzie może wymagać długiego planowania
i analizowania.

Pisanie/czytanie dokumentacji

pisanie dokumentacji

Dobre oprogramowanie powinno posiadać też dokumentację, opisującą wszystkie funkcje
i możliwości systemu oraz wyjaśniającą zastosowane algorytmy i praktyki kodowania. Oczywiście nie jest to twór stworzony raz na zawsze. Ciągle rozwijany projekt potrzebuje częstych aktualizacji swojej dokumentacji. Pomaga to nowym członkom zespołu wdrożyć się w projekt, a korzystającym
z aplikacji poznać jej możliwości. Zwykle pisana jest w języku angielskim. Pracując jako programista, jednym z Twoich zadań będzie rozwijanie opisu projektu. Niejednokrotnie też będziesz tam sięgał, aby zdobyć brakującą wiedzę.

Projektowanie nowych funkcjonalności

Bardziej doświadczonym developerom może zostać powierzone zadanie zaprojektowania nowej funkcjonalności. Wymaga ono pogodzenia wymagań biznesowych projektu oraz „przetłumaczenie” ich na algorytm, który można wyrazić w języku programowania. Potrzebna jest tutaj duża znajomość projektu i holistyczne podejście do problemu, który trzeba rozwiązać. To zadanie zwykle połączone jest z tworzeniem dokumentacji i analizą systemu.

Estymacja

W największym uproszczeniu jest to szacowanie, ile czasu potrzebujesz na wykonanie odpowiedniego zadania. Podejście do niej może być różne w każdym projekcie. Czasami bywa z góry narzucona przez klienta lub traktowana jako niezobowiązująca deklaracja. Bywają też przypadki skrupulatnego podejścia do estymacji. Jest wiele sposobów i technik pozwalających na zwiększenie jej dokładności, np. estymacja czasowa, punktowa, itp. Wybór jednej z nich zależy od projektantów systemu, project managera, a czasem od klienta.

Prowadzenie rozmów rekrutacyjnych

rekrutacja

Bardziej doświadczeni developerzy mogą zostać wytypowani do przeprowadzania rozmów technicznych z kandydatami na pracowników. Wymaga to dużej wiedzy własnej oraz wnikliwego ocenienia umiejętności osoby siedzącej po drugiej stronie stołu. Nikt nie chciałby przyjąć nieodpowiedniego kandydata na jakieś stanowisko, a co gorsza do projektu, w którym się pracuje. Z drugiej strony osoba prowadząca powinna wykazać się zrozumieniem i szacunkiem do rekrutowanego. Wypadałoby też dobrać rozsądne pytania dla kandydatów z odpowiednim doświadczeniem. Nie wypada przecież pytać seniora, czym jest klasa prawda?

Wdrażanie nowych członków zespołu

Wraz ze wzrostem Twojego doświadczenia w projekcie, będziesz zdobywał nową wiedzę o systemie oraz jego głębsze zrozumienie. Co za tym idzie, powierzane Ci będą coraz bardziej odpowiedzialne zadania. Mogą one dotyczyć wyzwań stricte programistycznych, ale te już omówiliśmy. Innym typem obowiązków może być wdrożenie nowych członków do zespołu. W takim przypadku, na Twoich barkach spoczywa odpowiedzialność przekazania im swoich umiejętności, stosowanych praktyk, czy konwencji, przedstawienie używanych narzędzi, czy coś od czego powinieneś zacząć – celu projektu oraz domeny biznesowej klienta. Dobrze przeprowadzone wdrożenie pozwala łatwiej zintegrować się z zespołem i zacząć pracować nad powierzonymi zadaniami. Należy pamiętać, że do każdego człowieka trzeba podchodzić inaczej. W swojej karierze spotkasz wiele osób o różnym charakterze, światopoglądzie czy nastawieniu do życia. Trzeba mieć to na uwadze, żeby dostosować podejście do takiej osoby.

Dzielenie się wiedzą

Wiele firm praktykuje podejście wymiany doświadczenia między pracownikami. Pozwala ona na poznanie lub przybliżenie np. nowej technologii, frameworka, czy narzędzia. Daje to możliwości rozwoju wszystkim zainteresowanym, przy jednoczesnym obniżeniu czasu potrzebnego na wstępne zapoznanie się z tematem- tym zajmuje się osoba prowadząca np. szkolenie, bo dzielenie się wiedzą zwykle przybiera formę szkolenia właśnie. Bywa też, że takie spotkanie wychodzi poza mury firmy
i jest przeprowadzane na różnych meet-upach grup programistycznych. Udział w takich wydarzeniach w roli prelegenta pozwala rozwinąć swoje umiejętności mówcy oraz budować swój wizerunek
w lokalnych społecznościach developerów.

Nauka

nauka

Opuszczając mury firmy dobry programista nie powinien od razu zaczynać od relaksu. Wiedza
w naszej branży bardzo szybko się dezaktualizuje. Jeżeli pracownik nadal chce pozostać konkurencyjny na rynku pracy musi ciągle poszerzać swoje horyzonty. Jest na to kilka możliwości. Pierwszą i najbardziej powszechną jest wykorzystanie do tego swojego wolnego czasu. Po pracy,
a niektórzy przed możesz poświęcić chwilę na naukę języka, frameworka lub np. dobrych praktyk programowania. Często firmy, w których pracujemy oferują część czasu pracy do dowolnego wykorzystania przez programistów – wtedy też możesz wiele zrobić. Innym ciekawym sposobem zdobywania wiedzy jest udział w konferencjach i tutaj podobnie – za bilet zwykle płacić będziesz sam, jednak częstą praktyką jest, co najmniej częściowe, dofinansowanie od firmy.

Kawa

kawa

Jestem pewien, że tytuł tego akapitu Cię zdziwił. Nie od dzisiaj jednak wiadomo, że spotkania przy kawie to codzienny element pracy niejednego programisty, który stał się, można powiedzieć, ikoną i cechą charakterystyczną branży IT.

Powyżej przedstawiłem główne zajęcia programisty. Tak jak wspominałem na początku, nie są to elementy stałe. Każda firma posiada swoją kulturę pracy, a projekt- specyfikę. Dlatego są raczej małe szanse, że będziesz miał okazję doświadczać wszystkich na raz. Nie mniej jednak opisałem te, dotykające najważniejszych aspektów- zadań technicznych, miękkich oraz dotyczących własnego rozwoju. Czy o czymś zapomniałem? Jeśli tak to koniecznie napisz mi o tym w komentarzu.

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.