A Java fejlesztő tipikus feladatai egy projekten

Melyek a Java fejlesztők tipikus feladatai? Végül is meg kell értened, hogy mibe keveredsz, és mit fogsz végül csinálni, igaz? Ma tíz létfontosságú feladatról szeretnék beszélni, amelyeket egy Java fejlesztő végez. De először ismerkedjünk meg a Jira nevű eszközzel. Vagy frissítse fel az emlékezetét, ha már ismeri. Jiraemberi interakciók szervezésének eszköze, bár bizonyos esetekben projektmenedzsmentre is használják. Más szavakkal, a projektet kis feladatokra bontják, amelyeket ebben az eszközben ismertetünk. Ezeket a feladatokat a fejlesztők kapják, akik felelősek azok megvalósításáért. Egy feladat lehet például néhány funkció hozzáadása. A feladat végrehajtása során a fejlesztők és más szakemberek megjegyzéseket fűznek hozzá, hogy ki mit csinált és mennyi időt töltött el. Ez időkövetési célból történik – hogy megtudjuk, milyen feladatokra mennyi időt fordítottak. Ideális esetben ez naponta egyszer történik: Mielőtt este elhagyná az íróasztalt, jelezze, hogy 8 munkaórájából mennyit fordított különféle feladatokra. A Jira funkcionalitása sokkal többről szól, mint amit fent leírtunk, de ez elegendő lesz a kezdeti megértéshez.

1. Új megoldások tervezése

Mielőtt létrehozol és megvalósítasz valamit, meg kell fogalmaznod azt, igaz? Ahogy korábban is mondtam, ez egyszerűen egy olyan feladat lehet a Jira-ban, amelyet rád bíznak, tehát új megoldás tervezésén dolgozol, rögzítve a Jira-ban, hogy mennyi időt töltöttél el és mire. Ez a munka egy csoportkonferencia beszélgetés során is megtörténhet: mindenki elmondhatja véleményét és javaslatot tehet az általa legjobbnak tartott megközelítésre. És itt szeretnék megjegyezni néhány pontot. Először is, a szoftverfejlesztés egy nagyon kreatív szakma, mivel szabványos eszközöket kell használnia ahhoz, hogy újszerű megoldási módokat találjon ki a problémákra. Egy feladatnak gyakran több különböző megoldása is lehet. Ennek megfelelően minden a fejlesztő kreativitásán múlik, amelyet erősen befolyásol a felhalmozott tudás és tapasztalat. Itt megmutathatod kreativitásodat és zsenialitásodat, de az a fontos, hogy ne vigyük túlzásba. Ha megteszi, a kód túl bonyolult és olvashatatlan lesz. Ennek eredményeként távozása után senki sem fogja teljesen megérteni, hogy mit kódolt és hogyan működik. És mindent a nulláról kell átírniuk. És emlékezhetnek rád. Több mint egyszer. És nem valószínű, hogy meleg, kedves szavakat fognak kiejteni. Ez kell neked? Másodszor, a fejlesztőnek meg kell őriznie pszichológiai rugalmasságát abban az értelemben, hogy ne ragaszkodjon egyetlen megoldáshoz, és ne váljon zárkózottá mások iránt. Mintha csak egy módon kell valamit csinálni, és nem lenne más lehetőség. Különféle okok miatt eshet ebbe a csapdába. Tegyük fel például, hogy be akarja bizonyítani, hogy álláspontja helyes. Vagy talán már megtervezte és megvalósította a saját ismerős megoldását – természetesen, nem akarod beismerni, hogy nem a legjobb. Ezek a helyzetek meglehetősen vakká tehetnek. Valójában képesnek kell lennie beismerni a hibáit, és mindig nyitottnak kell lennie, még akkor is, ha el kell távolítania azokat a funkciókat, amelyekre büszke, és már több mint egy hete kódol. Emlékszem, hogy egy munkatárs egyszer mindenki napját feldobta azzal, hogy ezt az időkövető megjegyzést hagyta a Jira-ban: – Eltávolítottam a halva született arcvonásomat. És gyászoltam.

