Layihə üzrə Java tərtibatçısının tipik vəzifələri

Java tərtibatçısının tipik vəzifələri hansılardır? Axı, nə üçün getdiyinizi və sonunda nə edəcəyinizi başa düşməlisiniz, elə deyilmi? Bu gün mən Java tərtibatçısının yerinə yetirdiyi on əsas vəzifə haqqında danışmaq istərdim. Ancaq əvvəlcə Jira kimi bir alətlə tanış olaq. Və ya sizə artıq tanışdırsa, yaddaşınızı təzələyək. Jira istifadəçi ilə qarşılıqlı əlaqə vasitəsidir, baxmayaraq ki, bəzi hallarda layihənin idarə edilməsi üçün də istifadə olunur. Başqa sözlə, layihənin inkişafı bu alətdə təsvir olunan kiçik tapşırıqlara bölünür. Bu vəzifələr onların həyata keçirilməsinə cavabdeh olacaq tərtibatçılara verilir (təyin olunur). Tapşırıqlar dedikdə, məsələn, bəzi funksionallıq əlavə etməyi nəzərdə tuturuq. Tərəqqi irəlilədikcə, tərtibatçılar və digər mütəxəssislər kimin nə etdiyi və nə qədər vaxt keçirdikləri barədə şərhlər əlavə edirlər - vaxtı izləyirlər. Bu, sərf olunan vaxtı izləmək üçün edilir: nə qədər və nəyə xərclənib. İdeal olaraq, bu, gündə bir dəfə edilir: axşam yola düşməzdən əvvəl, 8 saatınızı sərf etdiyiniz vəzifələrə qədər izləyirsiniz. Jira-nın funksionallığı yuxarıda təsvir ediləndən daha genişdir, lakin bu, ilkin anlayış üçün kifayət edəcəkdir. Beləliklə, Java tərtibatçısının məsuliyyəti nədir?

1. Yeni həllərin işlənib hazırlanması

Nəyisə yaratmadan və həyata keçirməzdən əvvəl onu fikirləşmək lazımdır, elə deyilmi? Dediyim kimi, bu, sadəcə olaraq sizə tapşırılacaq bir Jira tapşırığı ola bilər və siz Jira-da nə qədər vaxt sərf etdiyinizi və nəyə sərf etdiyinizi qeyd edərək, yeni bir həll hazırlamaq üçün çalışacaqsınız. Bu, həmçinin qrup komanda çağırışı zamanı müzakirə ola bilər: hər kəs öz fikrini ifadə edə və ən yaxşı hesab etdiyi yanaşmanı təklif edə biləcək. Və burada bir neçə məqamı qeyd etmək istərdim. Birincisi, tərtibatçı peşəsi çox yaradıcı bir sahədir, çünki standart vasitələrdən istifadə edərək problemləri həll etmək üçün unikal yollar tapmalısınız. Çox vaxt bir problemin bir çox fərqli həlli ola bilər: müvafiq olaraq, hər şey tərtibatçının "yaradıcı ruhundan", yığılmış bilik bazasından və təcrübəsindən asılıdır. Burada bütün yaradıcılığınızı və dahiliyinizi göstərə bilərsiniz, amma əsas odur ki, onu aşma: bu halda kod çox mürəkkəb və oxunmaz olacaq və nəticədə siz ayrıldıqdan sonra heç kim bunun nə olduğunu tam başa düşməyəcək və bu necə işləyir. Və hər şeyi sıfırdan yenidən yazmalı olacaqsınız. Və səni xatırlaya bilərlər. Və bir dəfədən çox. Və bu, çətin ki, isti, xoş sözlər olsun. Bu sizə lazımdır? İkincisi, tərtibatçı o mənada çevik olmalıdır ki, bir həlldə ilişib qalmamalı və başqalarına qapanmamalısınız. Necə ki, yalnız bu şəkildə etməlisiniz və başqa heç nə etməməlisiniz. Bu, müxtəlif səbəblərə görə baş verə bilər: məsələn, öz nöqteyi-nəzərini sübut etmək istəyirsən və ya kifayət qədər bağlı olduğunuz həllinizi artıq işləyib hazırlamısınız və həyata keçirmisiniz və əlbəttə ki, bunun heç bir problem olmadığını etiraf etmək istəmirsiniz. ən yaxşı. Bu sizi demək olar ki, kor edə bilər. Əslində, səhvlərinizi etiraf etməyi bacarmalı və hər zaman yeni şeylərə (“açıq fikirli”) açıq olmalısınız, hətta həftələrdir yazdığınız və çox qürur duyduğunuz funksionallığı silməli olsanız belə. Yadımdadır, bir dəfə Jirada kiminsə vaxt izi bütün günün əhval-ruhiyyəsini belə şərh etdi: “Ölü doğulmuş funksionallığımı sildim. Ağladım"

