Typowe zadania programisty Java w projekcie

Jakie są typowe obowiązki programisty Java? W końcu musisz zrozumieć, w co się pakujesz i co ostatecznie zrobisz, prawda? Dzisiaj chciałbym porozmawiać o dziesięciu ważnych zadaniach, które wykonuje programista Java. Ale najpierw zapoznajmy się z narzędziem o nazwie Jira. Lub odśwież sobie pamięć o nim, jeśli już go znasz. Jirajest narzędziem do organizowania interakcji międzyludzkich, choć w niektórych przypadkach jest również wykorzystywane do zarządzania projektami. Innymi słowy, projekt jest podzielony na małe zadania, które są opisane w tym narzędziu. Zadania te przydzielane są programistom, którzy odpowiadają za ich realizację. Zadaniem może być na przykład dodanie jakiejś funkcjonalności. W miarę wykonywania zadania programiści i inni specjaliści dodają komentarze o tym, kto co zrobił i ile czasu poświęcił. Odbywa się to w celu śledzenia czasu — aby wiedzieć, ile czasu poświęcono na jakie zadania. Najlepiej robić to raz dziennie: wieczorem przed odejściem od biurka zaznaczasz, ile z 8 godzin pracy poświęciłeś na różne zadania. Funkcjonalność Jira to znacznie więcej niż to, co opisano powyżej, ale to wystarczy do wstępnego zrozumienia.

1. Projektowanie nowych rozwiązań

Zanim coś stworzysz i wdrożysz, musisz to sobie wyobrazić, prawda? Jak powiedziałem wcześniej, może to być po prostu zadanie w Jira, które zostanie Ci przydzielone, więc pracujesz nad zaprojektowaniem nowego rozwiązania, rejestrując w Jira, ile czasu spędziłeś i na co. Ta praca mogłaby się również odbyć podczas dyskusji na zespołowej telekonferencji: każdy może wyrazić swoją opinię i zaproponować podejście, które uważa za najlepsze. I tutaj chciałbym zwrócić uwagę na kilka punktów. Po pierwsze, tworzenie oprogramowania to bardzo kreatywny zawód, ponieważ trzeba używać standardowych narzędzi, aby wymyślać nowe sposoby rozwiązywania problemów. Jedno zadanie często może mieć wiele różnych rozwiązań. W związku z tym wszystko zależy od kreatywności dewelopera, na którą duży wpływ ma zgromadzona wiedza i doświadczenie. Tutaj możesz wykazać się całą swoją kreatywnością i geniuszem, ale najważniejsze to nie przesadzać. Jeśli to zrobisz, kod stanie się zbyt złożony i nieczytelny. W rezultacie po wyjściu nikt nie będzie w pełni rozumiał, co zakodowałeś i jak to działa. I będą musieli napisać wszystko od nowa. I mogą o tobie wspominać. Więcej niż raz. I jest mało prawdopodobne, że padną ciepłe, miłe słowa. Czy tego potrzebujesz? Po drugie, programista musi zachować elastyczność psychologiczną w tym sensie, że nie należy kurczowo trzymać się jednego rozwiązania i zamykać się na innych. Jakbyś musiał coś zrobić tylko w jeden sposób i nie było innych opcji. Możesz wpaść w tę pułapkę z różnych powodów. Załóżmy na przykład, że chcesz udowodnić, że twój punkt widzenia jest poprawny. A może już zaprojektowałeś i wdrożyłeś swoje własne znane rozwiązanie — oczywiście nie chciałbyś przyznać, że nie jest najlepszy. Te sytuacje mogą sprawić, że będziesz dość ślepy. W rzeczywistości musisz być w stanie przyznać się do błędów i zawsze mieć otwarty umysł, nawet jeśli musisz usunąć funkcjonalność, z której jesteś dumny i kodujesz od ponad tygodnia. Pamiętam, jak jeden ze współpracowników rozjaśnił wszystkim dzień, zostawiając w Jira ten komentarz do śledzenia czasu: „Usunąłem moją martwą cechę. I opłakiwałem”.

2. Pisanie nowych funkcjonalności

