Kotlin programozáshoz profi segítségre van szükséged?

Kotlin programozás

A Kotlin programozás főleg akkor kerül elő, ha valaki Android alkalmazást szeretne, meglévő mobilos kódot javítana, vagy egy régi Java alapú megoldást szeretne rendezettebb formában továbbvinni. Magánügyfélnél ez nem mindig nagy termék. Sokszor egy konkrét ötlet, egy már futó alkalmazás hibája vagy egy félkész projekt befejezése a valódi feladat. A Kotlin programozás ezért nem elvont technikai kérdés, hanem gyakorlati szolgáltatás. Az ügyfél szempontjából az számít, hogy az alkalmazás rendesen fusson, ne omoljon össze, és később is lehessen hozzá nyúlni. A Qjob.hu oldalon szerintem így érdemes szakembert keresni erre a témára.

A magyar nyelvű találatoknál visszatérő elem a natív Android fejlesztés, a hibajavítás, a Java rendszerek továbbvitele és az egyedi alkalmazások készítése. Az angol szolgáltatói oldalakon ugyanígy gyakori a karbantartás, a teljesítmény, a kompatibilitás és a későbbi bővítés. Ez nekem logikusnak tűnik. A legtöbb ügyfél nem azért keres Kotlin fejlesztőt, mert önmagában a nyelv érdekli, hanem azért, mert van egy alkalmazásötlete vagy egy működő, de problémás rendszere.

Sokan ott csinálnak hibát, hogy túl korán részletes funkciólistát írnak, de nem mondják ki az alapcélt. Pedig elsőre elég lenne annyi is, hogy mire kell az alkalmazás, kik használják, milyen telefonokon futna, és mi az a legkisebb működő változat, amivel már lehetne tesztelni. Az én tapasztalatom az, hogy a jó indulás itt sokkal többet számít, mint egy hosszú, de zavaros leírás.

Kotlin fejlesztés Android alkalmazáshoz

A Kotlin fejlesztés leggyakoribb valós terepe ma is az Android. Ez lehet teljesen új alkalmazás, de ugyanilyen gyakori a meglévő mobilos projekt átvétele is. Magánügyfélnél sokszor valaki már elkezdett valamit egy korábbi fejlesztővel, aztán megakadt a munka. Más esetben egy régi alkalmazás még működik, csak már lassú, hibás vagy nehezen frissíthető. Ilyenkor a Kotlin fejlesztő feladata nem pusztán kódírás. Előbb meg kell érteni, milyen állapotban van a projekt.

Az ügyfelek gyakran azt hiszik, hogy egy alkalmazás fejlesztése főleg a látványról szól. Persze a felület is fontos. De sokkal több múlik a háttérlogikán, az adatkezelésen, az értesítéseken, a verziókezelésen és azon, hogyan reagál az app eltérő készülékeken. Szerintem sok félreértést megelőz, ha ezt már az elején tisztázzák. Nem minden probléma látszik kívülről. Volt már olyan eset, amikor a megrendelő új dizájnt akart, miközben a valódi gond az volt, hogy az alkalmazás egy régi Android verzión még elfutott, az újabb készülékeken viszont hibásan kezelte az engedélyeket.

Én személy szerint jobban szeretem, ha az első körben egy szűkebb cél kerül az asztalra. Például legyen működő bejelentkezés, adatküldés és egyetlen stabil képernyő. Ha ez rendben van, lehet bővíteni. A túl nagy első kör majdnem mindig csúszást hoz. És az ügyfél közben elveszíti a kapaszkodót, mert nem lát kézzelfogható eredményt.

Kotlin fejlesztő választása

Kotlin fejlesztőt keresve nem az a legfontosabb, hogy ki írja a leghosszabb bemutatkozást. Sokkal fontosabb, hogy hogyan kérdez vissza. Rákérdez-e arra, van-e kész terv, kell-e szerverkapcsolat, vannak-e képernyők, van-e hozzáférés a jelenlegi forráskódhoz, és hogyan történik majd a tesztelés. Egy jó Kotlin fejlesztő szerintem már az első beszélgetésnél jelzi, hogy mi egyértelmű és mi kockázatos.

Sokan a legalacsonyabb ár alapján döntenek. Ezzel önmagában nincs baj, csak utána gyakran derül ki, hogy mi maradt ki. Nincs tesztkészülék. Nincs átadási leírás. Nincs rövid utókövetés. Nincs tisztázva, hogy ki kezeli a későbbi feltöltést vagy frissítést. Az ilyen hiányok sokszor nagyobb gondot okoznak, mint maga a fejlesztési díj. Én inkább olyan embert választanék, aki rövidebben, de pontosabban válaszol.

Volt egy ügy, ahol az ügyfél csak annyit írt, hogy kellene egy kis módosítás. Később derült ki, hogy valójában push értesítés, új jogosultságkezelés és hibás bejelentkezési folyamat állt a háttérben. Ketten is alacsony árat mondtak rá. A harmadik fejlesztő előbb végignézte a projektet, és azt mondta, hogy a felmérés külön szakasz lesz. Elsőre ez kevésbé volt vonzó. A végén mégis ez lett a jobb döntés. Nekem ez megerősítette, hogy a tiszta indulás nem felesleges kör, hanem időspórolás.

