Jakie są typowe obowiązki programisty Java? W końcu musisz zrozumieć, do czego dążysz i co ostatecznie zrobisz, prawda? Dzisiaj chciałbym porozmawiać o dziesięciu głównych zadaniach, jakie wykonuje programista Java. Ale najpierw zapoznajmy się z narzędziem takim jak Jira. Albo odświeżmy naszą pamięć, jeśli jest Ci już znana. Jira to narzędzie interakcji z użytkownikiem, choć w niektórych przypadkach wykorzystywane jest także do zarządzania projektami. Innymi słowy, rozwój projektu jest podzielony na małe zadania opisane w tym narzędziu. Zadania te są przydzielane (przydzielane) programistom, którzy będą odpowiedzialni za ich realizację. Przez zadania rozumiemy na przykład dodanie jakiejś funkcjonalności. W miarę postępu programiści i inni specjaliści dodają komentarze na temat tego, kto co zrobił i ile czasu spędził – śledzą czas. Odbywa się to w celu śledzenia spędzonego czasu: ile i na co wydano. Idealnie jest to robić raz dziennie: wieczorem przed wyjazdem odliczasz swoje 8 godzin do zadań, na które je poświęciłeś. Funkcjonalność Jira jest znacznie szersza niż opisana powyżej, ale to wystarczy do wstępnego zrozumienia. Jakie są więc obowiązki programisty Java?
1. Opracowywanie nowych rozwiązań
Zanim coś stworzysz i wdrożysz, musisz to wymyślić, prawda? Jak mówiłem, może to być tak proste, jak zadanie w Jira , które zostanie Ci przydzielone, a Ty będziesz pracować nad opracowaniem nowego rozwiązania, notując w Jira, ile czasu i na czym spędziłeś. Może to być również dyskusja w ramach grupowej rozmowy zespołowej: każdy będzie mógł wyrazić swoją opinię i zaproponować podejście, które uważa za najlepsze. I tutaj chciałbym zwrócić uwagę na kilka kwestii. Po pierwsze, zawód programisty to bardzo kreatywna dziedzina, ponieważ trzeba wymyślać unikalne sposoby rozwiązywania problemów przy użyciu standardowych narzędzi. Często jeden problem może mieć wiele różnych rozwiązań: w związku z tym wszystko zależy od „ducha twórczego” programisty, zgromadzonej bazy wiedzy i doświadczenia. Tutaj możesz pokazać całą swoją kreatywność i geniusz, ale najważniejsze, żeby nie przesadzić: w tym przypadku kod stanie się zbyt skomplikowany i nieczytelny, w wyniku czego po wyjściu nikt w pełni nie zrozumie, co to jest i jak to działa. I będziesz musiał napisać wszystko od nowa. I mogą cię pamiętać. I więcej niż raz. I raczej nie będą to ciepłe, miłe słowa. Potrzebujesz tego? Po drugie, programista musi być elastyczny w tym sensie, aby nie utknąć w jednym rozwiązaniu i zamknąć się na inne. Musisz zrobić tylko w ten sposób i nic innego. Może się to zdarzyć z różnych powodów: na przykład chcesz udowodnić swój punkt widzenia, albo opracowałeś i wdrożyłeś już swoje rozwiązanie, do którego jesteś dość przywiązany i oczywiście nie chcesz się przyznać, że to nie jest to to, co najlepsze. To może cię całkiem oślepić. Tak naprawdę trzeba umieć przyznać się do błędów i zawsze być otwartym na nowe rzeczy („otwarty”), nawet jeśli trzeba będzie usunąć funkcjonalność, o której pisałeś od wielu tygodni i z której jesteś bardzo dumny. Pamiętam, jak kiedyś nastrój na cały dzień robił czyjś licznik czasu w Jirze z komentarzem: „Usunąłem funkcjonalność martwego dziecka. płakałam”
2. Napisanie nowej funkcjonalności
Jest to logiczny krok po poprzednim – wdrożenie nowej funkcjonalności. Cała praca nad projektem jest podzielona na zadania w jira, które programiści otrzymują w trakcie pracy. Istnieją różne podejścia do tego zagadnienia - „metodologie”, o których więcej przeczytasz w tym artykule na JavaRush . Z reguły zadania mają „Oszacowanie” - przewidywany czas spędzony na ich ukończeniu. Jest on ustalany przez Ciebie, gdy podejmujesz się zadania, lub przez kierownika zespołu, albo podczas planowania programiści wspólnie go szacują. Czas ten bardzo rzadko jest dokładnie odgadywany, ponieważ na rozwój wpływa wiele różnych czynników. Na przykład, czy programista jest zaznajomiony z tą technologią, czy nie, jakie jest jego ogólne doświadczenie, różne pułapki, które mogą ujawnić się już w trakcie programowania itp. Dlatego jeśli nie dotrzymasz tego terminu przy opracowywaniu funkcjonalności, nic złego się nie stanie. To tylko ogólne szacunki. Ale znowu, nie wszystkie projekty mają kosztorysy zadań i jak dla mnie dużo łatwiej się bez niego obyć, zwłaszcza gdy PM nie wpycha Cię w bok kilka razy dziennie pytaniem „Gdzie są kosztorysy? ” W związku z tym bierzesz zadanie, rozwijasz niezbędną funkcjonalność, przesyłasz je do wspólnej gałęzi w GIT , a w jira zmieniasz status zadania na „Gotowe do przeglądu” , czyli gotowe do przeglądania (sprawdzania) i modlisz się, aby nie jest on zwracany wraz z komentarzami dotyczącymi rewizji.
3. Pisanie testów funkcjonalności
Osobie sprawdzającej Twój kod – recenzentowi – spodobała się opracowana przez Ciebie funkcjonalność, ale ma pytanie: gdzie są do niej testy? I zwraca ci zadanie do powtórki. Testy są ważną częścią każdej aplikacji Java. Uruchamiając je, można od razu wychwycić, gdzie aplikacja działa nieprawidłowo. Na przykład programista wprowadził pewne zmiany w jednej części systemu, co doprowadziło do zmian w zachowaniu w innej i nie zauważył tego podczas programowania. Uruchamiając testy, będzie mógł zobaczyć nieudane (te, które nie działały poprawnie) testy. To powie mu, że coś jest uszkodzone w innej części systemu. Dlatego nie będzie przesyłał przełomowych zmian na serwer, ale będzie nadal udoskonalał swoje rozwiązanie. Tak, oczywiście, niewielu programistów kocha testy, ale nie można zaprzeczyć korzyściom, jakie wnoszą do aplikacji. Często klienci sami określają, jakiego poziomu pokrycia testami mają się trzymać (na przykład 80%). Dlatego trzeba znać różne rodzaje testów i umieć je pisać. Programiści Java piszą głównie testy jednostkowe i testy integracyjne, natomiast AQA (testerzy automatyczni) zajmują się testami bardziej rozbudowanymi (end-to-end). Więcej o nich i o innych przedstawicielach zawodów IT przeczytacie w mojej recenzji .
4. Znalezienie i naprawienie błędu
Jest to również bardzo częste i częste zadanie programisty Java. Głównym zadaniem QA i AQA jest wychwytywanie błędów. Czyli szukają miejsc, w których program zachowuje się nieprawidłowo, tworzą problemy w Jirze i zrzucają winę na kogoś. Na przykład lider zespołu, który z kolei decyduje, któremu programiście przypisać to, w zależności od jego obciążenia i znajomości tej części systemu. Następnie programista wyszukuje błąd, spędzając godziny w debugerze , korzystając z opisu problemu sporządzonego przez specjalistów ds. kontroli jakości, aby powtórzyć sytuację, w której wystąpił błąd. Następnie programista znajduje błąd, naprawia go i wysyła do sprawdzenia. Cóż, możliwe, że programista nie mógł odtworzyć błędu i zwraca zadanie do specjalisty ds. kontroli jakości z komentarzem na ten temat. Wygląda na to, że znalezienie i naprawienie błędu nie zajmie dużo czasu, ale są pewne niuanse. Wszystko zależy przede wszystkim od znajomości tej części kodu przez programistę, jego doświadczenia i znajomości zagadnień teoretycznych. Czasami błąd można znaleźć i naprawić w 20 minut, a czasami może to zająć trzy dni. W związku z tym tego typu zadanie jest szczególnie trudne do oceny z góry, chyba że programista po przeczytaniu opisu od razu zrozumie, co, gdzie i z czym poszło nie tak. W takim przypadku będzie mógł mniej więcej dokładnie odgadnąć czas.
5. Przegląd kodu
Jak wspomniano powyżej, zaraz po wykonaniu zadania należy je wysłać do sprawdzenia, a jeśli je przejdzie, trafia do wątku ogólnego, jeśli nie, zostanie zwrócone programiście z komentarzami co należy poprawić poprawione. Oczywiste jest, że wszystko to jest sprawdzane nie przez jakieś siły wyższe, ale przez innych programistów. Jednak nie wszyscy programiści mogą zostać recenzentami, a jedynie ci najbardziej doświadczeni, którzy mają za sobą praktykę i potrafią odróżnić zły kod od dobrego. Przegląd kodu zwykle odbywa się za pomocą narzędzia pomocniczego, na przykład Crucible . Recenzenci przeglądają kod i, jeśli to konieczne, zostawiają komentarze pod niektórymi liniami. Komentarze mogą być również różnego typu. Np. krytyczne, bez poprawienia których recenzent nie przekaże kodu, a inne to raczej uwagi na temat wybranego podejścia, których programista może wysłuchać, odnotować lub zignorować. Zespół może stworzyć własną procedurę i zasady przeprowadzania przeglądów, uzgodnić, na co warto zwrócić uwagę, a na co nie, w jakim terminie należy przeprowadzić przegląd kodu itp. Aby przeprowadzić recenzję, samo doświadczenie nie wystarczy: nadal musisz dużo rozwijać się w kierunku technicznym, czytać różne książki (na przykład „Czysty kod” ). Jeśli interesują Cię niuanse przeprowadzania przeglądu kodu według Google, radzę przeczytać ten artykuł .
6. Analiza kodu
Ponieważ projekt jest pisany jednocześnie przez kilka osób, które myślą odmiennie, ich kod i podejścia będą się różnić. Z biegiem czasu wszystko stopniowo zamieni się w papkę. Aby ulepszyć kod, czasami tworzysz zadania do analizy, być może konkretnego modułu lub całej aplikacji, aby znaleźć błędy i oznaczyć je, a później tworzysz zadanie refaktoryzacji na podstawie tych komentarzy. Analiza pomaga także w sytuacjach, gdy pewne prostsze skróty nie były widoczne od początku rozwoju, ale teraz można je dostrzec. Na przykład ta sama logika jest często powtarzana w niektórych metodach i dlatego można ją przenieść do osobnej metody i wielokrotnie używać ponownie. Cóż, albo jakaś klasa została boleśnie rozdęta, albo jakiś kod stał się trudny w utrzymaniu lub przestarzały, albo... Zadania analityczne pomagają poprawić jakość kodu i aplikacji. Chociaż moim zdaniem analiza dużej ilości kodu może być nudnym zadaniem.
7. Refaktoryzacja kodu
Kolejną częścią analizy jest refaktoryzacja kodu. Może być przestarzały, niepotrzebny, źle napisany, trudny do odczytania i tak dalej. Należy zawsze dążyć do perfekcji (choć ona nie istnieje) i do aktualnego kodu, usuwając wszystko, co niepotrzebne, bo to tylko dezorientuje i uniemożliwia dostrzeżenie istoty funkcjonalności. Jest rzeczą oczywistą, że jest mało prawdopodobne, aby zobaczyć te zadania na początku projektu: pojawiają się one dopiero na późniejszych etapach rozwoju, kiedy aplikacja jest dopracowana i doprowadzona do perfekcji. W tym przypadku właściwe może być skonsultowanie się ze współpracownikami w sprawie tego, jak by to zrobili i jakie pułapki widzą. Istota takich zadań jest podobna do tworzenia nowych funkcjonalności. Na przykład otrzymujesz zadanie edycji jakiejś funkcjonalności bez zmiany jej zachowania. Aby to zrobić, usuwasz stary, piszesz własny i sprawdzasz testy. Jeśli zrobiłeś wszystko poprawnie, bez wprowadzania zmian w testach, powinny one działać jak poprzednio. Gdy już wszystko zostanie uregulowane w kodzie, wysyłamy go do recenzji i idziemy na kawę))
8. Pisanie dokumentacji
Wyobraź sobie, że jesteś nowym programistą w projekcie, który był rozwijany przez długi czas. Trzeba się z tym zapoznać lub wykonać jakieś konkretne zadanie, np. złapać błąd. Jak będziesz poruszać się po projekcie? Ciągnij członków swojego zespołu co pięć minut? A jeśli są zajęci lub mają weekend, co wtedy? Po to właśnie istnieje dokumentacja, aby osoba nieobeznana z funkcjonalnością mogła wejść, znaleźć odpowiednią stronę i szybko zorientować się, co robi interesująca ją część aplikacji. Ale ktoś też musi wypełnić dokumentację ^^ Jeśli projekt posiada dokumentację, którą programiści muszą wesprzeć, wdrażając nową funkcjonalność opisują ją i przy różnych zmianach i refaktoryzacjach aktualizują dokumentację. Możliwe są również sytuacje, gdy do pisania, wspierania i kontrolowania dokumentacji zatrudniony zostanie odrębny specjalista, pisarz techniczny. Jeśli taki specjalista istnieje, ułatwia to życie zwykłym programistom.
9. Udział w różnych wiecach
Programiści spędzają dużo czasu na różnych spotkaniach, negocjacjach i planowaniu. Najprostszym przykładem są „codzienne spotkania” (codzienne spotkania), podczas których musisz opowiedzieć, co robiłeś wczoraj i co będziesz robić dzisiaj. Ponadto musisz odbyć rozmowę indywidualną, na przykład ze specjalistą ds. kontroli jakości, aby mógł pokazać/wyjaśnić niuanse odtwarzania błędu lub omówić niuanse i wymagania z analitykiem biznesowym lub organizacyjnym problemy z PMem. Dlatego nawet jeśli programista może być introwertykiem preferującym samotność, to jednak musi umieć znaleźć wspólny język z innymi ludźmi (no przynajmniej trochę). Im wyższa ranga programisty, tym więcej czasu potrzebuje na komunikację, a mniej na pisanie kodu. Lider zespołu programistów może nawet spędzać połowę lub nawet więcej swojego czasu pracy na rozmowach i spotkaniach oraz rzadziej pisać kod (może to prowadzić do utraty kontroli). Ale jeśli jesteś także osobą, która lubi rozmawiać, możesz łatwo przejść od pozycji lidera zespołu do strony menadżerskiej i całkowicie zapomnieć o kodzie, komunikując się przez cały dzień z różnymi zespołami, klientami i innymi menedżerami.
Jeśli pracujesz dla firmy outsourcingowej lub outstaffingowej, będziesz musiał przechodzić częste rozmowy kwalifikacyjne zewnętrzne, gdy trzeba Cię „sprzedać” klientowi (wtedy możesz przeprowadzić rozmowę z osobą ze strony klienta) oraz rozmowy wewnętrzne, aby podnieść swoją rangę w firmie. Nazwałbym to dobrym czynnikiem rozwoju, bo dzięki częstym rozmowom Twoja wiedza powinna być zawsze w formie: nie zardzewiejesz i zrelaksujesz się, bo jeśli zrelaksujesz się w IT, możesz całkowicie wylecieć z pola. Kiedy staniesz się bardziej doświadczonym programistą, będziesz mógł przejść na drugą stronę: nie mijając, ale przeprowadzając rozmowy kwalifikacyjne. Uwierz mi, będziesz bardzo zaskoczony, jeśli spojrzysz na to z tej perspektywy, ponieważ prowadzenie rozmów kwalifikacyjnych może być straszniejsze niż zaliczenie. Trzeba mieć własną strategię rozmowy kwalifikacyjnej, listę pytań i mieć czas na zadawanie pytań na wszystkie niezbędne tematy w ciągu godziny. A potem jesteś odpowiedzialny za informację zwrotną, ponieważ opierając się na niej, dana osoba może otrzymać tak długo oczekiwaną ofertę lub promocję lub nie. No i odwrotnie: można przegapić szczerze słabego kandydata na stanowisko, na które nie odpowiada, i wtedy można zapytać: jak w ogóle go przegapiliście przy takim poziomie wiedzy? Dlatego też podczas rozmowy kwalifikacyjnej miej na uwadze, że osoba naprzeciwko Ciebie również przeżywa trudne chwile i może też doświadczać stresu. Każda rozmowa kwalifikacyjna jest stresująca zarówno dla kandydata, jak i osoby przeprowadzającej rozmowę kwalifikacyjną. Być może na tym zakończymy. Dziękuję każdemu, kto skończył czytać: polub i naucz się Javy ^^
Po drugie, programista musi być elastyczny w tym sensie, aby nie utknąć w jednym rozwiązaniu i zamknąć się na inne. Musisz zrobić tylko w ten sposób i nic innego. Może się to zdarzyć z różnych powodów: na przykład chcesz udowodnić swój punkt widzenia, albo opracowałeś i wdrożyłeś już swoje rozwiązanie, do którego jesteś dość przywiązany i oczywiście nie chcesz się przyznać, że to nie jest to to, co najlepsze. To może cię całkiem oślepić. Tak naprawdę trzeba umieć przyznać się do błędów i zawsze być otwartym na nowe rzeczy („otwarty”), nawet jeśli trzeba będzie usunąć funkcjonalność, o której pisałeś od wielu tygodni i z której jesteś bardzo dumny. Pamiętam, jak kiedyś nastrój na cały dzień robił czyjś licznik czasu w Jirze z komentarzem: „Usunąłem funkcjonalność martwego dziecka. płakałam”
Dlatego trzeba znać różne rodzaje testów i umieć je pisać. Programiści Java piszą głównie testy jednostkowe i testy integracyjne, natomiast AQA (testerzy automatyczni) zajmują się testami bardziej rozbudowanymi (end-to-end). Więcej o nich i o innych przedstawicielach zawodów IT przeczytacie w mojej recenzji .
Przegląd kodu zwykle odbywa się za pomocą narzędzia pomocniczego, na przykład Crucible . Recenzenci przeglądają kod i, jeśli to konieczne, zostawiają komentarze pod niektórymi liniami. Komentarze mogą być również różnego typu. Np. krytyczne, bez poprawienia których recenzent nie przekaże kodu, a inne to raczej uwagi na temat wybranego podejścia, których programista może wysłuchać, odnotować lub zignorować. Zespół może stworzyć własną procedurę i zasady przeprowadzania przeglądów, uzgodnić, na co warto zwrócić uwagę, a na co nie, w jakim terminie należy przeprowadzić przegląd kodu itp. Aby przeprowadzić recenzję, samo doświadczenie nie wystarczy: nadal musisz dużo rozwijać się w kierunku technicznym, czytać różne książki (na przykład „Czysty kod” ). Jeśli interesują Cię niuanse przeprowadzania przeglądu kodu według Google, radzę przeczytać ten artykuł .
W tym przypadku właściwe może być skonsultowanie się ze współpracownikami w sprawie tego, jak by to zrobili i jakie pułapki widzą. Istota takich zadań jest podobna do tworzenia nowych funkcjonalności. Na przykład otrzymujesz zadanie edycji jakiejś funkcjonalności bez zmiany jej zachowania. Aby to zrobić, usuwasz stary, piszesz własny i sprawdzasz testy. Jeśli zrobiłeś wszystko poprawnie, bez wprowadzania zmian w testach, powinny one działać jak poprzednio. Gdy już wszystko zostanie uregulowane w kodzie, wysyłamy go do recenzji i idziemy na kawę))
Im wyższa ranga programisty, tym więcej czasu potrzebuje na komunikację, a mniej na pisanie kodu. Lider zespołu programistów może nawet spędzać połowę lub nawet więcej swojego czasu pracy na rozmowach i spotkaniach oraz rzadziej pisać kod (może to prowadzić do utraty kontroli). Ale jeśli jesteś także osobą, która lubi rozmawiać, możesz łatwo przejść od pozycji lidera zespołu do strony menadżerskiej i całkowicie zapomnieć o kodzie, komunikując się przez cały dzień z różnymi zespołami, klientami i innymi menedżerami.
Być może na tym zakończymy. Dziękuję każdemu, kto skończył czytać: polub i naucz się Javy ^^
GO TO FULL VERSION