2. Új funkcionalitás írása

Ez a lépés – az új funkcionalitás megvalósítása – logikusan követi az előzőt. A projektben részt vevő összes munka a Jira-ban feladatokra van felosztva, amelyeket aztán a munkaterhelésük alapján osztanak ki a fejlesztőknek. Ennek a folyamatnak különböző megközelítései vannak, amelyeket "módszertanként" ismerünk, amelyekről részletesebben a CodeGym ezen cikkében olvashat . A feladatoknak általában becslésük van, ami a végrehajtásukhoz szükséges előre jelzett idő. Ezt vagy Ön, a fejlesztő állítja be, amikor megkapja a feladatot, vagy a csapatvezető, vagy a tervezés során, közösen a fejlesztőcsapat. Ez az időbecslés nagyon ritkán pontos, mivel nagyon sok különböző tényező befolyásolja a szoftverfejlesztést. Például, hogy egy programozó ismeri-e vagy nem ismeri a vonatkozó technológiát, általános tapasztalatait, különféle előre nem látható buktatókat stb. Tehát, ha nem üti el az összes időbecslést a kódolás során, az még nem a világ vége. Ezek csak általános becslések. Ennek ellenére nem minden projekt igényel időbecslést. Én személy szerint sokkal könnyebben élek nélküle, különösen, ha a miniszterelnök nem zaklat naponta párszor azzal a kérdéssel, hogy "hol vannak az időbecslései?" Tehát kap egy feladatot,Felülvizsgálatra készen a Jira-ban, és imádkozz, hogy a kódmódosításokat ne küldjék vissza felülvizsgálatra a megjegyzésekkel együtt.

3. Írásbeli tesztek

A felülvizsgálónak, vagyis annak, aki ellenőrzi a kódot, tetszik az Ön által megvalósított funkcionalitás, de van egy kérdése Önhöz: hol vannak a kapcsolódó tesztek? Tehát visszaküldi neked a feladatot felülvizsgálatra. A tesztek minden Java-alkalmazás elengedhetetlen részét képezik. A tesztek futtatásával azonnal azonosíthatja azokat a helyeket, ahol az alkalmazás nem működik megfelelően. Például egy fejlesztő végrehajt néhány változtatást a rendszer egyik részében, ami egy másik rész viselkedésében is megváltozik, de ezt nem vette észre kódolás közben. A tesztek futtatásával láthatja, hogy bizonyos tesztek kudarcot vallottak, vagyis nem a várt eredményeket hozták. Ez azt jelzi neki, hogy valami elromlott valahol máshol a rendszerben. Ennek tudatában nem hajtja végre a törő változtatásokat a szerveren, hanem folytatja a kódja hibakeresését. Igen, meglehetősen kevés fejlesztő szeret teszteket írni, de tagadhatatlan, hogy azok milyen előnyökkel járnak a szoftverfejlesztésben. Az ügyfelek gyakran maguk is jelzik, hogy milyen szintű tesztlefedettséget szeretnének fenntartani (például 80%). Ez azt jelenti, hogy tudnia kella különböző típusú teszteket , és képes legyen megírni azokat. A Java fejlesztők főként egységteszteket és integrációs teszteket írnak, míg a kiterjedtebb (end-to-end) teszteket minőségbiztosítási és tesztautomatizálási szakértők végzik.

4. Hibák keresése és javítása

