Refactoring – fejlesztőknek kötelező

Refactoringot az angol wiki szerint akkor követünk el, amikor a kódnak “szaga” lesz. A kód pedig akkor bűzlik, ha ugyan a funkciója hibamentes, de fejlesztési szempontból tervezési hibaként értelmezhető.

Ilyen “bűzös kód” állapot minden programkód életében előbb vagy utóbb előjön, jellemzően a határidő miatt elkövetett quick-and-dirty megoldások hatására.

Szomorúbb, ha egy kód attól büdös, hogy valaki egy refactoring során átírta.

Sajnos jelenleg egy ilyen kódon dolgozok. Az előző fejlesztő valószínűleg egy procedurál elrendezésű php kódból indult OOP felé, de sem az öröklődést nem sikerült normálisan megvalósítania, se a refaktoringot.

Ilyen helyzetben úgy gondolom senki, akiben (még) lobog a szakmai büszkeség, sem tud továbbmenni, legalábbis nekem rettenetesen piszkálja a csőröm. Véleményem szerint, refactoringot maximum határidő nyomására lehet hanyagolni, bár a lehetőségekhez képest akkor is mindent meg kell tenni azért, hogy a kód a későbbiekben debuggolható, fejleszthető és módosítható legyen. Számomra ez alap, de úgy tűnik, hogy van akinek újra és újra el kell mondani.

Ha nem lenne, akkor jelenleg a következő fejlesztésen dolgoznék, és nem írnám át a kódot…

A nálunk lévő konkrét helyzetben (ahogy előbb említettem) az öröklődés hihetetlen sóher módon lett megoldva, ezért favágó módszerrel esek neki a 49 php-ból álló forráskód csomagnak. Első körben kiszűröm az azonos nevű funkciókat.

grep -r function * | cut -d ':' -f 2- | sed 's/^[ t]*//g'| sort | less

Eredményrészlet:

function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)
function createDataSetFromDataRow($dataRow,$rowNumber)

(Ez a rész a fenti shell kód eredményéből került kimásolásra, és nem egyetlen funkciónév kopipésztelt verziója a bejegyzés kedvéért.)

Bár az azonos funkciónevek nem feltétlenül jeleznek duplikált, vagy minimális eltérésű kódot, jelen esetben (még) igaz a mondás, hogy nem zörög a haraszt, ha nem fújja a szél. Nagy valószínűséggel fogok azonos vagy minimális eltérésű kódot találni. Szinte biztos vagyok abban, hogy vagy egészében vagy részeiben ki lehet a funkcionalitást emelni, hogy ne legyen kódismétlődés.

A favágó módszert tovább folytatva vagy valamilyen GUI-s összehasonlító programmal kezdem sorban csekkolni a kódokat (és egyből kiemelni a kiemelhető részt), vagy legalább egy kódrészletet kinyomtatok, ami ugyan nem környezetbarát, ám nagyban elősegíti, hogy képben maradjak. Ráadásul szövegkiemelővel/tollal satöbbi be tudom jelölni azokat a kódokat, amik kiemelhetőek.

Szükség esetén új közbülső szülő osztályokat hozok létre (általában absztraktot, ha a programnyelv engedi), és szükség esetén az öröklődési rendet is megváltoztatom úgy, hogy a funkciók/osztályok üzleti logikája ne változzon.

Ti milyen technikákat használtok? Van valami jó tippetek, hogy hogyan tudnám egyszerűbbé vagy hatékonyabbá tenni a fenti munkamenetet?

2 Comments

  1. Ha lett volna időm analizálni előre a kódot, akkor talán meghozható lett volna a döntés. Bár valamilyen befolyásom van arra, hogy milyen projektekre osztanak be a cégnél, a hierarchiából adódóan nincs 100% vétó jogom.

Comments are closed.