Szerintetek a bugok mekkora része keletkezik szaktudás hiányából, és mennyi "figyelmetlenségből"?

Mivel vannak kód reviewk, így ha valami nagyon rossz szakmailag azt nem szokták beengedni jobb helyen és emiatt a szaktudás hiánya nem játszik annyira szerintem.

Inkább abból ered, hogy nem értelmezte megfelelően a feladatot, kihagyott belőle valamit vagy adott esetet nem kezelt le, ami fontos lenne.

Legalábbis én ilyenekkel találkoztam eddig.

Ez egy fura kérdés. Kimaradt belőle:

- a specifikáció hibája (vagy félre érthetősége és ezért lesz luk egy csomó helyen)

- A fejlesztés/tesztelésre szánt idő rövidsége. "De főnök a múlt héten arról volt szó, hogy ezen a héten péntekre kell, és ma még csak kedd van, még nem vagyok kész. Áhh nem számít add ide ahol tartasz..."

- A kapkodás. "Erre a feladatra kéne kb. 2 hét nyugiban. Áhh annyi idő nincs az ügyfélnek ma délutánra kell valami. Majd kijavítjuk de legyen valami délutánra".

- A szervezetlenség. Például nálunk gyakori, hogy az ember nyakig van egy bonyolultabb eljárás megírásában (vagy fontos meetingben, ahol figyelni kéne) és megjelenik valemelyik főnök titkárnője valami eszetlen ostobasággal (legútóbb az volt a kérdése, hogy X-eljük be a táblázatába, hogy milyen illatosítású budi papírt rendeljenek, és olyat hoznak amiből a legtöbben X-elik, persze ez azonnal és nem várhat arra se, hogy az ember az adott sort befejezze, mert ez ezerszer fontosabb bárminél).

- A fél óránként változó feladat és specifikáció. Te ma az X projekten kéne dolgozzál és besegíteni Z-nek, mert elakadt, tudom, hogy határidőd van a W projekten, de ez most fontosabb és különben is változik mert nem Gizike hanem Gőzeke kicsit félre érettük, szóval nagyrészt újra kéne írni mindent de a határidő nem változik. De most Z-nek segíts egy kicsit mert az X projekten holnap határidő van és Z elakadt. Ez most mindennél fontosabb.

"belázasodott a gyerek érte kell menni az oviba és rohanni vele az orvoshoz..."

Sok oka lehet annak, hogy bug kerül a programba.

Az, hogy "szaktudás hiánya" az önmagában nem szokott bugot okozni, az annyit szokott okozni, hogy bonyolutabb megoldás születik, lassabban születik meg a kód, nem lesz olyan "szép" a kód.

Sokszor van olyan, hogy eleve hibás a megközelítés. Arra alkalmatlan környezetben, arra alkalmatlan eszközzel, keretrendszerrel, fejlesztő rendszerrel kell valamit megoldani. Ez már önmagába hordozza, hogy ott a hiba tévesztés stb. lehetősége.

Ott van sok esetben magának a fejlesztő rendszernek a hibája. Pl. a Python sok esetben önmagában full bugos. Vagy ott van az, hogy idő közben kijön az új lib változat, ami miatt csak egy picit változik meg valami valamelyik függvény hívásban és vagy észreveszed és javítod 1000 helyen (az esetleg már átnézett kódrészeknél) vagy nem...

Szerintem a hibák legnagyobb része a tesztelés hiányából fakad.

Egy funkciót te egy adott módon akarsz majd használni és azokra az esetekre fókuszálsz, de sok esetben más is elkezdheti azt a funkciót használni teljesen más módon, majd még egy ember.

És van amikor az a funkció egy picit változik és eltör néhány használati módot, ha le van fedve a kód tesztekkel akkor ezek elő fognak jönni, viszont ha nincs akkor bizony prod kódnál fog a gond csak előjönni.

De ugyanez előjöhet 1-1 könyvtár frissítésénél is.

Cachelés mint példát felhoztál pedig trükkös tud lenni hiszen más használati eseteknél más stratégia kell. Mondjuk te arra tervezed a cachet hogy nagy frekvenciával kérsz le adatokat, de mondjuk aki a funciót használja később hosszú idősorokat kér le ami folyamatosan túlcsordul a cache limiten.

Ha spagettikódot ír valaki és elfogadják a PRját az meg a csapat fszsága.

