Tapasztalt programozok/szoftverfejlesztok mit tesznek ilyenkor?

A LOC pont annyi karakter, mint a sor.

Amúgy gyakorlaton én egy kb 60k soros C kódot (amiből 40k sor EGY fájlban volt, igen) prüntyöltem, ami bináris fájlokat nyálazott végig és cseszegetett, tehát viszonylag nehéz volt követni a változtatásokat.

Nem lehetetlen, 15k sor az szinte semmi. Számíthatsz arra, hogy az elnevezések viszonylag logikusak lesznek, meg kell találni egy funkcionalitás gócpontját, és debuggolni. A VS elég okos debuggolásban, szóval sok sikert.

Első körben rohadtul káromkodunk, és szidjuk a felmenőit annak a kontárnak, aki nem tud olyan kódot írni, ami kezelhető (btw kommentezni általában nagyon rossz ötlet, de ebbe most nem folynék bele, privátban nagyon szívesen elmagyarázom, ha akad egy kis időm).

Annyit tudsz tenni, hogy írsz hozzá unit teszteket, amelyekben kvázi megtippeled, mi hogyan működik. A test case -ek rá fognak vezetni, hol stimmelnek az elképzeléseid, ill. hol merrefelé kell tapogatózni.

Ha megvannak a tesztek, el tudod kezdeni refaktorálni a kódot, mivel már van, ami biztosítja, hogy azonnal észrevedd, ha eltörsz valamit.

A másik lehetőség (szinte garantált, hogy elhajtanak), hogy jelzed, hogy a kód használhatatlan, és újra kell írni. Ide elég meggyőző érvekre lesz szükség, hogy egyáltalán meghallgassanak. Ha rábólintanak, meg lehet írni tisztességes minőségben. Juniorként/gyakornokként ez persze nem olyan egyértelmű, de ebben spec pont tudok segíteni.

Első körben itt egy kiváló könyv:

[link]

Főleg Java alapokra épít, de ez a lényeg szempontjából nem érdekes, pláne, hogy a C# és a Java meglehetősen hasonló. Ha a benne levőket megfogadod, tudni fogod, mit szabad és mit nem. Ezen felül vannak benne tanácsok/praktikák pont ilyen esetekre is, mint a tiéd.

Elég hosszú, de megéri elolvasni.

Mindenképpen kezdd el legalább apránként refaktorálni a kódot, különben bele fogsz fulladni előbb-utóbb.

Én ugyan nem vagyok szoftverfejlesztő, de szerintem ha már bele kell ásni magad a dolgokba, lehet, hogy érdemes a munkaidőd egy részét a hiányzó dokumentáció pótlására fordítani. Abból lesz valami látványos, amit le tudsz tenni az asztalra, és elmagyarázhatod, hogy hosszú távon ez jó nekik, és esetleg megértik, mit kéne legközelebb elvárniuk egy fejlesztőtől.

Valami hasonlóval foglalkozom én is, becsöppentem egy cégnél egy külső fejlesztő által gányolt, teljesen dokumentálatlan rendszerbe, amit a fejlesztő egy másik cégnek készült rendszerből barkácsolt át, de ki se dobta a fölösleget, ő se emlékszik rá, hogy működik a dolog, de tőlem bezzeg pontosan specifikált fejlesztési kéréseket vár. Így hát megpróbálom magamnak pótolni a dokumentációt, hogy legalább én értsem, mi hogyan működik.