Java иштеп чыгуучунун долбоордогу типтүү милдеттери

Java иштеп чыгуучунун типтүү милдеттери кандай? Кантсе да, сен эмне үчүн бара жатканыңды түшүнүшүң керек жана акыры эмне кыласың, туурабы? Бүгүн мен Java иштеп чыгуучусу аткара турган он негизги милдет жөнүндө айткым келет. Бирок, алгач Jira сыяктуу курал менен таанышып алалы. Же эс тутумубузду жаңырталы, эгер ал сизге тааныш болсо. Jira кээ бир учурларда долбоорду башкаруу үчүн да колдонулат да, колдонуучу өз ара аракеттенүү куралы болуп саналат. Башка сөз менен айтканда, долбоорду иштеп чыгуу бул куралда сүрөттөлгөн кичинекей милдеттерге бөлүнөт. Бул тапшырмалар иштеп чыгуучуларга жүктөлөт (ыйгарылат), алар алардын аткарылышы үчүн жооптуу болушат. Тапшырмалар менен биз, мисалы, кандайдыр бир функцияларды кошууну билдирет. Прогресс жаралган сайын, иштеп чыгуучулар жана башка адистер ким эмне кылганы жана канча убакыт өткөргөндүгү тууралуу комментарийлерди кошот — алар убакытты көзөмөлдөп турушат. Бул сарпталган убакытты көзөмөлдөө үчүн жасалат: канча жана эмнеге жумшалды. Идеалында, бул бир күндө бир жолу жасалат: кечинде кетээрдин алдында сиз 8 саатыңызды кайсы иштерге жумшаганыңызга көз салып турасыз. Jira функционалдуулугу жогоруда айтылгандан алда канча кенен, бирок бул алгачкы түшүнүү үчүн жетиштүү болот. Ошентип, Java иштеп чыгуучунун милдеттери кандай?

1. Жаңы чечимдерди иштеп чыгуу

Бир нерсени жаратып, ишке ашыруудан мурун аны ойлоп табуу керек, туурабы? Мен айткандай, бул сизге жүктөлгөн Jira тапшырмасы болушу мүмкүн жана сиз Жирада канча убакыт жана эмнеге жумшаганыңызды белгилеп, жаңы чечимди иштеп чыгуу үчүн иштейсиз. Бул топтун чакыруусу боюнча да талкуу болушу мүмкүн: ар ким өз оюн айтып, эң жакшы деп эсептеген ыкманы сунуштай алат. Бул жерде мен бир нече пункттарды белгилегим келет. Биринчиден, иштеп чыгуучу кесип - бул абдан чыгармачыл тармак, анткени стандарттуу куралдарды колдонуу менен көйгөйлөрдү чечүүнүн уникалдуу жолдорун табышыңыз керек. Көбүнчө бир маселе ар кандай чечимдерге ээ болушу мүмкүн: ошого жараша бардыгы иштеп чыгуучунун "чыгармачыл рухуна", топтолгон бorмдер базасына жана тажрыйбасына жараша болот. Бул жерде сиз өзүңүздүн бардык чыгармачылыгыңызды жана генийиңизди көрсөтө аласыз, бирок эң башкысы аны аша чаппаңыз: бул учурда code өтө татаал жана окулбай калат жана натыйжада, сиз кеткенден кийин, анын эмне экенин эч ким толук түшүнбөйт. бул кантип иштейт. Жана баарын нөлдөн баштап кайра жазууга туура келет. Жана алар сени эстеп калышы мүмкүн. Жана бир нече жолу. Ал эми бул жылуу, жылуу сөздөр болушу күмөн. Бул сизге керекпи? Экинчиден, иштеп чыгуучу ийкемдүү болушу керек, анткени сиз бир чечимге тыгылып, башкаларга жабык болуп калбашыңыз керек. Окшош, сиз ушул жолду гана кылышыңыз керек жана башка эч нерсе жок. Бул ар кандай себептерден улам болушу мүмкүн: мисалы, сиз өз көз карашыңызды далилдөөнү каалайсыз, же сиз өзүңүздүн чечимиңизди иштеп чыгып, ишке ашырып койгонсуз, ага сиз абдан байлангансыз жана, албетте, бул туура эмес экенин моюнга алгыңыз келбейт. мыкты. Бул сизди дээрлик сокур кылып коюшу мүмкүн. Чынында, сиз өз каталарыңызды моюнга алып, ар дайым жаңы нерселерге ачык болушуңуз керек («ачык көз караш»), атүгүл сиз көп жумадан бери жазып жүргөн жана сиз сыймыктанган функцияларды алып салышыңыз керек. Бир жолу Жирадагы кимдир бирөөнүн убакыт треги бүткүл күндүн маанайын кантип жасаганы эсимде: “Мен өзүмдүн өлүү төрөлгөн функциямды өчүрдүм. Мен ыйладым"

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

