Fájdalommentes technológiaváltás I.

Akár a szalámi: szeletenként haladjunk!

Néhány hónapja egy technológiaváltási projektben kérte a segítségünket az egyik partnercégünk: Delphi, C#, WPF és MS SQL technológiáról szerettek volna JavaScriptre átállni. Mivel a fejlesztőcsapat többsége C#-ban dolgozott korábban, a hiányzó tapasztalat miatt fordultak hozzánk. A Green Foxnál töltött éveim alatt és még korábban, fejlesztőként is számos hasonló projekten dolgoztam, nagyon sok csapdával és jó megoldással találkoztam, ezeknek a tapasztalatait gyűjtöm össze a következő két cikkben. 

Elégedettebb fejlesztők, gyorsabb fejlesztés: ezért vágjunk bele!

Egy új programozási nyelvre való átállás általában nehéz döntés egy vállalat életében. Meglehetősen fájdalmas folyamat, költséges- és időigényes lehet, ráadásul ha rossz döntéseket hozunk, zsákutcába futhatunk. A másik oldalon azonban közép távon sokat nyerhetünk, például elégedettebb fejlesztőket, gyorsabb, hatékonyabb fejlesztési projekteket, jobb megtérülést.

A technológiaváltási projektek általában a fejlesztők kezdeményezésére indulnak el, akiknek egy idő után megnehezíti a régi rendszer a munkájukat, és így nem szeretnek vele dolgozni. Tipikus, hogy például már nem érhető el friss dokumentáció az adott technológiához, vagy épp vissza kell keresni régi dokumentációkat, vagy egyszerűen már nem támogatott az adott technológia. Így nehéz módosítani a kódot, egy-egy módosítás pedig sokszor eltör valamit. Ez amellett, hogy nem hatékony, nagyon frusztráló tud lenni a fejlesztők számára. Ilyenkor sokszor a jó megoldást a technológiaváltás jelenti.

Ground up vs. funkciónként

Bármennyire is kecsegtető a korábbi alkalmazás nulláról való újraírása, tapasztalatom szerint ez az egyik legnagyobb hiba, amit elkövethetünk. Egy 5-10 éves rendszert újraírni elképesztően időrabló, szinte biztosan el fog törni valami, az új rendszer ráadásul kevesebbet is fog tudni. A régi alkalmazás ugyanis - minden hibája ellenére - jól kitesztelt, sok-sok feature-rel rendelkezik, amit nem lehet néhány hónap alatt reprodukálni.  

Ezért a régi alkalmazás teljes kukázása helyett egy jól meghatározott feature-t kell kiválasztani, azt újraírni az új technológiával úgy, hogy illeszkedjen a rendszer többi részéhez. Ez arra is jó, hogy validáljuk az új technológiát: Milyen előnyei vannak a korábbival szemben? Mennyire gyorsul fel az adott funkció? Mennyivel lesz jobb minőségű? 

Ha az első funkció újraírása sikeres, akkor jöhet a következő. Mint egy szalámi, szeletenként írjuk újra a rendszert. A projekt végére a kódbázis elenyésző részén marad meg a régi technológia. 

Így válasszuk ki a feature-öt!

Érdemes egy olyan feature-rel kezdeni a technológiaváltást ami:

• jól körülhatárolható,
• egyébként is szeretnénk rajta ráncfelvarrást,
• UX szempontból is elavult.

Így nemcsak a technológiaváltás indíthatjuk el, de egy elavult funkciót is felhasználóbaráttá tehetünk, vagyis a termék értékét is növeljük. 

Készítsünk architekturális ábrát!

Mielőtt belevágunk egy funkció újraírásába, készítsünk architekturális ábrát arról, hogy hogyan épül fel a rendszer, milyen fő komponensei vannak, mely részeket fogja érinteni a technológiai váltás! Ezután nézzük meg, hogy a rendszer többi része hogyan fog kapcsolódni az új technológiához!

Sokszor ez a tudás hiányzik a cégeknél, korábbi projektjeink egy jó részében ezért éppen abban kérték a segítségünket, hogy összekapcsoljuk a régi rendszert és az új technológiát. 

A technológiaváltáshoz kapcsolódókövetkező cikkben többek között azt veszem sorra, hogy milyen szempontokat érdemes figyelembe venni az új technológia kiválasztása során.

‍

Te is technológiaváltás előtt állsz? Töltsd le kapcsolódó esettanulmányunkat, ahol egy technológiaváltással kapcsolatos projektet mutatunk be!