Java әзірлеушісінің жобадағы типтік тапсырмалары

Java әзірлеушісінің типтік міндеттері қандай? Ақыр соңында, сіз не үшін бара жатқаныңызды түсінуіңіз керек және соңында не істейсіз, солай ма? Бүгін мен Java әзірлеушісі орындайтын он негізгі тапсырма туралы айтқым келеді. Бірақ алдымен Jira сияқты құралмен танысайық. Немесе ол сізге бұрыннан таныс болса, жадымызды жаңартайық. Jira – пайдаланушымен өзара әрекеттесу құралы, дегенмен ол кейбір жағдайларда жобаны басқару үшін де қолданылады. Басқаша айтқанда, жобаны әзірлеу осы құралда сипатталған шағын тапсырмаларға бөлінеді. Бұл міндеттер әзірлеушілерге жүктеледі (тағайындалады), олар олардың орындалуына жауапты болады. Тапсырмалар деп, мысалы, кейбір функцияларды қосуды айтамыз. Прогресс ілгерілеген сайын әзірлеушілер мен басқа мамандар кімнің не істегені және қанша уақыт өткізгені туралы түсініктемелер қосады — олар уақытты қадағалайды. Бұл жұмсалған уақытты бақылау үшін жасалады: қанша және не үшін жұмсалды. Ең дұрысы, бұл күніне бір рет жасалады: кешке кетер алдында сіз 8 сағатыңызды жұмсаған тапсырмаларға дейін қадағалайсыз. Jira функционалдығы жоғарыда сипатталғанға қарағанда әлдеқайда кең, бірақ бұл бастапқы түсіну үшін жеткілікті болады. Сонымен, Java әзірлеушісінің міндеттері қандай?

1. Жаңа шешімдерді әзірлеу

Бір нәрсені жасап, жүзеге асырмас бұрын, оны ойлап табу керек, солай емес пе? Мен айтқанымдай, бұл сізге тағайындалатын Jira тапсырмасы болуы мүмкін және сіз Джирада қанша уақыт жұмсағаныңызды және не үшін жұмсағаныңызды көрсете отырып, жаңа шешім әзірлеуге жұмыс жасайсыз. Бұл топтық шақырудағы талқылау да болуы мүмкін: әркім өз пікірін білдіре алады және ең жақсы деп санайтын тәсілді ұсына алады. Осы жерде мен бірнеше жайтты атап өткім келеді. Біріншіден, әзірлеуші ​​мамандығы - бұл өте шығармашылық сала, өйткені стандартты құралдарды пайдаланып мәселелерді шешудің бірегей жолдарын табу керек. Көбінесе бір мәселенің әртүрлі шешімдері болуы мүмкін: сәйкесінше, бәрі әзірлеушінің «шығармашылық рухына», жинақталған білім базасы мен тәжірибесіне байланысты. Мұнда сіз өзіңіздің барлық шығармашылық қабілеттеріңізді және данышпандығыңызды көрсете аласыз, бірақ бастысы - оны асыра алмау: бұл жағдайда code тым күрделі және оқылмайтын болады және нәтижесінде сіз кеткеннен кейін оның не екенін ешкім толық түсінбейді және Ол қалай жұмыс істейді. Және бәрін нөлден қайта жазу керек болады. Және олар сені еске алуы мүмкін. Және бірнеше рет. Ал бұл жылы, жылы сөздер болуы екіталай. Сізге керек пе? Екіншіден, әзірлеуші ​​икемді болуы керек, өйткені сіз бір шешімде тұрып қалмайсыз және басқаларға жабық боласыз. Сізге тек осылай істеу керек, басқа ештеңе жоқ. Бұл әртүрлі себептерге байланысты болуы мүмкін: мысалы, сіз өзіңіздің көзқарасыңызды дәлелдегіңіз келеді немесе сіз өз шешіміңізді әзірлеп, іске асырдыңыз, ол сізге өте жақын және, әрине, бұл мәселе емес екенін мойындағыңыз келмейді. ең жақсы. Бұл сізді айтарлықтай соқыр етуі мүмкін. Шын мәнінде, сіз өз қателеріңізді мойындай білуіңіз керек және жаңа нәрселерге әрдайым ашық болуыңыз керек («ашық ойлы»), тіпті сіз көптеген апталар бойы жазып келе жатқан және мақтан тұтатын функционалдылықты жоюға тура келсе де. Бірде Джирада біреудің тайм трегі бүкіл күннің көңіл-күйін қалай жасағаны есімде: «Мен өлі туылған функциямды жойдым. Мен жыладым»

