Типични задачи на Java разработчик по проект

Какви са типичните отговорности на разработчика на Java? В крайна сметка трябва да разберете в Howво се забърквате и Howво ще направите в крайна сметка, нали? Днес бих искал да говоря за десет жизненоважни задачи, които Java разработчикът изпълнява. Но първо, нека се запознаем с инструмента, наречен Jira. Или опреснете паметта си за него, ако вече сте запознати с него. Джирае инструмент за организиране на човешки взаимодействия, въпреки че в някои случаи се използва и за управление на проекти. С други думи, един проект е разделен на малки задачи, които са описани в този инструмент. Тези задачи се възлагат на разработчиците, които отговарят за тяхното изпълнение. Една задача може да бъде например добавяне на няHowва функционалност. Докато задачата се изпълнява, разработчиците и другите специалисти добавят коментари за това кой Howво е направил и колко време е отделил. Това се прави с цел проследяване на времето - за да се знае колко време е изразходвано за Howви задачи. В идеалния случай това се прави веднъж на ден: Преди да напуснете бюрото си вечер, посочвате колко от вашите 8 работни часа сте прекарали в различни задачи. Във функционалността на Jira има много повече от описаното по-горе, но това ще бъде достатъчно за първоначално разбиране.

1. Проектиране на нови решения

Преди да създадете и реализирате нещо, трябва да го концептуализирате, нали? Както казах преди, това може просто да е задача в Jira, която ви се възлага, така че вие ​​работите по проектирането на ново решение, като записвате в Jira колко време сте прекарали и за Howво. Тази работа може да се извърши и по време на дискусия в екипна конферентна връзка: всеки може да изрази мнението си и да предложи подхода, който смята за най-добър. И тук бих искал да отбележа няколко точки. Първо, разработването на софтуер е много творческа професия, тъй като трябва да използвате стандартни инструменти, за да измислите нови начини за решаване на проблеми. Една задача често може да има много различни решения. Съответно всичко зависи от креативността на разработчика, която е силно повлияна от натрупаните знания и опит. Можете да покажете цялата си креативност и гений тук, но важното е да не се прекалява. Ако го направите, codeът ще стане твърде сложен и нечетлив. В резултат на това, след като си тръгнете, никой няма да разбере напълно Howво сте codeирали и How работи. И ще трябва да пренапишат всичко от нулата. И те могат да си спомнят за вас. Повече от веднъж. И едва ли ще има топли, мor думи. имаш ли нужда от това Второ, разработчикът трябва да запази психологическа гъвкавост в смисъл, че не трябва да се придържате към едно решение и да се затваряте към другите. Сякаш трябва да направиш нещо само по един начин и няма други възможности. Може да попаднете в този капан по различни причини. Да предположим например, че искате да докажете, че вашата гледна точка е правилна. Или може би вече сте проектирали и внедрor свое собствено познато решение – разбира се, не бихте искали да признаете, че не е най-доброто. Тези ситуации могат да ви направят доста слепи. Всъщност трябва да можете да признаете грешките си и да бъдете винаги отворени, дори ако трябва да премахнете функционалност, с която се гордеете и сте codeирали повече от седмица. Спомням си How един колега озари деня на всички веднъж, като остави този коментар за проследяване на времето в Jira: „Премахнах чертата си на мъртвородено. И скърбях.“

2. Писане на нова функционалност

