Igy ne...

[Andras Tantos]

Hali!

>> Azert a tobbszalu programokban szinkronizacios hibat talalni nem 
>> egyszeru. Semmi keppen nem a 'primitiv hiba' kategoria. Tobben mondtak 
>> mar, hogy ez es a memoria korrupcio (buffer overflow, ketszeres 
>> felszabaditas, felszabaditott memoriaba iras, stb.) a legnehezebben 
>> megtalahato hiba-osztaly.
>
> Igy igaz, de ezek a feladatok leginkabb az alkalmazott oprendszer 
> feladatai kellenenek legyenek...

Ez tevedes. Az OS szinkronizacios primitiveket, technikakat ad, de magat a 
szinkronizaciot neked kell a szalak kozott megvalositani. Bizonyos 
programnyelvek talan adnak ehhez nemi segitseget, de a C, es a C++ nem igen, 
marpedig a 'nagy' programok zomet manapsag ezekben a nyelvekben irajak. Az 
OS soha nem fogja helyettet kitalalni, hogy mely valtozokat kell kritikus 
szekcioval vedeni, melyik programreszletek, algoritmusok azok, amik 
thread-safe-ek, es melyikek nem, melyikek re-enteransak es melyikek nem, 
stb. stb. Talan egy dead-lock-ot meg fel tud deriteni az OS, de meg ze se 
mindig igaz.

>> Ez relative egyszeru: olyan rendszereket kell hasznalni, amiknek mar 
>> eleve megvan a feladathoz illo minositese. Azaz, ha pl. SIL-3-as 
>> biztonsagi osztalyu programot kell irnod, akkor olyan OS-t, olyan 
>> forditot, olyan lib.-eket stb. fogsz hasznalni, amikre a 
>> gyarto/forgalmazo mar megszerezte a SIL-3-as minositest. Igy neked mar 
>> csak a sajat kododat kell minositeni. Persze ezek az eszkozok nem szoktak 
>> 'GPL' liszensszel jonni, es nem is 50e forint egy liszensz...
>
> De hiaba a minosites, neha elojon a worst-case es ezek is tudnak borulni..

A minosites sajnos nem jelent minoseget. Amit viszont jelent: garanciat. 
Amugy azt hiszem, hogy bizonyos biztonsagi osztalyok (nem tudom, hogy pont a 
SIL-3 ilyen-e) tartalmaznak worst-case eloirasokat is.

>> Egyebkent en is ugy latom, hogy a programok minosege nagy atlagban evrol 
>> evre zuhan. En viszont nem elso sorban a programozok tudasanak a 
>> romlasaban latom ennek az okat, hanem a programok bonyolultsaganak 
>> exponencialis novekedeseben. Ma mar nem nagyon van olyan eladhato tudasu 
>> program (PC-n legalabbis) aminek a bonyolultsaga ne haladna meg egy ember 
>> felfogo kepesseget. Ha meg nem latod at a teljes rendszert, bizonyos 
>> pontokon sotetben fogsz tapogatozni es hibazni fogsz.
>
> En nem ebben latom a fo okot. Leginkabb az a bibi, hogy a 
> versenyhelyzetben a kuncsaft nem kivanja megfizetni a tisztesseges 
> programozast es tesztelest, vagy erre mar nem szannak idot a profit 
> erdekeben... igy az ugyfel tesztel elesben... es a program hibazni fog.
> marpedig ekkor mar csak foltozni lehet, jol megcsinalni legtobbszor nem..

Ez nem egeszen van igy, plane a nagy megbizhatosagu rendszereknel. A 
minositesnek ugyanis feltetele a bizonyitottan elvegzett alapos teszteles 
(pl. 100% code-coverage). Az ugyan igaz, hogy a 'time-to-market' nagyon 
lerovidult, es ez leroviditi a tesztelesre juto idot is, de a masik oldalrol 
a tesztelesi technikak is fejlodtek. Az ugyfel altal vegzett teszt fontos 
(ezt hivjak pl. Tech Preview, Alpha, Beta, RC release-nek) mert sok olyan 
hiba jon ki belole, amit maskent a tesztelok nem vennenek eszre de ez nem az 
egyetlen teszt termeszetesen ma sem.

Nagyon keves ceg/tarsasag engedheti meg maganak azt, hogy ne 'csak 
foltozzon' regi programokat. Egy nagy program altalaban tartalmaz nagyon 
regi es nagyon uj reszeket, koztuk a szivarvany osszes szinevel. Az 
optimalis eset kb. az, hogy a regi reszek tele vannak tervezesi, az uj 
reszek pedig programozasi hibakkal. Uj reszek ket ok miatt kerulnek egy 
rendszerbe: egy regi reszt, ami mar karbantarthatatlanul regi es/vagy 
eltervezett kicserelnek, vagy uj modulokat, funkciokat adnak hozza a 
programhoz. Teljesen elolrol nagyon nagyon ritkan irank ujra egy programot.

A csere tobb ok miatt is rizikos: biztos, hogy lesznek benne programozasi 
hibak, es nem biztos, hogy nem lesz benne kevesebb tervezesi hiba. Igy tehat 
a vegeredmeny (eleinte legalabbis) valoszinuleg rosszabb lesz, mint a regi 
verzio. A masik riziko az, hogy a felhasznaloknak nem lehet az uj valtozatot 
azzal eladni, hogy 'az uj program azt tudja, mint a regi, de jol'. Az uj 
verziot csak azzal lehet eladni, ha valami olyasmit tud, amit a regi nem, es 
a felhasznaloknak szukseguk van ra.  Ez lehet 'nagyobb biztonsag', 'uj 
funkcio', 'nagyobb teljesitmeny' stb. Nem lehet 'hibajavitas'. Uj verziot 
pedig el *kell* adni, mert ebbol el a ceg.

A megoldas tehat nem ott van, hogy 'jobb programot kell irni', es 'jobb 
programozokat kell hasznalni', meg, hogy 'a mai programozok hulyek, bezzeg a 
regiek'. Az emberek alapvetoen hibasan dolgoznak, ezen nem lehet segiteni. A 
SW pedig dontoen kezi munkaval keszul. A megoldas reszben valahol abban az 
iranyban van, hogy toleralni kell a programozasi hibakat. Nem hibatlan 
rendszereket kell irni, hanem hibaturo rendszereket. A masik iranya a 
megoldasnak az, hogy olyan eszkozoket kell adni a programozok kezebe, amik 
nem teszik lehetove a hibak elkoveteset. Azaz automatizalni kell a SW iras 
bizonyos aspektusait. Egy pelda: a programok jelentos resze hemzseg a 
memoria-kezelesi hibaktol. Nem az tehat a megoldas, hogy 'tanitsuk meg a 
programozokat memoirat kezelni', hanem az, hogy 'vegyuk ki a kezukbol a 
memoria kezelest'. Reszben errol szol a Java, meg a .NET, meg meg egy csomo 
modern programnyelv.

Mind ez persze SZVSZ.

No, jo hosszu lett, bocsi...

Udv,
Tantos Andras