A partnerünk egy új mérési módszert vezet be ebben az évben. Az elvégzendő feladat komplex, sokféle tudást és tapasztalatot igényel szoftverfejlesztésben és azon kívül is. A projektben több cég érintett és a Marktsoft jelentős részt vállal az új funkciók megvalósításában.
Nemrég végeztünk egy nagy tesztet, ami arra adott választ, hogy az eredeti elképzelés megállja-e a helyét a gyakorlatban (proof of concept). Volt min izgulni. Mi vagyunk a felelősek az adatok mozgatásáért és monitorozásáért két rendszer között. Több mint 30 tesztelő adatait kellett átküldeni a másik rendszerbe, majd az eredményeket visszatölteni az első rendszerbe, miközben a menedzserek a négy érintett cégnél várták a folyamat eredményeit. Ha valami gond van nálunk az adatátvitelben, akkor nincs eredmény vagy nem pontos.
Nem ez volt az első tesztünk. Tudtuk, hogy lesznek problémák, mert azok minden tesztnél vannak. A megelőző napokon többször átnéztük a követelményeket, az interfészeket és a tervezett teszt lépéseit. Mindent rendben találtunk és a belső tesztjeink is mind rendben lefutottak. Felkészültek voltunk, vagy legalábbis azt hittük.
Az első probléma nem is váratott sokáig magára. Azért, hogy az átküldött adat fájl sértetlenségét ellenőrizni lehessen a fájl tartalmából egy hash-t generáltunk és az értéket, a byte tömböt, egy másik fájlban szintén átküldtük.
A hash érték könnyen kiszámítható a .Net System.Security.Cryptography.MD5 osztály segítségével.
private byte[] ComputeMd5Hash(Stream stream)
{
stream.Seek(0, SeekOrigin.Begin);
using (MD5 md5Hash = MD5.Create())
{
return md5Hash.ComputeHash(stream);
}
}
Azonban a másik oldal sztringként várta a hash értéket, egy text fájlt akartak olvasni. A byteok szöveggé alakítása szintén nem egy nagy ügy, már ha tudunk róla, hogy erre van szükség.
private byte[] GetHexadecimalFormattedHash(byte[] hash)
{
return Encoding.UTF8.GetBytes(BitConverter.ToString(hash).Replace(„-„, string.Empty));
}
A második hiba az eredmény olvasásakor jött. A partnerünk által küldött hash nem egyezett a nálunk számolt értékkel. Kis nyomozás után kiderült, hogy a másik oldalon a tömörített fájlból számoltak hash-t, míg mi a tömörített fájl tartalmából. Az teszt előtti napokon amikor figyelmesen újra meg újra átolvastuk a követelményeket az egyik „kis betűs” részben megtaláltuk, hogy a tartalmat kell hash-elni, de a másik oldalon átsiklottak ezen, pont úgy ahogy először mi is.
Persze az ilyen szoros helyzetekben történnek a legelképesztőbb dolgok. Az történt ugyanis, hogy a német kollégánk hívott rémülten, hogy a generált kódunk nem helyes. Épp most ellenőrizte a neten egy online kalkulátorral és más eredményt kapott. Egyből néztük a kódot, hátha valamit rosszul csinálnunk, de nem volt semmi gond. Aztán legeneráltattam a hash-t Total Commander-rel és ugyanazt kaptam, mint amit mi számoltunk. Itt már kezdett gyanús lenni a dolog. Kerestünk online kalkulátorokat és kiszámíttattuk azokkal is az értéket, és azokkal is ugyanazt az eredményt kaptuk, kivéve azzal, amit a kollégánk használt. Megegyeztünk abban, hogy az a kalkulátor rossz és folytattuk a tesztet.
De a legnagyobb gond csak ezek után jött. Az eredmény más formátumban jött, mint ami a követelményben volt. Csak két kis dolog változott a sémában, de az pont elég volt, hogy a monitorozásunk rossz értéket mutasson. Mint utólag kiderült, elküldték az új sémát, de az valahol valakinél elakadt és nem érkezett el hozzánk a tesztig.
Az egész teszt szempontjából ezek a hibák marginálisak, könnyen javíthatók. De nagyon dühítők, mert ezek megakasztották az egész folyamatot és tényleg csak azon múlt, hogy nem beszéltünk egymással.
Sosem szabad lebecsülni a kommunikáció és az információ áramlás fontosságát. Nem szabad sajnálni az időt az informális beszélgetésekre, hogy az elvégzendő feladattal tisztában legyünk. Hogy tényleg megértsük és mindkét fél számára világos legyen mit kell csinálni.
Ha a munka egy irodában folyik, akkor erre a beszélgetésre jó alkalom lehet akár egy kávézás vagy amikor délben ebédeni megyünk. Ha a fejlesztés több helyen folyik, akkor már rosszabb a helyzet, mert nincsenek a véletlen találkozásból adódó ad-hoc kialakuló beszélgetések. Ilyenkor nincs más, mint valakinek kezdeményeznie kell. Mert megéri. Mindig.
Nem hagyott nyugodni a hibás online kalkulátor, http://onlinemd5.com/ , ezért a teszt után játszottam egy kicsit vele. Referenciaként a Total Commander-t ezeket az oldalakat használtam.
https://emn178.github.io/online-tools/md5_checksum.html
https://md5file.com/calculator
Először mindenféle fájlokkal kódoltattam vele és azokban az esetekben ugyanaz volt az eredmény, mint a többivel. Kivéve a tesztben szereplő fájlunkat, mert arra ugyanúgy hibás eredményt adott. Ezután megváltoztattam egy majd több karaktert a teszt fájl szövegében, de a generált kód ugyanúgy eltérő volt a többiekétől.
Vajon lehet a bemenetben valami olyan karakter vagy karaktersorozat, amit nem képes kezelni?
Gyorsan csináltam egy teszt fájlt, amiben csak „a” betűk voltak. Az eredeti fájlban 2229 karakter volt, ezért a teszt fájlom is ilyen hosszú lett.
private void CreateTestFile(int lenght = 2229)
{
StringBuilder builder = new StringBuilder();
builder.Append(‘a’, lenght);
File.WriteAllText(@”d:\Hash\test.txt”, builder.ToString());
}
De ezzel a bemenettel is eltérő volt a hash, tehát nem a tartalommal van a gond, hanem a bemenet hosszával. Mikor egyel kevesebb vagy egyel több a betűt használtam, akkor a többiekkel megegyező kódot adott. Más rövidebb és hosszabb bemenetekre is jó eredményt ad, sőt megpróbáltam kétszer olyan hosszú bemenettel is, de az is rendben van. Csak ezt a 2229 hosszt nem tudja kezelni.
Egyszerűen hihetetlen, hogy egy online kalkulátor, amit első helyen hoz a találati listán, rossz eredményt adjon egy bizonyos hosszúságú bemenetre. És vajon mekkora annak az esélye, hogy a teszteléskor pont azt a hosszúságú fájlt használjuk, amit nem tud kezelni? Nagyon-nagyon ritkán, de csakis teszteléskor vagy bemutatón fordulnak elő.