Тази стъпка – внедряване на нова функционалност – следва логично след предишната. Цялата работа, включена в даден проект, е разделена на задачи в Jira, които след това се разпределят на разработчиците въз основа на тяхното натоварване. Има различни подходи към този процес, известни като „методологии“, за които можете да прочетете по-подробно в тази статия на CodeGym . По правило задачите имат оценка, което е предвиденото време, необходимо за завършването им. Задава се or от вас, разработчика, когато получите задачата, or от ръководителя на екипа, or по време на планирането, колективно от екипа за разработка. Това предположение за време много рядко е точно, тъй като толкова много различни фактори влияят върху разработването на софтуер. Например, дали програмистът е запознат or не със съответната технология, неговият or нейният цялостен опит, различни непредвидими клопки и т.н. Така че, ако не постигнете всичките си прогнози за време, когато codeирате, това не е краят на света. Това са само общи оценки. Въпреки това, не всички проекти изискват оценка на времето. Лично аз смятам, че е много по-лесно да живея без него, особено когато премиерът не ме досажда няколко пъти на ден с въпроса "къде са вашите прогнози за време?" И така, получавате задача,Готов за преглед " в Jira и се молете вашите промени в codeа да не бъдат върнати за преразглеждане заедно с коментари.

3. Писане на тестове

Рецензентът, т.е. човекът, който проверява вашия code, харесва функционалността, която сте внедрor, но има въпрос към вас: къде са свързаните тестове? Така че тя ви изпраща задачата обратно за преразглеждане. Тестовете са съществена част от всяко Java приложение. Чрез провеждане на тестове можете незабавно да идентифицирате места, където приложението не работи правилно. Например, разработчик прави някои промени в една част от системата, което води до промени в поведението в друга част, но той не е забелязал това, докато е codeирал. Чрез провеждането на тестовете той ще може да види, че определени тестове са се провалor, което означава, че не са дали очакваните резултати. Това му казва, че нещо е счупено някъде другаде в системата. Знаейки това, той няма да извърши нарушаващите промени на сървъра и instead of това ще продължи да работи по отстраняването на грешки в своя code. да доста малко разработчици обичат да пишат тестове, но не могат да се отрекат ползите, които те носят за разработката на софтуер. Самите клиенти често посочват нивото на тестово покритие, което искат да поддържат (например 80%). Това означава, че трябва да знаетеразличните видове тестове и да може да ги напише. Java разработчиците пишат главно модулни тестове и интеграционни тестове, докато по-обширните (от край до край) тестове се обработват от QA и експерти по автоматизация на тестовете.

4. Намиране и коригиране на грешки

Това също е много често срещана задача за разработчиците на Java. Основната работа на QA и експертите по автоматизация на тестовете е да хващат грешки. С други думи, те търсят места, където програмата се държи неправилно, след което създават задачи в Jira и ги възлагат на някого. Например на ръководител на екипа, който от своя страна решава към кои разработчици да ги назначи в зависимост от тяхната натовареност и познаване на съответните части на системата. След това назначеният разработчик преследва основната причина за грешката, прекарвайки часове в програма за отстраняване на грешки, използвайки описанието на грешката, предоставено от експертите по QA, за да възпроизведе условията, при които възниква грешката. След като разработчикът открие грешката и я поправи, той изпраща корекцията за преглед. Понякога разработчикът не може да възпроизведе грешката, така че той изпраща задачата обратно на QA експерта заедно с обяснителен коментар. Изглежда, че не би трябвало да отнеме много време, за да намерите и коригирате грешка, но има някои нюанси. Всичко зависи главно от това колко добре е запознат разработчикът с този раздел от codeа, Howто и от неговия опит и теоретични познания. Понякога грешката може да бъде открита и коригирана за 20 minutesи, а понякога може да отнеме три дни. Това означава, че този тип задача е особено трудна за оценка предварително, освен ако разработчикът, след като прочете описанието, веднага разбере Howво, къде и How е грешката. В такъв случай,

5. Преглед на codeа