2. Yeni funksionallığın yazılması

Bu, əvvəlkindən sonrakı məntiqi addımdır - yeni funksionallığın həyata keçirilməsi. Layihə üzrə bütün işlər tərtibatçılar işləyərkən aldıqları jira-da tapşırıqlara bölünür. Bu məsələyə müxtəlif yanaşmalar var - "metodologiyalar", daha çox JavaRush-da bu məqalədə oxuya bilərsiniz . Bir qayda olaraq, tapşırıqların "Təxminləri" var - tamamlanmağa sərf olunan proqnozlaşdırılan vaxt. Tapşırığı öz üzərinizə götürəndə ya özünüz təyin edirsiniz, ya da komandanın rəhbəri, ya da planlaşdırma zamanı tərtibatçılar birlikdə onu qiymətləndirirlər. Bu vaxt çox nadir hallarda dəqiq təxmin edilir, çünki inkişafa bir çox müxtəlif amillər təsir göstərir. Məsələn, proqramçı bu texnologiya ilə tanışdır, yoxsa tanış deyil, onun ümumi təcrübəsi nədir, inkişaf zamanı artıq görünə biləcək müxtəlif tələlər və s. Buna görə də, funksionallığı inkişaf etdirərkən bu son tarixə əməl etməsəniz, pis bir şey olmayacaq. Bunlar sadəcə ümumi hesablamalardır. Ancaq yenə də bütün layihələrin tapşırıq smetaları yoxdur və mənim üçün onsuz yaşamaq daha asandır, xüsusən də baş nazir gündə bir neçə dəfə “Təxminlər haradadır? ” Müvafiq olaraq, bir tapşırığı götürürsən, lazımi funksionallığı inkişaf etdirirsən, onu GIT -də ümumi bir filiala yükləyirsən və jirada tapşırığın statusunu "İzlənməyə hazırdır" , yəni baxmağa (yoxlamağa) hazırdır və dua edirsən. revizyona dair şərhlərlə sizə qaytarılmır.

3. Funksionallıq üçün testlərin yazılması

Kodunuzu yoxlayan şəxs - rəyçi - hazırladığınız funksionallığı bəyəndi, lakin onun bir sualı var: bunun üçün testlər haradadır? Və tapşırığı yoxlamaq üçün sizə qaytarır. Testlər istənilən Java proqramının vacib hissəsidir. Onları işə salmaqla, tətbiqin səhv işlədiyi yeri dərhal tuta bilərsiniz. Məsələn, bir tərtibatçı sistemin bir hissəsində bəzi dəyişikliklər etdi, bu da digərində davranış dəyişikliklərinə səbəb oldu və inkişaf zamanı bunu hiss etmədi. Testləri həyata keçirməklə o, uğursuz (düzgün işləməmiş) testləri görə biləcək. Bu, ona sistemin başqa bir hissəsində nəyinsə pozulduğunu deyəcək. Buna görə də, o, serverə pozucu dəyişiklikləri yükləməyəcək, lakin həllini təkmilləşdirməyə davam edəcək. Bəli, əlbəttə ki, bir neçə tərtibatçı testləri sevir, lakin onların tətbiqə gətirdiyi faydaları inkar etmək olmaz. Çox vaxt müştərilər özləri test əhatəsinin hansı səviyyəsinə riayət edilməli olduğunu müəyyənləşdirirlər (məsələn, 80%). Ona görə də müxtəlif test növlərini bilməli və onları yazmağı bacarmalısan. Java tərtibatçıları əsasən vahid testləri və inteqrasiya testləri yazır, AQA (avtomatlaşdırma testçiləri) isə daha geniş (son-to-end) testlərlə məşğul olurlar. Onlar və İT peşələrinin digər nümayəndələri haqqında daha çox oxuya bilərsiniz .