Egy nagyon korai programozás tankönyvben olvastam (úgy értve korai, hogy az 1960-as évek vége), hogy 100 sor fölött elkezd a program olyan komplex lenni, hogy a bugok száma rohamosan emelkedik. Erre próbáltak olyanokat kitalálni, hogy legyen egy-egy blokk kisebb (kezdetben voltak az eljárások, függvények, hogy 100 sor alatt legyen egy egy rész ami önmagában tesztelhető; ma ezek az objektumok stb.). De egy idő után ez sem működik, mert ott van az emberi tévesztés lehetősége. Valamikor az 1970-es évek közepéből egyszer olvastam (vagy youtube videó vagy már nem emlékszem), hogy vizsgálták, hogy egy programozó (vagy bármilyen ember) milyen valószínűséggel követ el hibát ("tévedni emberi dolog" tartja a mondás) és hogy ezt a valószínűséget rávetítve kód méretre és egészen meglepően rövid kód esetén már csak az a tény, hogy az ember nem gép és néha hibázik (genetikai örökségünk?) okoz bugot, amit utána vagy megtalálunk vagy nem. Nyilván legtöbbször ez elgépelés és feltehetően szintatktika hiba lesz és eldobja a fordító de mi van ha nem? És átmegy mindenen? Régen a nagyon profi gépírónőket szintén vizsgálták és 3-4 hiba/oldal egy egészen elfogadható hiba arány volt. És őneki csak az volt a dolga, hogy gépelje az adott szöveget. Most néztem egy gépírás tankönyvet ott azt írja, hogy "jeles az eredmény ha 500 leütésenként van 1 hiba, 4-es ha 2" és ez csak gépírás és másolási feladatnál. Ez önmagában csak annak a hiba aránya amivel leírjuk a sorokat. Ez azt jelenti, hogy /nem profi gépírás/ legyen egy közepes szintnek megfelelő, az 500 karakterenként 3 hibát enged meg. 35-40 karakter egy program sor (nyelv függő de azért ez jó átlagnak vehető) azaz az 500 karakter legyen kb. 15 sor, ebben lehet 3 hiba. Azaz simán elképzelhető csak a gépírás hibából 5 soronként 1. Amit vagy észreveszünk és javítjuk vagy nem vesszük észre és nem javítjuk. Ha ez szintatktikai hiba akkor a fordító eldobja de akkor is maradhat benne csak ebből a tényezőből néhány hiba. És ez nem azért van mert rossz programozók lennénk ez egy emberi adottság. Nyilván erre vannak módszerek, hogy ezeket kiszűrjük, korrigáljuk de nem mindent sikerül.

Tegyük fel, hogy 99%-os hatékonyságú a programozó saját hibajavítása a gépelési hibák területén. Azaz 100 hibából 99-et kijavít. Vegyük az előbbi hiba határt (5 sorban lehet 1 hiba). Ez azt fogja jelenteni (99%-os önellenőrzési hatékonyság) 500 soronként marad bent 1 hiba amit a programozó nem vett észre. Ezeknek is legyen egy olyan, hogy (ez gyan már nyelv függő) de ezeknek kb. 80% kibukik a fordításnál mert szintaktikai hiba. Azaz 100 hibából 20 marad bent. Ez azt fogja jelenteni, hogy 500x100 50 000 sorból 20-ban hagytunk bent hibát, ez azt jelenti, hogy kb. 2500 soronként marad bent egy hiba. Amiről nem tehetünk mert ez emberi adottság. És ez vagy kibukik a tesztnél vagy nem. És itt nagyon nagy hatékonyságokat vettem figyelembe a becslésnél. Ez azt jelenti, hogy minden olyan program ami 2500 sornál hosszabb abban simán bent maradhat csak gépélési hibából legalább 1. És minden másban "tökéletes" a programozó. És ez most egy durva becslés. Méréseket nem végeztem.

"szaktudás hiánya: rosszul implementált caching"

Nem. A szaktudás hiánya rengeteg dolgot jelenthet. Ráadásul nem is egzakt fogalom.

""figyelmetlenség": az if statement-ed tele van le nem kezelt lyukakkal"

Na, ez inkább a szaktudás hiánya.

Bár ugye ugyanazt a hibát el lehet követni mindkét okból.

"Gyengébbek kedvéért"

Azért egy kis beképzeltségért neked sem kell a szomszédba menni.

Ami pedig a kérdés lényegét illeti: egyéntől, vállalattól, a csapattól, és a konkrét feladattól is függ. De a hibák leggyakrabban a rossz menedzsment miatt maradnak a szoftverekben. (Legalábbis a nagyobb kereskedelmi szoftverekben.) Mert muszáj haamrabb végezniük, gyakori elvárás az egészségtelen mértékű túlóra, a leterhelt ember pedig eleve rosszabb kódot ír. Elodázni pedig nem lehet a kiadást, inkább kiadják hibákkal tele, aztán "majd megpatchelik valamikor".

9# Autó mondjuk más.

Vannak benne puha és kemény valósidejú rendszerek, ahol hardver/softwer redundaciák vannak. Ott igazán nem terténik olyan hiba, amit észre venne a vezető, mert agyon van tesztelve és sokszor különféle módon egyzserre több hardver/softwer elvégzi a számítást és abból kitalálja a rendszer, hogy "Biztosan minden rendben működik és jó az eredmény?"

Tehát ott szoftveres hiba miatt nem nagyon fogsz balesetbe kerülni.

Az meg, hogy az infotainment rendszerben van valami bug sem feltétlenül egyértelmű. Ha van is valami, valószínűleg nem látsz belőle semmit.

Szóval nem fog a vezető emiatt anyázni...