Ten krok — wdrożenie nowej funkcjonalności — następuje logicznie po poprzednim. Cała praca związana z projektem jest dzielona w Jira na zadania, które są następnie przydzielane programistom na podstawie ich obciążenia pracą. Istnieją różne podejścia do tego procesu, znane jako „metodologie”, o których można przeczytać bardziej szczegółowo w tym artykule na CodeGym . Z reguły zadania mają oszacowanie, czyli przewidywany czas potrzebny na ich ukończenie. Jest ustalany przez ciebie, programistę, kiedy otrzymujesz zadanie, przez kierownika zespołu lub podczas planowania, wspólnie przez zespół programistów. Tym razem przypuszczenie bardzo rzadko jest trafne, ponieważ tak wiele różnych czynników wpływa na rozwój oprogramowania. Na przykład, czy programista jest zaznajomiony z odpowiednią technologią, czy nie, jego ogólne doświadczenie, różne nieprzewidywalne pułapki itp. Jeśli więc nie osiągniesz wszystkich szacunków czasu podczas kodowania, to nie koniec świata. To tylko ogólne szacunki. To powiedziawszy, nie wszystkie projekty wymagają oszacowania czasu. Osobiście dużo łatwiej mi się bez tego żyje, zwłaszcza gdy premier nie dręczy mnie kilka razy dziennie pytaniem „gdzie są twoje szacunki czasu?” Dostajesz więc zadanieGotowy do przeglądu ” w Jira i módl się, aby zmiany w kodzie nie zostały zwrócone do korekty wraz z komentarzami.

3. Pisanie testów

Recenzentowi, czyli osobie, która sprawdza Twój kod, podoba się zaimplementowana przez Ciebie funkcjonalność, ale ma do Ciebie pytanie: gdzie są powiązane testy? Więc odsyła ci zadanie do sprawdzenia. Testy są istotną częścią każdej aplikacji Java. Uruchamiając testy, możesz od razu zidentyfikować miejsca, w których aplikacja nie działa poprawnie. Na przykład programista wprowadza pewne zmiany w jednej części systemu, co powoduje zmiany w zachowaniu w innej części, ale nie zauważył tego podczas kodowania. Przeprowadzając testy, będzie mógł zobaczyć, że niektóre testy się nie powiodły, co oznacza, że ​​nie dały oczekiwanych wyników. To mówi mu, że coś jest zepsute gdzie indziej w systemie. Wiedząc o tym, nie zatwierdzi przełomowych zmian na serwerze i zamiast tego będzie kontynuował pracę nad debugowaniem swojego kodu. Tak, raczej niewielu programistów lubi pisać testy, ale nie można zaprzeczyć korzyściom, jakie wnoszą do tworzenia oprogramowania. Klienci sami często wskazują poziom pokrycia testowego, jaki chcą utrzymać (np. 80%). To znaczy, że musisz wiedziećróżne rodzaje testów i umieć je napisać. Programiści Java piszą głównie testy jednostkowe i testy integracyjne, podczas gdy bardziej rozbudowane (end-to-end) testy są obsługiwane przez ekspertów ds. kontroli jakości i automatyzacji testów.

4. Znajdowanie i naprawianie błędów

Jest to również bardzo powszechne, częste zadanie programistów Java. Głównym zadaniem ekspertów ds. kontroli jakości i automatyzacji testów jest wyłapywanie błędów. Innymi słowy, szukają miejsc, w których program zachowuje się niepoprawnie, następnie tworzą zadania w Jirze i przydzielają je komuś. Na przykład do lidera zespołu, który z kolei decyduje, do których programistów ich przypisać, w zależności od ich obciążenia pracą i znajomości odpowiednich części systemu. Następnie wyznaczony programista szuka głównej przyczyny błędu, spędzając godziny w debuggerze, korzystając z opisu błędu dostarczonego przez ekspertów ds. kontroli jakości w celu odtworzenia warunków, w których występuje błąd. Gdy programista znajdzie błąd i go naprawi, wysyła poprawkę do sprawdzenia. Czasami programista nie jest w stanie odtworzyć błędu, więc odsyła zadanie do eksperta ds. kontroli jakości wraz z komentarzem wyjaśniającym. Wydaje się, że znalezienie i naprawienie błędu nie powinno zająć dużo czasu, ale są pewne niuanse. Wszystko zależy głównie od tego, jak dobrze programista jest zaznajomiony z tą sekcją kodu oraz od jego doświadczenia i wiedzy teoretycznej. Czasami błąd można znaleźć i naprawić w 20 minut, a czasami może to zająć trzy dni. Oznacza to, że tego typu zadanie jest szczególnie trudne do oszacowania z góry, chyba że programista po przeczytaniu opisu od razu zrozumie, co, gdzie i jak dotyczy błędu. W tym przypadku,

5. Przegląd kodu