Ez is nagyon gyakori, gyakori feladat a Java fejlesztők számára. A minőségbiztosítási és tesztautomatizálási szakértők fő feladata a hibák feltárása. Más szóval, megkeresik azokat a helyeket, ahol a program hibásan működik, majd a Jira-ban feladatokat hoznak létre, és kiosztják azokat valakinek. Például egy csapatvezetőnek, aki viszont eldönti, hogy melyik fejlesztőhöz rendeli őket, attól függően, hogy milyen leterheltségük és a rendszer megfelelő részeit ismerik. Ezt követően a kijelölt fejlesztő felkutatja a hiba kiváltó okát, órákat töltve a hibakeresőben ., a minőségbiztosítási szakértők által biztosított hibaleírás segítségével reprodukálja azokat a körülményeket, ahol a hiba előfordul. Miután a fejlesztő megtalálta a hibát, és kijavította, elküldi a javítást felülvizsgálatra. Előfordul, hogy a fejlesztő nem tudja reprodukálni a hibát, ezért visszaküldi a feladatot a minőségbiztosítási szakértőnek egy magyarázó megjegyzéssel együtt. Úgy tűnik, nem kell sokáig tartania egy hiba megtalálásának és kijavításának, de van néhány árnyalat. Minden elsősorban azon múlik, hogy a fejlesztő mennyire ismeri a kód ezen részét, valamint a tapasztalataitól és elméleti tudásától. Néha egy hibát 20 perc alatt lehet megtalálni és kijavítani, néha pedig három napig is eltarthat. Ez azt jelenti, hogy az ilyen típusú feladatokat különösen nehéz előre megbecsülni, kivéve, ha a fejlesztő a leírás elolvasása után azonnal megérti, hogy mit, hol és hogyan tartalmaz a hiba. Ebben az esetben,

5. Kód felülvizsgálata

Ahogy fentebb említettük, amint befejez egy feladatot, el kell küldeni felülvizsgálatra. Ha átmegy a felülvizsgálaton, akkor a fő ágba kerül. Ha nem, akkor visszaküldi a fejlesztőnek a megjegyzésekkel, amelyekkel foglalkozni kell. Természetesen tisztában van azzal, hogy a kódot a többi fejlesztő ellenőrzi, nem pedig valami nagy hatalom. Ennek ellenére nem mindenki végezhet kódellenőrzést – csak a legtapasztaltabb fejlesztők, akik megedzettek a valós gyakorlatban, és akik különbséget tudnak tenni a jó és a rossz kód között. A kódellenőrzés általában segédeszköz, például a Crucible segítségével történik. A lektorok végigmennek a kódon, és ha szükséges, megjegyzéseket fűznek bizonyos sorokhoz. Különféle megjegyzések lehetnek. Például néhányan kritikusak. Ha nem foglalkoznak velük, akkor az ellenőr nem engedélyezi a kód véglegesítését. A többi megjegyzés mondjuk egyszerűen megjegyzések a választott megközelítéshez. Ezeket a fejlesztő meghallgathatja, tudomásul veheti vagy figyelmen kívül hagyhatja. A csapat létrehozhatja saját szabályait és eljárásait a kódellenőrzéshez, megállapodva abban, hogy mire érdemes odafigyelni és mire nem, milyen időkeretet kell szánni a kódellenőrzés elvégzésére stb. A tapasztalat önmagában nem elegendő a felülvizsgálat elvégzéséhez: továbbra is sokat kell fejlődnie technikai készségei terén, és különféle könyveket kell olvasnia (például "Clean Code").

6. Kódelemzés

Mivel többen, akik eltérően gondolkodnak, egyszerre írnak kódot a projekthez, a kódjuk és a megközelítésük eltérő lesz. És idővel minden fokozatosan káoszba fordul. A kód fejlesztése érdekében néha olyan feladatokat készítenek, amelyek mondjuk egy adott modult vagy az egész alkalmazást elemeznek, a hiányosságokat megtalálják és tudomásul veszik, majd az elemzés alapján később létrehoznak egy refaktorálási feladatot. Az ilyen elemzés olyan helyzetekben is segít, ahol a fejlesztés megkezdésekor a csapat nem látott egyszerűbb, tömörebb megoldásokat, de most már látja. Például a logika gyakran megkettőződik egyes módszerekben. Ennek megfelelően külön módszerré kinyerhető, amit aztán sokszor újra felhasználhatunk. Vagy lehet, hogy egy osztály túlságosan feldagadt, vagy valamilyen kód nehezen karbantartható vagy elavult lett, vagy... Az elemzési feladatok segítenek a kód és az alkalmazás minőségének javításában. Ennek ellenére számomra unalmas lehet nagy mennyiségű kód elemzése.