2. Жаңа функцияларды жазу

Бұл алдыңғысынан кейінгі логикалық қадам - ​​жаңа функционалдылықты енгізу. Жобадағы барлық жұмыстар джирадағы тапсырмаларға бөлінген, оны әзірлеушілер жұмыс кезінде алады. Бұл мәселеге әртүрлі тәсілдер бар - «әдістемелер», олар туралы толығырақ JavaRush туралы осы мақалада оқи аласыз . Әдетте, тапсырмаларда «Бағалау» болады - аяқтауға жұмсалған болжамды уақыт. Оны сіз тапсырманы қабылдаған кезде өзіңіз орнатады, немесе топ жетекшісі немесе жоспарлау кезінде әзірлеушілер оны бірлесіп бағалайды. Бұл уақыт өте сирек дәл болжанады, өйткені дамуға әртүрлі факторлар әсер етеді. Мысалы, бағдарламашы бұл технологиямен таныс немесе бейтаныс па, оның жалпы тәжірибесі қандай, әзірлеу кезінде көрінуі мүмкін әртүрлі тұзақтар және т.б. Сондықтан, функционалдылықты әзірлеу кезінде осы мерзімге сай келмесеңіз, жаман ештеңе болмайды. Бұл жалпы есептер ғана. Бірақ тағы да айтамын, барлық жобаларда тапсырмаларды бағалау жоқ, мен үшін онсыз өмір сүру әлдеқайда оңай, әсіресе премьер-министр сізді күніне бірнеше рет «Бағалаулар қайда? » Тиісінше, сіз тапсырманы қабылдайсыз, қажетті функционалдылықты дамытасыз, оны GIT -дегі жалпы бөлімшеге жүктейсіз және жирада тапсырманың күйін «Қарап шығуға дайын» ​​деп өзгертесіз , яғни қарауға (тексеруге) дайын және бұл туралы дұға етесіз. ол сізге қайта қарау туралы түсініктемелермен қайтарылмайды.

3. Функционалдылыққа тесттер жазу

Кодыңызды тексеретін адам - ​​шолушы - сіз жасаған функционалдылықты ұнатты, бірақ оның сұрағы бар: ол үшін сынақтар қайда? Және ол сізге тапсырманы қайталау үшін қайтарады. Тесттер кез келген Java қолданбасының маңызды бөлігі болып табылады. Оларды іске қосу арқылы қолданбаның қай жерде дұрыс жұмыс істемейтінін бірден анықтауға болады. Мысалы, әзірлеуші ​​жүйенің бір бөлігіне кейбір өзгерістер енгізді, бұл екінші бөлігінде мінез-құлықтың өзгеруіне әкелді және оны әзірлеу кезінде байқамады. Тесттерді орындау арқылы ол сәтсіз (дұрыс жұмыс істемеген) сынақтарды көре алады. Бұл оған жүйенің басқа бөлігінде бір нәрсе бұзылғанын айтады. Сондықтан ол serverге үзіліссіз өзгерістерді жүктеп салмайды, бірақ шешімін жетілдіруді жалғастырады. Иә, әрине, аз әзірлеушілер сынақтарды жақсы көреді, бірақ олардың қосымшаға әкелетін пайдасын жоққа шығаруға болмайды. Көбінесе тұтынушылар тестілеуді қамтудың қандай деңгейін сақтау керектігін өздері анықтайды (мысалы, 80%). Сондықтан әр түрлі тест түрлерін біліп , жаза білу керек. Java әзірлеушілері негізінен бірлік сынақтары мен интеграциялық сынақтарды жазады, ал AQA (автоматтандыру тестерлері) кеңірек (соңғы) сынақтармен айналысады. Олар туралы және IT кәсіптерінің басқа өкілдері туралы менің шолуымда толығырақ оқи аласыз .