Jak wspomniano powyżej, natychmiast po wykonaniu zadania należy je przesłać do sprawdzenia. Jeśli przejdzie przegląd, trafia do głównej gałęzi. Jeśli nie, jest zwracany programiście z komentarzami, którymi należy się zająć. Oczywiście rozumiesz, że twój kod jest sprawdzany przez innych programistów, a nie przez jakąś wielką władzę. To powiedziawszy, nie każdy może przeprowadzać przeglądy kodu — tylko najbardziej doświadczeni programiści, zahartowani w praktyce w świecie rzeczywistym, którzy potrafią odróżnić dobry kod od złego. Przeglądy kodu są zwykle wykonywane przy użyciu narzędzia pomocniczego, takiego jak Crucible. Recenzenci przeglądają kod i, jeśli to konieczne, zostawiają komentarze dotyczące niektórych linii. Mogą być różne rodzaje komentarzy. Na przykład niektóre są krytyczne. Jeśli nie zostaną one rozwiązane, recenzent nie zezwoli na zatwierdzenie kodu. Inne komentarze to, powiedzmy, po prostu uwagi na temat wybranego podejścia. Programista może ich wysłuchać, wziąć pod uwagę lub zignorować. Zespół może stworzyć własne zasady i procedury przeglądu kodu, uzgadniając, na co warto zwrócić uwagę, a na co nie, w jakim czasie należy przeznaczyć na wykonanie przeglądu kodu itp. Samo doświadczenie nie wystarczy do przeprowadzenia przeglądu: nadal musisz bardzo rozwinąć swoje umiejętności techniczne i czytać różne książki (na przykład „Czysty kod”).

6. Analiza kodu

Ponieważ kilka osób, które myślą inaczej, jednocześnie pisze kod dla projektu, ich kod i podejście będą różne. Z biegiem czasu wszystko stopniowo zamienia się w bałagan. Aby ulepszyć kod, czasami tworzone są zadania mające np. przeanalizować określony moduł lub całą aplikację, znaleźć i odnotować niedociągnięcia, a później stworzyć zadanie refaktoryzacji na podstawie tej analizy. Taka analiza pomaga również w sytuacjach, w których na początku rozwoju zespół nie widział prostszych, bardziej zwięzłych rozwiązań, ale widzi je teraz. Na przykład logika jest często powielana w niektórych metodach. W związku z tym można go wyodrębnić do oddzielnej metody, którą można następnie wielokrotnie wykorzystywać. A może klasa stała się zbyt rozdęta, albo jakiś kod stał się trudny do utrzymania lub przestarzały, lub... Zadania analityczne pomagają poprawić jakość kodu i aplikacji. To powiedziawszy, dla mnie analizowanie dużej ilości kodu może być nudne.

7. Refaktoryzacja kodu

Następną częścią analizy kodu jest refaktoryzacja. Kod może być przestarzały, przestarzały, źle napisany, trudny do odczytania i tak dalej. Zawsze należy dążyć do perfekcji (choć jej nie ma) i aktualnego kodu, usuwając wszystko, co zbędne, bo to, co zbędne, wprowadza tylko zamieszanie i przeszkadza w możliwości zobaczenia, co robi kod. Jest rzeczą oczywistą, że mało prawdopodobne jest, aby zobaczyć te zadania na początku projektu: napotykasz je na późniejszych etapach rozwoju, kiedy aplikacja jest dopracowywana i doprowadzana do perfekcji. W tym przypadku właściwe może być skonsultowanie się ze współpracownikami na temat tego, co by zrobili i jakie pułapki widzą. W istocie takie zadania są podobne do opracowywania nowych funkcjonalności. Załóżmy na przykład, że otrzymujesz zadanie edytowania niektórych funkcji bez zmiany ich zachowania. Aby to zrobić, usuwasz stary kod, piszesz własny i sprawdzasz testy. Jeśli zrobiłeś wszystko dobrze, to bez wprowadzania jakichkolwiek zmian w testach, wszystkie powinny przejść tak jak poprzednio. Gdy wszystko w kodzie jest tak, jak powinno być, wysyłamy go do recenzji i idziemy napić się kawy :)

8. Pisanie dokumentacji

Wyobraź sobie, że jesteś nowym programistą w jakimś długoterminowym projekcie rozwoju oprogramowania. Musisz zapoznać się z bazą kodu lub wykonać jakieś konkretne zadanie, na przykład zdiagnozować błąd. Jak będziesz poruszać się po projekcie? Nękać kolegów z drużyny co pięć minut? A jeśli są zajęci lub jest weekend, co wtedy? Właśnie po to mamy dokumentację — aby osoba, która nie zna kodu, mogła wejść, znaleźć odpowiednią stronę i szybko zorientować się, co się dzieje w interesującej ją części aplikacji. Ale ktoś musi stworzyć dokumentację, haha. Jeśli projekt ma dokumentację, którą programiści muszą obsługiwać, to kiedy wdrażają nową funkcjonalność, opisują ją i aktualizują dokumentację wraz z wszelkimi zmianami kodu lub refaktoryzacją. Mogą również wystąpić sytuacje, w których oddzielny pracownik — pisarz techniczny — jest zatrudniony do pisania, utrzymywania i nadzorowania dokumentacji. Jeśli taki specjalista jest dostępny, życie zwykłych programistów jest trochę łatwiejsze.

9. Różne spotkania

