…meie igapäevast IT’d anna meile igapäev…

2011-12-20

Kogutud teotused 3

Filed under: Kogutud teotused — Sander @ 12:31:54

Seekordsed teotused pärinevad ühest veebiteenusest, mille autor oli suutnud imelihtsa, nii 100..150 rida koodi nõudva funktsionaalsuse vedada pea tuhande rea peale. Mõned briljantsemad näited.

Garbage collection on juba kord selline kahtlane asi… kutsume selle igaks juhuks manuaalselt oma teenuse väljakutse lõpus välja ning ootame et GC oma töö ära teeks, siis me võime kindlad olla et meil on kõik mälust mittevajalik mälust kadunud. Aga oot… kas ta ikka eemaldas mälust kõik mittevajalikud objektid? Teeme seda kaks korda järjest. Nüüd me saame lõpuks tagastada veebiteenuse vastuse, uraa!

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

Meetod ajutise kataloogi saamiseks:

public string GetTempPath()
{
  //string path = System.Environment.GetEnvironmentVariable("TEMP");
  //if (!path.EndsWith("\\")) path += "\\";
  //return path;
  return "C:\\";
}

Seejuures – kuna tegemist oli ju veebiteenusega – siis loomulikult ei olnud IIS’il õigust C:\ kirjutada. Ning kuna seda kataloogi küsis logimine, mis oli wrapitud try… catch blokki, siis ei kirjutatud iial ühtegi logirida. Miks on vaja logi kirjutada ajutisse kataloogi? Miks ei kasutata Path.GetTempPath() meetodit?

private int RandomNumber(int min, int max)
{
  var random = new Random();
  return random.Next(min, max);
}

See RandomNumber() funktsioon iseenesest ei ole WTF. Tõsi, kuivõrd seda kasutati täpselt ühes kohas, siis oleks võinud see olla ka lihtsalt new Random().Next(min, max), kuid see pole veel tragöödia. Kurb on aga see, kuidas seda kasutati – nimelt võeti saadud number ja liideti stringile, et saada unikaalne failinimi. Loomulikult ei kontrollitud ega seda faili juba enne olemas ei ole… Miks kasutada Path.GetRandomFileName() funktsionaalsust, kui ise saab ju kah?

Ning päeva nael, mis on esitamiseks liiga pikk. Kolm igaüks 168 rea pikkust meetodit, kesksed antud veebiteenuse funktsionaalsusele. Lähemal uurimisel selgub, et tegemist on täpselt ühe ja sama meetodiga, mis erineb kettale salvestatava faili laiendi poolest (string). Ning näpuka tõttu copypasteerimisel on esimesel ja kolmandal meetodil sisse jäänud sama laiend.

Miks ei võinud anda seda laiendit sisse meetodi parameetrina? Vastust teab vaid tuul.

Lisaks, umbes kolmkümmend deklareeritud ja sageli ka väärtustatud muutujat, mida ei kasutata. Sealhulgas ka streamid, mis luuakse ja loetakse väärtused sisse, kuid ei kasutata ega suleta. Kasutamata meetodid. Kümmekond konstanti, mida kasutatakse vaid ühes kohas, kui üldse. Mittetöötav logimine üritab kirjutada logifaili potentsiaalselt kümneid megabaite suurt Base64 stringi. If-else-if puud switch…case asemel.

Versioonihalduses olev kood ei ole sama, mis lives kompileeritud dll – ning seejuures loomulikult ei tea keegi, kus see “päris” kood võiks olla. Ilmselt ei jõudnud see kunagi tundmatu “arendaja” masinast kaugemale.

Lisaks veel kommentaar nooremprogrammeerija koodist, hoopis teisest projektist:

// Note that this implementation has weakness. It does not work correctly

See tegelikult ei ole teotus ja muutub arusaadavaks, kui järgmisel real olevat “// if…” kommentaari jätku lugeda. Aga esmapilgul…

Lisa kommentaar »

Kommentaare veel pole.

RSS feed for comments on this post. TrackBack URI

Lisa kommentaar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Muuda )

Twitter picture

You are commenting using your Twitter account. Log Out / Muuda )

Facebook photo

You are commenting using your Facebook account. Log Out / Muuda )

Google+ photo

You are commenting using your Google+ account. Log Out / Muuda )

Connecting to %s

Blog at WordPress.com.