4. Қатені табу және түзету

Бұл Java әзірлеушісі үшін өте кең таралған және жиі кездесетін тапсырма. QA және AQA негізгі міндеті қателерді ұстау болып табылады. Яғни, олар бағдарлама дұрыс жұмыс істемейтін жерлерді іздейді, Jira-да мәселелер туғызады және оны біреуге жүктейді. Мысалы, топ жетекшісі, ол өз кезегінде жүктемесіне және жүйенің осы бөлігімен танысуына байланысты оны қай әзірлеушіге тағайындау керектігін шешеді. Осыдан кейін әзірлеуші ​​қате пайда болған жағдайды қайталау үшін QA мамандарының мәселенің сипаттамасын пайдаланып, жөндеушіде сағаттарды өткізіп, қатені іздейді. Содан кейін әзірлеуші ​​қатені тауып, оны түзетеді және оны тексеруге жібереді. Мүмкін, әзірлеуші ​​қатені қайта шығара алмауы мүмкін және ол тапсырманы QA маманына бұл туралы түсініктемемен қайтарады. Қатені табу және түзету көп уақытты қажет етпейтін сияқты, бірақ кейбір нюанстар бар. Барлығы, ең алдымен, әзірлеушінің codeтың осы бөлімімен танысуына, тәжірибесіне және теориялық мәселелерді білуіне байланысты. Кейде қате 20 minutesта табылып, түзетіледі, ал кейде үш күн кетуі мүмкін. Тиісінше, әзірлеуші ​​сипаттаманы оқығаннан кейін ненің, қайда және ненің дұрыс емес екенін бірден түсінбесе, тапсырманың бұл түрін алдын ала бағалау өте қиын. Бұл жағдайда ол уақытты азды-көпті дәл болжай алады.

5. Кодты қарау

Жоғарыда айтылғандай, тапсырманы орындаған бойда оны қарауға жіберу керек, ал егер ол өтсе, ол жалпы ағынға өтеді, егер өтпесе, ол не істеу керектігі туралы түсініктемелермен әзірлеушіге қайтарылады. түзетілді. Мұның бәрін әлдебір жоғары күштер емес, басқа әзірлеушілер тексеретіні анық. Бірақ барлық әзірлеушілерге рецензент болуға рұқсат етілмейді, бірақ тәжірибесі бар және жаман codeты жақсыдан ажырата алатын ең тәжірибелі адамдарға ғана рұқсат етіледі. Кодты қарап шығу әдетте көмекші құралдың көмегімен жасалады, мысалы, Crucible . Рецензенттер codeты қарастырады және қажет болса, кейбір жолдардың астына түсініктемелер қалдырады. Түсініктемелер де әртүрлі болуы мүмкін. Мысалы, сыни пікірлерді түзетусіз рецензент codeты өткізбейді, ал басқалары әзірлеуші ​​тыңдай алатын, ескеретін немесе елемеуі мүмкін таңдалған тәсіл туралы түсініктемелер болуы мүмкін. Команда шолуларды жүргізудің өзіндік тәртібі мен ережелерін жасай алады, не нәрсеге назар аудару керек және нені қажет етпейтінін, codeты тексеруді қандай мерзімде жүргізу керектігін және т.б. Шолуды жүргізу үшін тек тәжірибе жеткіліксіз: сізге әлі де техникалық бағытта көп нәрсені дамыту керек, әртүрлі кітаптарды оқу керек (мысалы, «Таза code» ). Егер сізді Google-ға сәйкес codeты тексерудің нюанстары қызықтырса, мен сізге осы мақаланы оқуға кеңес беремін .