Deweloperzy spędzają dużo czasu na różnych spotkaniach, negocjacjach i planowaniu. Najprostszym przykładem jest codzienny stand-up, na którym musisz zdać relację z tego, co robiłeś wczoraj i co będziesz robić dzisiaj. Ponadto będziesz musiał odbywać indywidualne rozmowy telefoniczne, na przykład z testerami, aby mogli zademonstrować/wyjaśnić niuanse odtwarzania błędu lub omówić subtelności i wymagania z analitykiem biznesowym lub porozmawiać o kwestiach organizacyjnych z PMem. Oznacza to, że chociaż programista może być introwertykiem, który preferuje samotność, nadal musi być w stanie znaleźć wspólny język z innymi ludźmi (no, przynajmniej trochę). Im wyższa ranga programisty, tym więcej czasu musi poświęcić na komunikację, a mniej na pisanie kodu. Kierownik programisty może spędzić połowę lub nawet więcej swojego dnia pracy na samych rozmowach i spotkaniach i może rzadziej pisać kod (prawdopodobnie powodując utratę części swoich umiejętności programistycznych). Ale jeśli po prostu lubisz rozmawiać, możesz jako lider zespołu przejść do zarządzania i całkowicie zapomnieć o pisaniu kodu, zamiast tego spędziłbyś cały dzień komunikując się z różnymi zespołami, klientami i innymi menedżerami.

10. Przeprowadzanie/zaliczenie wywiadów

Jeśli pracujesz dla firmy outsourcingowej lub outstaffingowej, często będziesz musiał przejść przez rozmowy zewnętrzne, podczas których będziesz musiał „sprzedać się” klientowi (może Cię przeprowadzić osoba pracująca dla klienta), a także wewnętrzne którzy wspinają się po szczeblach kariery w firmie. Nazwałbym to dobrą okazją do rozwoju, ponieważ częste wywiady zmuszą cię do utrzymywania wiedzy: nie zardzewiejesz i nie zmiękniesz. W końcu, jeśli zmiękniesz w IT, możesz całkowicie wypaść z pola. Gdy staniesz się bardziej doświadczonym programistą, będziesz mógł znaleźć się po drugiej stronie stołu, przeprowadzając rozmowy kwalifikacyjne, a nie zdając je. Uwierz mi, będziesz bardzo zaskoczony, gdy spojrzysz na to z tej pozycji, ponieważ zadawanie pytań na rozmowie kwalifikacyjnej może być bardziej przerażające niż odpowiadanie na nie. Musisz mieć własną strategię rozmowy kwalifikacyjnej, listę pytań i czas, aby zadać pytania na wszystkie niezbędne tematy w ciągu jednej godziny. Następnie jesteś odpowiedzialny za przekazanie informacji zwrotnej, która wpłynie na decyzję o zatrudnieniu i to, czy kandydat otrzyma długo oczekiwaną ofertę lub awans. Lub możesz pozwolić ewidentnie słabej kandydatce na stanowisko, na które się nie kwalifikuje, a następnie możesz zostać zapytany: „jak mogłeś w ogóle pozwolić na zatrudnienie jej z takim poziomem wiedzy”? Tak więc, kiedy siedzisz na gorącym krześle podczas rozmowy kwalifikacyjnej, pamiętaj, że osoba przed tobą również stoi przed wyzwaniem i może być zestresowana. jesteś odpowiedzialny za przekazanie informacji zwrotnej, która wpłynie na decyzję o zatrudnieniu oraz to, czy kandydat otrzyma długo oczekiwaną ofertę lub awans. Lub możesz pozwolić ewidentnie słabej kandydatce na stanowisko, na które się nie kwalifikuje, a następnie możesz zostać zapytany: „jak mogłeś w ogóle pozwolić na zatrudnienie jej z takim poziomem wiedzy”? Tak więc, kiedy siedzisz na gorącym krześle podczas rozmowy kwalifikacyjnej, pamiętaj, że osoba przed tobą również stoi przed wyzwaniem i może być zestresowana. jesteś odpowiedzialny za przekazanie informacji zwrotnej, która wpłynie na decyzję o zatrudnieniu oraz to, czy kandydat otrzyma długo oczekiwaną ofertę lub awans. Lub możesz pozwolić ewidentnie słabej kandydatce na stanowisko, na które się nie kwalifikuje, a następnie możesz zostać zapytany: „jak mogłeś w ogóle pozwolić na zatrudnienie jej z takim poziomem wiedzy”? Tak więc, kiedy siedzisz na gorącym krześle podczas rozmowy kwalifikacyjnej, pamiętaj, że osoba przed tobą również stoi przed wyzwaniem i może być zestresowana. Każda rozmowa kwalifikacyjna jest stresująca zarówno dla kandydata, jak i osoby przeprowadzającej rozmowę. Prawdopodobnie skończymy właśnie tutaj. Dziękuję wszystkim, którzy przeczytali ten artykuł. Zostaw lajka i ucz się dalej Javy :)