Бул мурункудан кийинки логикалык кадам - ​​жаңы функцияны ишке ашыруу. Долбоордогу бардык иштер жирадагы тапшырмаларга бөлүнөт, аны иштеп чыгуучулар иштеп жатканда алышат. Бул маселеге ар кандай ыкмалар бар - "методологиялар", алар жөнүндө JavaRush боюнча ушул макаладан окуй аласыз . Эреже катары, тапшырмалар "Баалоо" бар - аяктоо үчүн болжолдонгон убакыт. Бул тапшырманы өзүңүз кабыл алганыңызда, же команданын лидери тарабынан белгиленет, же пландаштыруу учурунда иштеп чыгуучулар чогуу баалашат. Бул убакыт өтө сейрек так болжолдонот, анткени көптөгөн ар кандай факторлор өнүгүүгө таасир этет. Мисалы, программист бул технология менен таанышпы же бейтаанышпы, анын жалпы тажрыйбасы кандай, иштеп чыгуу учурунда көрүнүп турган ар кандай тузактар ​​ж.б. Ошондуктан, функцияларды иштеп чыгууда бул мөөнөттү аткарбасаңыз, эч кандай жаман нерсе болбойт. Бул жөн гана жалпы эсептөөлөр. Бирок, дагы бир жолу айта кетейин, бардык долбоорлордо тапшырмалардын сметасы жок жана мен үчүн ансыз жашоо бир топ жеңилдейт, айрыкча премьер-министр күнүгө бир-эки жолу “Эсептөөлөр кайда? ” Демек, сиз тапшырманы алып, керектүү функцияларды иштеп чыгып, аны GITтин жалпы фorалына жүктөйсүз жана жирада тапшырманын статусун "Карап чыгууга даяр" деп өзгөртөсүз , башкача айтканда, кароого (текшерүүгө) даяр жана дуба кыласыз. кайра карап чыгуу боюнча комментарийлер менен сизге кайтарылган эмес.

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

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

4. Мүчүлүштүктөрдү табуу жана оңдоо

Бул дагы Java иштеп чыгуучусу үчүн өтө кеңири таралган жана тез-тез тапшырма. QA жана AQA негизги милдети каталарды кармоо болуп саналат. Башкача айтканда, алар программа туура эмес иш алып барган жерлерди издеп, Жирада маселе жаратып, аны кимдир-бирөөгө жүктөшөт. Мисалы, команданын лидери, ал өз кезегинде системанын бул бөлүгү менен жүктөмүнө жана тааныштыгына жараша аны кайсы иштеп чыгуучуга дайындоону чечет. Андан кийин, иштеп чыгуучу мүчүлүштүктөрдү издейт, мүчүлүштүктөрдү оңдоочуда сааттарды коротуп , ката пайда болгон кырдаалды кайталоо үчүн QA адистеринин көйгөйдүн сыпаттамасын колдонот. Андан кийин, иштеп чыгуучу мүчүлүштүктөрдү таап, аны оңдоп, карап чыгууга жөнөтөт. Ооба, балким, иштеп чыгуучу мүчүлүштүктөрдү кайра чыгара албай калышы мүмкүн жана ал тапшырманы QA адисине бул тууралуу комментарий менен кайтарат. Мүчүлүштүктөрдү таап, оңдоо көп убакытты талап кылbyte окшойт, бирок кээ бир нюанстар бар. Баары, биринчи кезекте, иштеп чыгуучунун codeдун бул бөлүмү менен тааныштыгынан, теориялык маселелердин тажрыйбасынан жана бorминен көз каранды. Кээде мүчүлүштүктөрдү таап, 20 мүнөттө оңдоого болот, ал эми кээде үч күнгө созулушу мүмкүн. Демек, иштеп чыгуучу сыпаттаманы окуп чыккандан кийин эмне, кайда жана эмне менен ката кеткенин дароо түшүнбөсө, тапшырманын бул түрүн алдын ала баалоо өзгөчө кыйын. Бул учурда ал убакытты аздыр-көптүр так айта алат.

5. Кодду карап чыгуу