6. Кодты талдау

Жобаны бір уақытта басқаша ойлайтын бірнеше адам жазғандықтан, олардың codeы мен тәсілдері әртүрлі болады. Ал уақыт өте келе бәрі бірте-бірте балшыққа айналады. Кодты жақсарту үшін, кейде белгілі бір модульді немесе бүкіл қолданбаны талдау үшін, кемшіліктерді тауып, оларды белгілеу үшін тапсырмалар жасайсыз және кейінірек осы түсініктемелер негізінде рефакторинг тапсырмасын жасайсыз. Талдау сонымен қатар кейбір қарапайым, таңбашалар әзірлеудің басынан бері көрінбейтін, бірақ оларды қазір көруге болатын жағдайларда көмектеседі. Мысалы, бір логика кейбір әдістерде жиі қайталанады және сәйкесінше оны бөлек әдіске ауыстырып, бірнеше рет қайта пайдалануға болады. Жақсы, не кейбір сыныптар қатты ісініп кетті, не кейбір codeты сақтау қиынға соқты немесе ескірген, немесе... Талдау тапсырмалары code пен қолданбаның сапасын жақсартуға көмектеседі. Менің ойымша, codeтың үлкен көлемін талдау қызықсыз тапсырма болуы мүмкін.

7. Кодты рефакторинг

Талдаудың келесі бөлігі codeты рефакторинг болып табылады. Ол ескірген, қажет емес, нашар жазылған, оқуға қиын және т.б. Сіз әрқашан кемелділікке (ол жоқ болса да) және жаңартылған codeқа ұмтылуыңыз керек, қажет емес барлық нәрсені алып тастаңыз, өйткені бұл тек шатастырады және функционалдылықтың мәнін көруге мүмкіндік бермейді. Бұл тапсырмаларды жобаның басында көру екіталай екені айтпаса да түсінікті: олар әзірлеудің кейінгі кезеңдерінде, қолданба жылтыратылған және жетілдірілген кезде ғана пайда болады. Бұл жерде әріптестермен мұны қалай жасайтыны және олар қандай тұзақтарды көретіні туралы кеңескен дұрыс. Мұндай тапсырмалардың мәні жаңа функционалдылықты дамытуға ұқсас. Мысалы, сіз кейбір функцияларды оның әрекетін өзгертпей өңдеу тапсырмасын аласыз. Мұны істеу үшін сіз ескісін жойып, өзіңізді жазып, сынақтарды тексересіз. Егер сіз бәрін дұрыс жасасаңыз, сынақтарға өзгерістер енгізбестен олар бұрынғыдай жұмыс істеуі керек. Барлығы codeта реттеліп болғаннан кейін, біз оны қарап шығуға жібереміз және кофе ішеміз))

8. Құжаттарды жазу

Сіз ұзақ уақыт бойы әзірленіп жатқан жобаның жаңа әзірлеушісі екеніңізді елестетіңіз. Сіз онымен танысуыңыз немесе белгілі бір тапсырманы орындауыңыз керек, мысалы, қатені ұстау. Сіз жобаны қалай шарлайсыз? Әр бес minutes сайын топ мүшелерін тартасыз ба? Ал егер олар бос емес болса немесе демалыс күндері болса, онда ше? Міне, сондықтан функционалдықпен таныс емес адам кіріп, қажетті бетті тауып, қолданбаның оны қызықтыратын бөлігі не істейтінін жылдам анықтай алатындай құжаттама бар. Бірақ біреу құжаттаманы да толтыруы керек ^^ Егер жобада әзірлеушілер қолдау көрсетуі керек құжаттама болса, жаңа функционалдылықты енгізу кезінде олар оны сипаттайды және әртүрлі өзгертулер мен рефакторингтермен құжаттаманы жаңартады. Құжаттарды жазу, қолдау және бақылау үшін жеке маман, техникалық жазушы жалданған кезде де жағдайлар болуы мүмкін. Егер мұндай маман бар болса, бұл қарапайым әзірлеушілердің өмірін біршама жеңілдетеді.