4. Səhvlərin tapılması və aradan qaldırılması

Bu, həm də Java tərtibatçıları üçün çox ümumi və tez-tez görülən işdir. QA və AQA-nın əsas vəzifəsi səhvləri tutmaqdır. Yəni proqramın səhv apardığı yerləri axtarırlar, Jirada problem yaradırlar və bunu kiminsə üzərinə yıxırlar. Məsələn, yükündən və sistemin bu hissəsi ilə tanışlığından asılı olaraq, öz növbəsində bunu hansı tərtibatçıya təyin edəcəyinə qərar verən komanda rəhbəri. Bundan sonra, tərtibatçı səhvin baş verdiyi vəziyyəti təkrarlamaq üçün QA mütəxəssisləri tərəfindən problemin təsvirindən istifadə edərək, sazlayıcıda saatlar sərf edərək səhvi axtarır. Sonra, tərtibatçı bir səhv tapır, onu düzəldir və nəzərdən keçirmək üçün göndərir. Yaxşı, ola bilər ki, tərtibatçı səhvi təkrarlaya bilmədi və o, bu barədə şərh ilə tapşırığı QA mütəxəssisinə qaytarır. Görünür, səhvi tapmaq və düzəltmək o qədər də uzun çəkməyəcək, lakin bəzi nüanslar var. Hər şey ilk növbədə tərtibatçının kodun bu bölməsi ilə tanışlığından, təcrübəsindən və nəzəri məsələlərin biliyindən asılıdır. Bəzən səhv 20 dəqiqə ərzində tapılıb aradan qaldırıla bilər, bəzən isə üç gün çəkə bilər. Müvafiq olaraq, tərtibatçı təsviri oxuduqdan sonra nəyin, harada və nə ilə səhv getdiyini dərhal başa düşməsə, bu cür tapşırığı əvvəlcədən qiymətləndirmək xüsusilə çətindir. Bu zaman o, vaxtı az-çox dəqiq təxmin edə biləcək.

5. Kodun nəzərdən keçirilməsi

Yuxarıda qeyd edildiyi kimi, bir tapşırığı yerinə yetirən kimi onu nəzərdən keçirmək üçün göndərmək lazımdır və onu keçərsə, ümumi mövzuya keçir, yoxsa, nə edilməli olduğu barədə şərhlərlə tərtibatçıya qaytarılacaqdır. düzəldildi. Aydındır ki, bütün bunlar hansısa yüksək qüvvələr tərəfindən yox, digər tərtibatçılar tərəfindən yoxlanılır. Lakin bütün tərtibatçılara rəyçi olmağa icazə verilmir, ancaq onların arxasında təcrübəsi olan və pis kodu yaxşıdan ayıra bilən ən təcrübəli olanlar. Kodun nəzərdən keçirilməsi adətən köməkçi alətdən istifadə etməklə həyata keçirilir, məsələn, Crucible . Rəyçilər kodu nəzərdən keçirir və lazım gələrsə, bəzi sətirlərin altında şərhlər buraxırlar. Şərhlər də müxtəlif növ ola bilər. Məsələn, tənqidi olanlar, düzəliş etmədən rəyçi kodu keçməyəcək, digərləri isə daha çox seçilmiş yanaşma haqqında şərhlərdir, tərtibatçı onları dinləyə, qeyd edə və ya görməməzliyə vura bilər. Komanda nəzərdən keçirmək üçün öz prosedurunu və qaydalarını yarada bilər, nəyə diqqət yetirməyə dəyər və nəyə yox, kodun nəzərdən keçirilməsinin hansı müddət ərzində aparılmalı olduğunu və s. Baxış aparmaq üçün təkcə təcrübə kifayət deyil: hələ də texniki istiqamətdə çox şey inkişaf etdirməli, müxtəlif kitablar oxumalısan (məsələn, “Təmiz Kod” ). Google-a uyğun olaraq kodun nəzərdən keçirilməsinin nüansları ilə maraqlanırsınızsa, bu məqaləni oxumağı məsləhət görürəm .