7. Refaktorálási kód

A kódelemzés következő része az újrafaktorálás. A kód lehet elavult, elavult, rosszul megírt, nehezen olvasható stb. Mindig törekedni kell a tökéletességre (bár az nem létezik) és a naprakész kódra, eltávolítva a felesleges dolgokat, mert a felesleges csak zűrzavart okoz, és megzavarja a kód működését. Magától értetődik, hogy nem valószínű, hogy egy projekt elején látni fogja ezeket a feladatokat: a fejlesztés későbbi szakaszaiban találkozik velük, amikor az alkalmazást csiszolják és tökéletesítik. Itt érdemes lehet konzultálni a munkatársakkal arról, mit tennének, és milyen buktatókat látnak. Az ilyen feladatok lényegükben az új funkciók fejlesztéséhez hasonlítanak. Tegyük fel például, hogy olyan feladatot kap, amely szerkeszteni szeretne bizonyos funkciókat anélkül, hogy megváltoztatná a viselkedését. Ehhez törölje a régi kódot, írja meg a sajátját, és ellenőrizze a teszteket. Ha mindent jól csinált, akkor a tesztek módosítása nélkül mindegyiknek át kell mennie, mint korábban. Miután a kódban minden úgy van ahogy kell, elküldjük áttekintésre, és megyünk egy kávét kortyolgatni :)

8. Dokumentáció írása

Képzelje el, hogy Ön egy új fejlesztő egy hosszú távú szoftverfejlesztési projektben. Meg kell ismerkednie a kódbázissal, vagy végre kell hajtania valamilyen konkrét feladatot, például diagnosztizálnia kell egy hibát. Hogyan fog navigálni a projektben? Öt percenként megzavarja csapattársait? És mi van, ha elfoglaltak, vagy hétvége van, mi van akkor? Pontosan ezért rendelkezünk dokumentációval – hogy a kódot nem ismerő személy bejöhessen, megtalálja a megfelelő oldalt, és gyorsan kitalálja, mi történik az alkalmazás őt érdeklő részében. De valakinek elkészítenie kell a dokumentációt, haha. Ha egy projekt rendelkezik olyan dokumentációval, amelyet a fejlesztőknek támogatniuk kell, akkor új funkciók bevezetésekor leírják azt, és frissítik a dokumentációt a kódmódosításokkal vagy átalakításokkal együtt. Előfordulhatnak olyan helyzetek is, amikor egy külön alkalmazottat – egy műszaki írót – alkalmaznak a dokumentáció megírására, karbantartására és felügyeletére. Ha van ilyen szakember, a hétköznapi fejlesztők élete egy kicsit könnyebb.

9. Különféle találkozók

A fejlesztők sok idejét különféle megbeszélésekre, tárgyalásokra, tervezésre fordítják. A legegyszerűbb példa a napi stand-up értekezlet, ahol be kell számolnod, mit csináltál tegnap és mit fogsz csinálni ma. Ezenkívül személyes telefonhívásokat kell folytatnia, például a tesztelőkkel, hogy bemutassák/elmagyarázhassák a hiba reprodukálásának árnyalatait, vagy megvitassák a finomságokat és követelményeket egy üzleti elemzővel, vagy beszéljenek szervezeti kérdésekről. PM-mel. Ez azt jelenti, hogy bár egy fejlesztő lehet introvertált, aki inkább a magányt kedveli, mégis meg kell tudnia találni a közös hangot másokkal (legalábbis egy kicsit). Minél magasabb egy fejlesztő rangja, annál több időt kell a kommunikációra fordítania, és annál kevesebb időt kell írnia a kódnak. Egy fejlesztői vezető a munkanapjának felét vagy akár többet is egyedül beszélgetésekkel és értekezletekkel töltheti, és ritkábban írhat kódot (esetleg egy kicsit elveszítheti kódolási képességeit). De ha csak szeret beszélgetni, csapatvezetőként áttérhet a menedzsmentbe, és teljesen elfelejtheti a kódírást, ehelyett egész nap különféle csapatokkal, ügyfelekkel és más menedzserekkel kommunikálna.