9. Әртүрлі митингілерге қатысу

Әзірлеушілер әртүрлі кездесулерге, келіссөздерге және жоспарлауға көп уақыт жұмсайды. Ең қарапайым мысал - «күнделікті жиналыстар» (күнделікті жиналыстар), онда сіз кеше не істегеніңізді және бүгін не істейтініңізді айтуыңыз керек. Бұған қоса, қатені қайта шығарудың нюанстарын көрсету/түсіндіру немесе бизнес-аналитикпен немесе ұйымдық бөліммен нюанстар мен талаптарды талқылау үшін, мысалы, QA маманымен жеке сөйлесу керек. Премьер-министрге қатысты мәселелер. Сондықтан, әзірлеуші ​​​​жалғыздықты жақсы көретін интроверт болуы мүмкін болса да, ол әлі де басқа адамдармен ортақ тіл таба білуі керек (жақсы, кем дегенде). Әзірлеушінің дәрежесі неғұрлым жоғары болса, соғұрлым ол коммуникацияға көбірек уақыт жұмсайды және code жазуға аз уақыт жұмсайды. Әзірлеуші-топ жетекшісі жұмыс уақытының жартысын, тіпті одан да көп уақытын сөйлесулер мен кездесулерге және codeты жиі жазуға жұмсай алады (бұл аздап ұстамдылық жоғалтуға әкелуі мүмкін). Бірақ егер сіз де сөйлескенді ұнататын адам болсаңыз, сіз командалық жетекші лауазымынан басқарушылық жағына оңай дамып, әр түрлі командалармен, тұтынушылармен және басқа менеджерлермен күні бойы сөйлесе отырып, codeты толығымен ұмыта аласыз.

10. Сұхбатты өткізу/өткізу

Егер сіз аутсорсинг немесе аутстаффингтік компанияда жұмыс істесеңіз, клиентке «сату» қажет болған кезде жиі сыртқы сұхбаттардан және ішкі сұхбаттардан өтуіңіз керек. компаниядағы дәрежеңізді арттырыңыз. Мен мұны дамудың жақсы факторы деп атар едім, өйткені жиі сұхбаттардың арқасында сіздің біліміңіз әрқашан пішінде болуы керек: сіз тот баспайсыз және демалмайсыз, өйткені егер сіз IT саласында демалсаңыз, сіз даладан толығымен ұшып кете аласыз. Тәжірибелі әзірлеуші ​​болған кезде, сіз екінші жағына бара аласыз: өту емес, сұхбат жүргізу. Маған сеніңіз, егер сіз бұған осы тұрғыдан қарасаңыз, сіз қатты таң қаласыз, өйткені сұхбат жүргізу өтуден гөрі қорқынышты болуы мүмкін. Сізде өзіңіздің сұхбат стратегияңыз, сұрақтар тізімі болуы керек және бір сағат ішінде барлық қажетті тақырыптар бойынша сұрақтар қоюға уақытыңыз болуы керек. Осыдан кейін сіз кері байланыс үшін жауап бересіз, өйткені оған сүйене отырып, адам мұндай көптен күткен ұсынысты немесе жарнаманы алуы немесе алуы мүмкін. Ал, және керісінше: сіз шынымен әлсіз үміткерді ол сәйкес келмейтін лауазымға жіберіп алуыңыз мүмкін, содан кейін сізден: мұндай білім деңгейімен оны қалай сағындыңыз? Сондықтан, сұхбаттан өткен кезде, сізге қарсы тұрған адам да қиын уақытты бастан кешіретінін және ол күйзеліске ұшырауы мүмкін екенін есте сақтаңыз. Кез келген сұхбат кандидат үшін де, сұхбат алушы үшін де стресс болады. Мүмкін осымен бітерміз. Оқуды аяқтағандардың барлығына рахмет: лайк басып, Java тілін үйреніңіз ^^