6. Kod təhlili

Layihə eyni vaxtda fərqli düşünən bir neçə şəxs tərəfindən yazıldığı üçün onların kodu və yanaşmaları fərqli olacaq. Və zaman keçdikcə hər şey tədricən muşa çevriləcək. Kodu təkmilləşdirmək üçün bəzən siz, bəlkə də müəyyən modulu və ya bütün tətbiqi təhlil etmək, çatışmazlıqları tapmaq və onları qeyd etmək üçün tapşırıqlar yaradırsınız və sonra bu şərhlər əsasında refaktorinq tapşırığı yaradırsınız. Təhlil, bəzi daha sadə, qısa yolların inkişafın əvvəlindən görünmədiyi, lakin indi göründüyü vəziyyətlərdə də kömək edir. Məsələn, bəzi üsullarda eyni məntiq tez-tez təkrarlanır və müvafiq olaraq, ayrı bir üsula köçürülə və dəfələrlə təkrar istifadə edilə bilər. Yaxşı, ya bəzi siniflər ağrılı şəkildə şişirdi, ya da bəzi kodu saxlamaq çətinləşdi və ya köhnəldi, ya da... Təhlil tapşırıqları kodun və tətbiqin keyfiyyətini yaxşılaşdırmağa kömək edir. Baxmayaraq ki, mənim fikrimcə, böyük miqdarda kodu təhlil etmək darıxdırıcı bir iş ola bilər.

7. Kod refaktorinqi

Təhlilin növbəti hissəsi kodun refaktorinqidir. O, köhnəlmiş, lazımsız, zəif yazılmış, oxunması çətin və s. ola bilər. Siz həmişə mükəmməlliyə (bu mövcud olmasa da) və lazımsız hər şeyi silərək aktual kod əldə etməyə çalışmalısınız, çünki bu, yalnız çaşqınlıq yaradır və funksionallığın mahiyyətini görməyə mane olur. Sözsüz ki, bu tapşırıqları layihənin əvvəlində görmək ehtimalı azdır: onlar yalnız inkişafın sonrakı mərhələlərində, tətbiq cilalandıqda və mükəmməlliyə gətirildikdə baş verir. Burada həmkarları ilə bunu necə edəcəkləri və gördükləri tələlər barədə məsləhətləşmək məqsədəuyğun ola bilər. Bu cür tapşırıqların mahiyyəti yeni funksionallığın inkişafına bənzəyir. Məsələn, bəzi funksionallığı onun davranışını dəyişmədən redaktə etmək tapşırığı alırsınız. Bunun üçün köhnəni silirsən, özünü yazırsan və testləri yoxlayırsan. Hər şeyi düzgün etmisinizsə, testlərdə dəyişiklik etmədən onlar əvvəlki kimi işləməlidirlər. Hər şey kodda həll edildikdən sonra onu nəzərdən keçirməyə və qəhvə içməyə göndəririk))

8. Sənədlərin yazılması

Təsəvvür edin ki, siz uzun müddətdir inkişafda olan hansısa layihədə yeni tərtibatçısınız. Bununla tanış olmalısınız və ya müəyyən bir tapşırıq yerinə yetirməlisiniz, məsələn, bir səhv tutmaq. Layihəni necə idarə edəcəksiniz? Komanda üzvlərinizi hər beş dəqiqədən bir çəkin? Və əgər onlar məşğuldursa və ya həftə sonu, onda necə? Buna görə sənədlər mövcuddur ki, funksionallıqla tanış olmayan şəxs daxil ola bilsin, lazımi səhifəni tapsın və tətbiqin onu maraqlandıran hissəsinin nə etdiyini tez anlaya bilsin. Amma kimsə sənədləri də doldurmalıdır ^^ Əgər layihədə tərtibatçıların dəstəkləməli olduğu sənədlər varsa, yeni funksionallıq tətbiq edərkən onlar onu təsvir edir və müxtəlif dəyişikliklər və refaktorinqlərlə sənədləri yeniləyirlər. Sənədləri yazmaq, dəstəkləmək və nəzarət etmək üçün ayrıca bir mütəxəssis, texniki yazıçı işə götürüldükdə də vəziyyətlər mümkündür. Belə bir mütəxəssis varsa, adi tərtibatçıların həyatını bir az asanlaşdırır.