Java alapú app átvétele és hibajavítás

A Kotlin programozás sok esetben nem nulláról indul. Gyakori, hogy van már egy Java alapú Android alkalmazás, amelyet javítani, továbbírni vagy részben átvezetni kell. A szolgáltatói oldalaknál ez kifejezetten visszatérő téma. Nem csoda. Sok korábbi mobilos rendszer még ma is Java alapon működik, és nem mindig éri meg mindent újraírni. Néha elég egy-egy részt Kotlinban bővíteni, és így fokozatosan rendezettebb lesz a projekt.

De itt sokan hibáznak. Azt gondolják, hogy a nyelvcsere önmagában megoldás. Pedig nem az. Ha az alkalmazás logikája szétesett, hiányos a szerkezet, vagy rossz a tesztelés, akkor attól még nem lesz jobb, hogy más nyelven folytatják. Szerintem a jó szakember előbb azt nézi meg, érdemes-e egyáltalán átállni, és ha igen, melyik részeken. Néha egy teljes migráció túl nagy falat. Néha viszont éppen ez hozza meg a nyugalmat hosszabb távon.

Az én tapasztalatom az, hogy a hibajavításnál mindig a reprodukálhatóság a kulcs. Mikor omlik össze az app. Melyik készüléken. Belépés után vagy előtte. Csak gyenge hálózatnál jön elő a gond, vagy mindenhol. Ezek nélkül a javítás találgatás marad. Volt már olyan eset, amikor az ügyfél szerint véletlenszerű volt a hiba. Később kiderült, hogy kizárólag bizonyos Android verziókon jelentkezett, és ott is csak akkor, ha a felhasználó gyorsan váltott képernyőt. Innen már kezelhető lett a helyzet.

Árak és fejlesztési szakaszok

A Kotlin programozás ára attól függ, hogy kisebb javításról, új funkcióról vagy teljes alkalmazásról van szó. Az angol szolgáltatói oldalak alapján a visszatérő részek a tervezés, az egyedi fejlesztés, a Java és Kotlin együttélése, valamint a későbbi karbantartás. A magyar példákban szintén az látszik, hogy az ár nem csak a kód mennyiségétől függ, hanem attól is, mennyi bizonytalanság van a projektben. Ha van kész terv és rendezett forráskód, könnyebb becsülni. Ha nincs, akkor a felmérés külön tétel lesz, ami teljesen normális.

Olcsóbban természetesen lehet ajánlatot kapni, de őszintén szólva a túl alacsony ár engem mindig óvatossá tesz. Szerintem 15.000 alatt legfeljebb nagyon szűk és pontosan körülírt javítás fér bele nyugodtan. Egy valódi hibafeltárás, eszközteszt vagy komolyabb új funkció ennél több munkát igényel. Sok ügyfél csak a programozásra gondol, pedig ott van mellette a tesztelés, a build környezet rendbetétele, az átadás és néha az alkalmazás közzétételéhez kapcsolódó segítség is.

Én jobban szeretem a tételes ajánlatot, mint az egyetlen végösszeget. Így látszik, mi a felmérés, mi a fejlesztés, mi a próba és mi az átadás. És az is kiderül, hol lehet egyszerűsíteni a kérést. Sok megrendelő csak akkor érzi ezt, amikor már elindult a munka. Pedig előre is tisztázható lenne.

Karbantartás és átadás

A Kotlin fejlesztés akkor marad hosszabb távon is használható, ha a munka végén nem csak az app működik, hanem valamilyen rend is marad utána. Hol van a forráskód. Mivel fordítható. Milyen függőségek kellenek hozzá. Ki fér hozzá a kiadási folyamathoz. Kell-e valamit figyelni új Android verziónál. Ezek nem látványos pontok, mégis itt dől el, hogy fél év múlva mennyire lesz kezelhető a projekt.

Sokan itt követik el a legnagyobb hibát. Megkapják a késznek tűnő alkalmazást, kipróbálják, örülnek neki, és nem kérnek semmilyen rövid átadást. Később pedig, amikor fejleszteni vagy javítani kellene, már senki nem tudja, pontosan milyen állapotban lett átadva. Én mindig kérek rövid összefoglalót arról, mi készült el, mi maradt későbbre, és mihez milyen hozzáférés tartozik. Nem hosszú dokumentációra gondolok. Elég pár világos bekezdés.

És van még egy fontos rész. Sok konfliktus abból születik, hogy az ügyfél hibajavításnak hív valamit, amit a fejlesztő már új kérésnek lát. Ezt érdemes előre kimondani. Mi számít utólagos hibának. Mi számít új funkciónak. Mennyi ideig vállalható ésszerűen visszajelzés a lezárás után. Szerintem ez sokkal hasznosabb beszélgetés, mint az, hogy ki mennyire lelkes. A jó együttműködés nem a hangulaton, hanem a tiszta határokon múlik.

Összességében a Kotlin fejlesztés és a Kotlin programozás akkor működik jól magánügyfélnél, ha a feladat világos, az első verzió nem túl nagy, és a végén marad egy áttekinthető projekt. Nekem ez fontosabb, mint bármilyen túl szép ígéret.