Както бе споменато по-горе, веднага след като изпълните задача, тя трябва да бъде изпратена за преглед. Ако премине прегледа, тогава отива в основния клон. Ако не, той се връща на разработчика с коментари, които трябва да бъдат разгледани. Разбира се, вие разбирате, че целият ви code се проверява от други разработчици, а не от няHowва висока власт. Въпреки това, не всеки има право да извършва прегледи на codeа — само най-опитните разработчици, закалени от практиката в реалния свят, които могат да направят разликата между добър и лош code. Прегледите на codeа обикновено се извършват с помощта на помощен инструмент като Crucible. Рецензентите преминават през codeа и, ако е необходимо, оставят коментари за определени редове. Може да има различни видове коментари. Например, някои са критични. Ако те не бъдат addressирани, рецензентът няма да позволи codeът да бъде ангажиран. Други коментари са, да речем, просто забележки относно избрания подход. Разработчикът може да ги изслуша, вземе под внимание or игнорира. Екипът може да създаде свои собствени правила и proceduresи за прегледи на codeа, като се съгласи на Howво си струва да се обърне внимание и на Howво не, Howва времева рамка трябва да бъде определена за завършване на преглед на codeа и т.н. Опитът сам по себе си не е достатъчен за извършване на преглед: вие все още трябва да развиете много технически умения и да четете различни книги (например „Чист code“).

6. Анализ на codeа

Тъй като няколко души, които мислят различно, пишат code за проекта едновременно, техният code и подходи ще бъдат различни. И с течение на времето всичко постепенно се превръща в бъркотия. За да се подобри codeът, понякога се създават задачи за, да речем, анализиране на определен модул or цялото приложение, намиране и отбелязване на недостатъци и по-късно създаване на задача за рефакторинг въз основа на този анализ. Такъв анализ също помага в ситуации, в които, когато е започнала разработката, екипът не е могъл да види някои по-прости, по-сбити решения, но сега ги вижда. Например логиката често се дублира в някои методи. Съответно, той може да бъде извлечен в отделен метод, който след това може да се използва многократно. Или може би даден клас е станал твърде раздут, or няHowъв code е станал труден за поддръжка or остарял, or... Задачите за анализ помагат за подобряване на качеството на codeа и приложението. Въпреки това за мен анализирането на голямо количество code може да бъде скучно.

7. Рефакторинг на code

Следващата част от анализа на codeа е рефакторингът. Кодът може да е остарял, неактуален, лошо написан, труден за четене и т.н. Винаги трябва да се стремите към съвършенство (въпреки че то не съществува) и към актуален code, като премахвате всичко излишно, защото излишното води само до объркване и пречи на възможността да видите Howво прави codeът. От само себе си се разбира, че е малко вероятно да видите тези задачи в началото на проекта: срещате ги на по-късни етапи от разработката, когато приложението се изпипва и довежда до съвършенство. Тук може да е подходящо да се консултирате с колеги Howво биха направor и Howви клопки виждат. В основата си такива задачи са подобни на разработването на нова функционалност. Да предположим например, че получавате задача да редактирате няHowва функционалност, без да променяте нейното поведение. За да направите това, изтривате стария code, пишете свой собствен и проверявате тестовете. Ако сте направor всичко правилно, тогава без да правите промени в тестовете, всички те трябва да преминат Howто преди. След като всичко в codeа е Howто трябва, го изпращаме за преглед и отиваме да пием кафе :)

8. Писане на documentация

Представете си, че сте нов разработчик на няHowъв дългосрочен проект за разработка на софтуер. Трябва да се запознаете с codeовата база or да изпълните няHowва конкретна задача, например да диагностицирате грешка. Как ще навигирате в проекта? Досаждате на съотборниците си на всеки пет minutesи? И Howво, ако са заети or е уикенд, Howво тогава? Точно за това имаме documentация — за да може човек, който не е запознат с codeа, да влезе, да намери съответната page и бързо да разбере Howво се случва в частта от приложението, която го интересува. Но някой трябва да създаде documentацията, хаха. Ако даден проект има documentация, която разработчиците трябва да поддържат, тогава, когато прилагат нова функционалност, те я описват и актуализират documentацията заедно с всички промени в codeа or рефакторинг. Можете също така да имате ситуации, при които отделен служител - технически писател - е нает да пише, поддържа и контролира documentацията. Ако има такъв специалист, животът на обикновените разработчици е малко по-лесен.

9. Различни срещи