Жогоруда айтылгандай, сиз тапшырманы аткарарыңыз менен, ал карап чыгууга жөнөтүлүшү керек, эгер ал өтүп кетсе, жалпы темага өтөт, эгер жок болсо, иштеп чыгуучуга эмне кылуу керектиги боюнча комментарийлер менен кайтарылат. оңдолгон. Мунун баарын кандайдыр бир жогору турган күчтөр эмес, башка иштеп чыгуучулар текшерип жатканы түшүнүктүү. Бирок бардык иштеп чыгуучуларга рецензент болууга уруксат берилбейт, бирок алардын артында тажрыйбасы бар жана жаман codeду жакшыдан айырмалай алган эң тажрыйбалуу адамдар гана болушат. Кодду карап чыгуу, адатта, жардамчы куралдын жардамы менен жүргүзүлөт, мисалы, Crucible . Рецензенттер codeду карап чыгып, зарыл болсо, кээ бир саптардын астына комментарий калтырышат. Комментарийлер да ар түрдүү болушу мүмкүн. Мисалы, сынчылдар, аларды оңдоосуз рецензент codeду өткөрбөйт, жана башкалар, балким, иштеп чыгуучу угуп, көңүл буруп же көңүл бурбай турган тандалган ыкма жөнүндө жөн гана комментарийлер. Команда өзүнүн proceduresасын жана кароолорду жүргүзүү эрежелерин түзө алат, эмнеге көңүл буруу керек жана эмнеге болбойт, codeду кароо кайсы мөөнөттүн ичинде жүргүзүлүшү керек ж.б.у.с. Карап чыгуу үчүн, бир гана тажрыйба жетишсиз: сиз дагы эле техникалык багытта көп иштеп чыгуу, ар кандай китептерди окуу керек (мисалы, "Таза codeекс" ). Эгер сизди Google'га ылайык codeду карап чыгуунун нюанстары кызыктырса, мен сизге бул макаланы окууну сунуштайм .

6. Код анализи

Долбоор бир эле учурда башкача ойлонгон бир нече адам тарабынан жазылгандыктан, алардын codeу жана мамилеси ар башка болот. Убакыттын өтүшү менен баары акырындык менен былжырга айланат. Кодду жакшыртуу үчүн кээде сиз талдоо үчүн тапшырмаларды, балким, белгилүү бир модулду же бүтүндөй тиркемени түзүп, кемчorктерди таап, аларды белгилөө үчүн, кийинчерээк бул комментарийлердин негизинде рефакторинг тапшырмасын түзөсүз. Талдоо ошондой эле кээ бир жөнөкөй, жарлыктар иштеп чыгуунун башталышынан бери көрүнбөгөн, бирок аларды азыр көрүүгө болот. Мисалы, бир эле логика кээ бир методдордо көп кайталанат жана ошого жараша өзүнчө ыкмага өтүп, көп жолу кайталанып колдонулушу мүмкүн. Ооба, же кээ бир класстар катуу шишип кетти, же кээ бир codeду сактоо кыйын болуп калды же эскирип калды, же... Талдоо тапшырмалары codeдун жана тиркеменин сапатын жакшыртууга жардам берет. Менин оюмча, көп сандагы codeду талдоо кызыксыз иш болушу мүмкүн.

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

Анализдин кийинки бөлүгү codeду рефакторинг болуп саналат. Ал эскирген, кереги жок, начар жазылган, окууга кыйын ж.б. Сиз ар дайым кемчorксиздикке (ал жок болсо да) жана актуалдуу codeго умтулушуңуз керек, керексиз нерселердин баарын алып салыңыз, анткени бул бир гана чаташтырат жана функционалдуулуктун маңызын көрүүгө тоскоол болот. Долбоордун башында сиз бул милдеттерди көрө албайсыз: алар иштеп чыгуунун кийинки баскычтарында, тиркеме жылмаланган жана жеткилеңдикке жеткенде гана пайда болот. Бул жерде кесиптештер менен кеңешип, алар муну кантип жасашмак жана алар кандай тузактарды көрүп жатышканы туура болушу мүмкүн. Мындай милдеттердин маңызы жаңы функцияларды иштеп чыгууга окшош. Мисалы, сиз кээ бир функцияларды анын жүрүм-турумун өзгөртпөстөн түзөтүү тапшырмасын аласыз. Бул үчүн, сиз эскисин өчүрүп, өзүңүздүн жазыңыз жана тесттерди текшериңиз. Эгер сиз бардыгын туура кылган болсоңуз, тесттерге өзгөртүүлөрдү киргизбестен, алар мурункудай иштеши керек. Коддо баары чечилгенден кийин, биз аны карап чыгууга жөнөтөбүз жана кофе ичебиз))

8. Документтерди жазуу