9. Müxtəlif mitinqlərdə iştirak

Tərtibatçılar müxtəlif görüşlərə, danışıqlara və planlaşdırmağa çox vaxt sərf edirlər. Ən sadə nümunə “gündəlik görüşlər”dir (gündəlik görüşlər), burada dünən nə etdiyinizi və bu gün nə edəcəyinizi söyləmək lazımdır. Bundan əlavə, məsələn, QA mütəxəssisi ilə təkbətək zəng etməlisiniz ki, o, səhvin təkrar istehsalının nüanslarını göstərə / izah edə və ya biznes analitiki və ya təşkilati ilə nüansları və tələbləri müzakirə edə bilsin. PM ilə problemlər. Buna görə də, tərtibatçı təkliyə üstünlük verən introvert ola bilsə də, yenə də digər insanlarla ortaq dil tapa bilməlidir (yaxşı, heç olmasa bir az). Tərtibatçının rütbəsi nə qədər yüksək olarsa, o, ünsiyyətə daha çox vaxt və kod yazmağa daha az vaxt sərf etməlidir. Tərtibatçı-komanda rəhbəri hətta iş vaxtının yarısını, hətta daha çoxunu söhbətlərə və görüşlərə və daha az tez-tez kod yazmağa sərf edə bilər (bu, bir az tutuşun itirilməsinə səbəb ola bilər). Amma siz həm də danışmağı sevən birisinizsə, komanda rəhbəri vəzifəsindən idarəçi tərəfə asanlıqla inkişaf edə və bütün günü müxtəlif komandalar, müştərilər və digər menecerlərlə ünsiyyət quraraq kodu tamamilə unuda bilərsiniz.

10. Müsahibənin keçirilməsi/keçirilməsi

Əgər siz autsorsinq və ya autstaffinq şirkəti üçün işləyirsinizsə, müştəriyə “satılmalı” lazım olduqda tez-tez xarici müsahibələrdən və daxili müsahibələrdən keçməli olacaqsınız. şirkət daxilində dərəcənizi artırın. Mən bunu inkişaf üçün yaxşı amil adlandırardım, çünki tez-tez müsahibələrə görə bilikləriniz həmişə formada olmalıdır: siz paslanmayacaq və dincəlməyəcəksiniz, çünki İT-də istirahət etsəniz, sahədən tamamilə uça bilərsiniz. Daha təcrübəli bir tərtibatçı olduqda, qarşı tərəfə baş çəkə biləcəksiniz: keçmək deyil, müsahibələr aparmaq. İnanın, bu prizmadan baxsanız, çox təəccüblənəcəksiniz, çünki müsahibə aparmaq ötüb keçməkdən daha qorxulu ola bilər. Sizin öz müsahibə strategiyanız, sualların siyahısı olmalı və bir saat ərzində bütün lazımi mövzularda sual verməyə vaxtınız olmalıdır. Və bundan sonra geribildirim üçün cavabdehlik daşıyırsınız, çünki ona güvənərək, bir insan belə çoxdan gözlənilən təklif və ya təşviqi ala və ya almaya bilər. Yaxşı, və əksinə: açıq şəkildə zəif bir namizədi uyğun olmadığı bir vəzifə üçün əldən verə bilərsiniz və sonra sizdən soruşulacaq: belə bir bilik səviyyəsi ilə necə darıxdınız? Odur ki, müsahibədən keçərkən nəzərə alın ki, qarşınızdakı insan da çətin günlər keçirir və o da stress yaşayır. İstənilən müsahibə həm namizəd, həm də müsahibə götürən şəxs üçün streslidir. Bəlkə burada bitirək. Oxumağı bitirən hər kəsə təşəkkürlər: bəyənin və Java öyrənin ^^