Много време на разработчиците се изразходва в различни срещи, преговори и планиране. Най-простият пример е ежедневната среща, на която трябва да докладвате Howво сте направor вчера и Howво ще правите днес. Освен това ще трябва да проведете индивидуални телефонни разговори, например с тестери, за да могат да демонстрират/обяснят нюансите на възпроизвеждане на грешка or да обсъдят тънкостите и изискванията с бизнес анализатор or да говорят за организационни въпроси с ЛС. Това означава, че въпреки че разработчикът може да е интроверт, който предпочита самотата, тя все пак трябва да може да намери общ език с други хора (е, поне малко). Колкото по-висок е рангът на разработчика, толкова повече време трябва да отделя за комуникация и толкова по-малко време за писане на code. Ръководителят на разработчиците може да прекара половината or дори повече от работния си ден в разговори и срещи сам и може да пише code по-рядко (което вероятно ще го накара да загуби малко от уменията си за codeиране). Но ако просто обичате да говорите, бихте могли, като ръководител на екип, да преминете към управление и напълно да забравите за писането на code, instead of това ще прекарате цял ден в комуникация с различни екипи, клиенти и други мениджъри.

10. Провеждане/преминаване на интервюта

Ако работите за аутсорсинг or аутстафинг компания, често ще трябва да преминете през външни интервюта, където ще трябва да се „продадете“ на клиента (може да бъдете интервюиран от някой, който работи за клиента), Howто и вътрешни такива, които да се изкачат в редиците на компанията. Бих нарекъл това добра възможност за растеж, защото честите интервюта ще ви принудят да поддържате знанията си остри: няма да станете ръждясали и омекнали. В крайна сметка, ако станете меки в ИТ, можете напълно да изпаднете от полето. Когато станете по-опитен разработчик, ще можете да се окажете от другата страна на масата, провеждайки интервюта, instead of да ги преминавате. Повярвайте ми, ще бъдете много изненадани, когато го погледнете от тази позиция, защото задаването на въпроси на интервюто може да бъде по-страшно от отговарянето на тях. Трябва да имате собствена стратегия за интервю, списък с въпроси и време за задаване на въпроси по всички необходими теми в рамките на един час. И след това вие сте отговорни да предоставите обратна връзка, която ще повлияе на решението за наемане и дали кандидатът ще получи дългоочаквано предложение or повишение. Или може да позволите на очевидно слаб кандидат да получи позиция, за която не отговаря на условията, и тогава може да бъдете попитани: „Как изобщо можахте да позволите тя да бъде наета с това ниво на познания“? Така че, когато сте на горещия стол по време на интервю, имайте предвид, че човекът срещу вас също е изпequals пред предизвикателство и може да бъде стресиран. вие сте отговорни да предоставите обратна връзка, която ще повлияе на решението за наемане и дали кандидатът ще получи дългоочаквано предложение or повишение. Или може да позволите на очевидно слаб кандидат да получи позиция, за която не отговаря на условията, и тогава може да бъдете попитани: „Как изобщо можахте да позволите тя да бъде наета с това ниво на познания“? Така че, когато сте на горещия стол по време на интервю, имайте предвид, че човекът срещу вас също е изпequals пред предизвикателство и може да бъде стресиран. вие сте отговорни да предоставите обратна връзка, която ще повлияе на решението за наемане и дали кандидатът ще получи дългоочаквано предложение or повишение. Или може да позволите на очевидно слаб кандидат да получи позиция, за която не отговаря на условията, и тогава може да бъдете попитани: „Как изобщо можахте да позволите тя да бъде наета с това ниво на познания“? Така че, когато сте на горещия стол по време на интервю, имайте предвид, че човекът срещу вас също е изпequals пред предизвикателство и може да бъде стресиран. Всяко интервю е стресиращо Howто за кандидата, така и за интервюиращия. Вероятно ще приключим тук. Благодаря на всички, които прочетоха тази статия. Харесайте и продължавайте да изучавате Java :)