Сиз көптөн бери иштеп келе жаткан долбоордун жаңы иштеп чыгуучусу экениңизди элестетиңиз. Сиз аны менен таанышыңыз же кандайдыр бир конкреттүү тапшырманы аткарышыңыз керек, мисалы, катаны кармоо. Долбоорду кантип башкарасыз? Ар бир беш мүнөт сайын командаңыздын мүчөлөрүн тартасызбы? Эгерде алар бош эмес же дем алыш күндөрү болсо, анда эмне кылыш керек? Мына ошондуктан documentация бар, бул функцияны билбеген адам кирип, керектүү баракты таап, колдонмонун аны кызыктырган бөлүгү эмне кылып жатканын тез түшүнө алат. Бирок кимдир бирөө ошондой эле documentтерди толтурушу керек ^^ Долбоордо иштеп чыгуучулар колдоого алышы керек болгон documentтер болсо, жаңы функцияларды ишке ашырууда алар аны сүрөттөп, ар кандай өзгөртүүлөр жана рефакторингтер менен documentацияны жаңыртышат. Документтерди жазуу, колдоо жана контролдоо үчүн өзүнчө адис, техникалык жазуучу жалданганда да жагдайлар болушу мүмкүн. Мындай адис бар болсо, бул жөнөкөй иштеп чыгуучулардын жашоосун бир аз жеңилдетет.

9. Ар кандай митингдерге катышуу

Иштеп чыгуучулар ар кандай жолугушууларга, сүйлөшүүлөргө жана пландаштырууга көп убакыт коротушат. Эң жөнөкөй мисал – “күнүмдүк жолугушуулар” (күнүмдүк жолугушуулар), анда сиз кечээ эмне кылганыңызды жана бүгүн эмне кыла турганыңызды айтып беришиңиз керек. Мындан тышкары, сиз, мисалы, QA адиси менен жекече чалуу керек, ал катаны кайра чыгаруунун нюанстарын көрсөтүп/түшүндүрүп, же бизнес-аналитик же уюштуруучулук менен нюанстарды жана талаптарды талкуулай алат. ПМ менен маселелер. Ошондуктан, иштеп чыгуучу жалгыздыкты жактырган интроверт болушу мүмкүн болсо да, ал дагы эле башка адамдар менен жалпы тил таба алышы керек (жакшы, бир аз болсо да). Иштеп чыгуучунун даражасы канчалык жогору болсо, ага баарлашууга көбүрөөк убакыт жана code жазууга азыраак убакыт керек. Иштеп чыгуучу топтун лидери жумуш убактысынын жарымын, атүгүл көбүрөөк бөлүгүн сүйлөшүүгө жана жолугушууларга жана codeду азыраак жазууга коротушу мүмкүн (бул бир аз кармап калууга алып келиши мүмкүн). Бирок, эгер сиз да сүйлөшкөндү жакшы көргөн адам болсоңуз, анда сиз команданын лидеринин позициясынан башкаруучулук тарапка оңой эле өнүгүп, ар кандай командалар, кардарлар жана башка менеджерлер менен эртеден кечке баарлашып, codeду таптакыр унута аласыз.

10. Интервью өткөрүү/өтүү

Эгерде сиз аутсорсинг же аутстаффинг компаниясында иштесеңиз, анда сиз кардарга “сатуу” керек болгондо (анда сизди кардар тараптан интервью алышыңыз мүмкүн) жана ички интервьюлардан тез-тезден өтүп туруңуз. компаниянын ичинде даражасын жогорулатуу. Мен муну өнүгүүнүн жакшы фактору деп атайт элем, анткени тез-тез маектешүүлөрдүн аркасында сиздин бorмиңиз дайыма калыпта болушу керек: дат басып, эс албайсыз, анткени IT тармагында эс алсаңыз, талаадан толугу менен учуп кете аласыз. Тажрыйбалуу иштеп чыгуучу болгондон кийин, сиз башка тарапка бара аласыз: өтпөстөн, интервьюларды өткөрүү. Мага ишенип коюңуз, эгер сиз буга ушундай көз караш менен карасаңыз, абдан таң каласыз, анткени интервьюларды өткөрүү өтүп кеткенден да коркунучтуу болушу мүмкүн. Сизде өзүңүздүн интервью стратегияңыз, суроолордун тизмеси болушу керек жана бир сааттын ичинде бардык керектүү темалар боюнча суроо берүүгө үлгүрүңүз. Ошондон кийин, сиз жооп кайтаруу үчүн жооп бересиз, анткени ага таянуу менен адам мындай көптөн күткөн сунушту же көтөрүлүүнү алышы мүмкүн же албашы мүмкүн. Ооба, жана тескерисинче: сиз ачык эле алсыз талапкерди ал туура келбеген кызматка өткөрүп жиберсеңиз болот, анан сизден: мындай бorм деңгээли менен аны кантип сагындыңыз? Андыктан, интервью берип жатып, сизге каршы турган адам да кыйналып жатканын, ал да стресске дуушар болушу мүмкүн экенин унутпаңыз. Ар кандай интервью талапкер үчүн да, интервью алуучу үчүн да стресс. Балким ушул жерден бүтүрөбүз. Окууну бүтүргөндөрдүн баарына рахмат: жактыруу жана Java үйрөнүү ^^