Megfelelően működő program

1. A programozói munka

A kezdő programozók nagyon gyakran teljesen másképp gondolnak egy programozó munkájáról, mint ahogy azt a tapasztalt programozók gondolják.

A kezdők gyakran mondanak valami ilyesmit: "A program működik, mi kell még?" Egy tapasztalt programozó tudja, hogy a "jól működik" csak az egyik követelmény a programokkal szemben , és nem is ez a legfontosabb !

Kód olvashatóság

A legfontosabb az, hogy a programkód érthető legyen más programozók számára . Ez fontosabb, mint egy megfelelően működő program. Sokkal több.

Ha olyan programja van, amely nem működik megfelelően, kijavíthatja. De ha olyan programod van, aminek a kódja nem érthető, azzal nem tudsz mit kezdeni.

Vegyünk egy tetszőleges lefordított programot, például a Jegyzettömböt, és változtassuk a háttérszínét pirosra. Van egy működő programja, de nincs érthető forráskódja: lehetetlen egy ilyen programot módosítani.

Tankönyvi példa az, amikor a Microsoft fejlesztői eltávolították a Pinball játékot a Windows rendszerből, mert nem tudták 64 bites architektúrára portolni. És még a forráskódjuk is megvolt. Egyszerűen nem tudták megérteni, hogyan működik a kód .

Minden használati eset elszámolása

A program második legfontosabb követelménye, hogy minden forgatókönyvet figyelembe vegyen. Sokszor a dolgok egy kicsit bonyolultabbak, mint amilyennek látszik.

Hogyan látja egy kezdő programozó az SMS-ek küldését:

Így látja ezt egy profi programozó:

A „helyesen működik” forgatókönyv általában csak egy lehetséges. És ezért sok újonc panaszkodik a CodeGym feladatellenőrzőjére: 10-ből csak egy forgatókönyv működik, és az újonc programozó szerint ez elég.

2. Rendellenes helyzetek

Bármely program végrehajtása során rendellenes helyzetek adódhatnak.

Például úgy dönt, hogy ment egy fájlt, de nincs lemezterület. Vagy a program megpróbál adatokat írni a memóriába, de kevés a rendelkezésre álló memória. Vagy letölt egy képet az internetről, de a kapcsolat megszakad a letöltési folyamat során.

A programozónak (a program készítőjének) minden abnormális helyzetre a) előre kell látnia , b) el kell döntenie, hogy a program pontosan hogyan kezelje , és c) olyan megoldást kell írnia, amely a lehető legközelebb áll a kívánthoz.

Emiatt a programok nagyon egyszerű viselkedést mutattak sokáig: ha hiba történt a programban, a program leállt. És ez nagyon jó megközelítés volt.

Tegyük fel, hogy egy dokumentumot lemezre szeretne menteni, de a mentési folyamat során azt tapasztalja, hogy nincs elég lemezterület. Melyik viselkedést szeretné a legjobban:

• A program leáll
• A program tovább fut, de nem menti a fájlt.

Egy kezdő programozó azt gondolhatja, hogy a második lehetőség jobb, mert a program még fut. De a valóságban ez nem így van.

Képzelje el, hogy 3 órán keresztül gépelt ki egy dokumentumot a Wordben, de két perccel az írási folyamat során világossá vált, hogy a program nem tudja lemezre menteni a dokumentumot. Jobb elveszíteni két percnyi munkát vagy három órát?

Ha a program nem tudja megtenni, amit kell, jobb, ha bezárja, mintsem továbbra is úgy tesz, mintha minden rendben lenne. A legjobb, amit egy program tehet, ha olyan hibába ütközik, amelyet önmagában nem tud kijavítani, ha azonnal jelenti a problémát a felhasználónak.

3. Háttér a kivételekről

Nem a programok az egyetlenek, amelyek rendellenes helyzetekkel szembesülnek. A programokon belül is előfordulnak – a metódusokban. Például:

• Egy metódus fájlt akar írni a lemezre, de nincs hely.
• Egy metódus függvényt akar hívni egy változón, de a változó nullával egyenlő.
• A 0-val való osztás egy metódusban történik.

Ebben az esetben a hívó metódus esetleg kijavíthatja a helyzetet (alternatív forgatókönyvet hajthat végre), ha tudja, hogy milyen probléma fordult elő a hívott metódusban.

Ha egy fájlt próbálunk lemezre menteni, és már létezik ilyen fájl, akkor egyszerűen megkérhetjük a felhasználót, hogy erősítse meg, hogy felül kell írni a fájlt. Ha nincs szabad lemezterület, megjeleníthetünk egy üzenetet a felhasználónak, és megkérhetjük a felhasználót, hogy válasszon másik lemezt. De ha a programnak elfogy a memóriája, akkor összeomlik.

Egyszer régen a programozók elgondolkodtak ezen a kérdésen, és a következő megoldást találták ki: minden metódusnak/függvénynek hibakódot kell visszaadnia, amely jelzi a végrehajtás eredményét. Ha egy függvény tökéletesen működött, 0-t adott vissza . Ha nem, hibakódot adott vissza (nem nullát).

A hibák ilyen megközelítésével szinte minden függvényhívás után a programozóknak ellenőrizniük kellett, hogy a függvény hibásan fejeződött-e be. A kód buborékos méretű, és így néz ki:

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

Sőt, gyakran előfordul, hogy egy hiba észlelését észlelő funkció nem tudott mit kezdeni vele: a hívó félnek vissza kellett adnia a hibát, a hívó fél pedig visszaküldte a hívójának, és így tovább.

Egy nagy programban a több tucat függvényhívásból álló lánc a jellemző: néha akár több száz függvény hívásmélységét is megtalálhatjuk. És most át kell adnia a hibakódot a legalulról a tetejére. És ha valahol valamelyik funkció nem kezeli a kilépési kódot, akkor a hiba elvész.

Ennek a megközelítésnek egy másik hátránya, hogy ha a függvények hibakódot adtak vissza, már nem tudták visszaadni saját munkájuk eredményét. A számítások eredményét referencia paramétereken keresztül kellett átadni. Ez még körülményesebbé tette a kódot, és tovább növelte a hibák számát.