10. Interjúk készítése/leadása

Ha egy outsourcing vagy outstaffing cégnél dolgozik, gyakran külső interjúkon kell részt vennie, ahol "el kell adnia" magát az ügyfélnek (lehet, hogy valaki az ügyfélnek dolgozik), valamint belső interjúkat is. akik fel akarnak lépni a társaságon belül. Ezt jó növekedési lehetőségnek nevezném, mert a gyakori interjúk arra kényszerítenek, hogy a tudásodat megőrizd: nem leszel rozsdás és puha. Hiszen ha puhává válik az informatikában, teljesen kieshet a mezőnyből. Ahogy egyre tapasztaltabb fejlesztő leszel, az asztal másik oldalán találhatod magad, és inkább interjúkat készíthetsz, nem pedig továbbítasz. Hidd el, nagyon meg fogsz lepődni, ha ebből a pozícióból nézed, mert az interjú kérdéseket feltenni ijesztőbb lehet, mint válaszolni rájuk. Rendelkeznie kell saját interjústratégiával, kérdéslistával, és idővel kell feltennie kérdéseket az összes szükséges témában egy óra alatt. Ezt követően pedig Ön köteles visszajelzést adni, amely befolyásolja a felvételi döntést, és azt, hogy a jelölt megkapja-e a régóta várt ajánlatot vagy előléptetést. Vagy megengedheti egy nyilvánvalóan gyenge jelöltnek, hogy olyan pozíciót kapjon, amelyre nem alkalmas, és akkor megkérdezhetik: "Hogyan engedheti meg, hogy ilyen szintű tudással egyáltalán felvegyék"? Tehát, amikor egy interjú során a forró ülésen ül, ne feledje, hogy az Ön előtt álló személy is kihívásokkal néz szembe, és stresszes lehet. Ön felelős azért, hogy olyan visszajelzést adjon, amely befolyásolja a felvételi döntést, és azt, hogy a jelölt megkapja-e a régóta várt ajánlatot vagy előléptetést. Vagy megengedheti egy nyilvánvalóan gyenge jelöltnek, hogy olyan pozíciót kapjon, amelyre nem alkalmas, és akkor megkérdezhetik: "Hogyan engedheti meg, hogy ilyen szintű tudással egyáltalán felvegyék"? Tehát, amikor egy interjú során a forró ülésen ül, ne feledje, hogy az Ön előtt álló személy is kihívásokkal néz szembe, és stresszes lehet. Ön felelős azért, hogy olyan visszajelzést adjon, amely befolyásolja a felvételi döntést, és azt, hogy a jelölt megkapja-e a régóta várt ajánlatot vagy előléptetést. Vagy megengedheti egy nyilvánvalóan gyenge jelöltnek, hogy olyan pozíciót kapjon, amelyre nem alkalmas, és akkor megkérdezhetik: "Hogyan engedheti meg, hogy ilyen szintű tudással egyáltalán felvegyék"? Tehát, amikor egy interjú során a forró ülésen ül, ne feledje, hogy az Ön előtt álló személy is kihívásokkal néz szembe, és stresszes lehet. Minden interjú megterhelő mind a jelölt, mind az interjúkészítő számára. Valószínűleg itt véget is érünk. Köszönöm mindenkinek, aki elolvasta ezt a cikket. Nyomj egy like-ot és tanuld tovább a Java-t :)