Mások hibái miatt lesz sokszor hibás a mi programunk is

Mások hibái miatt lesz sokszor hibás a mi programunk is
2010-09-24T14:37:16+02:00
2010-09-26T19:47:08+02:00
2022-10-27T08:41:56+02:00
  • Szerintem nem lehet 100% biztonsággal megmondani, hogy mely programban lesznek hibák és melyikben nem.

    Az mondjuk valószínű, hogy a kezdők programjaiban biztosan több a bug. Talán a biztonsági rés is, de az a profik programjaiban is előfordul.

    Ide vehetnénk azt is, hogy az idő elteltével mennyire lesz futtatható/használható a program, vagy éppen nem. Ez sem utolsó szempont, illetve programhibát okozhatja az is, hogy csak régi a program.
    Régi progrmokra jellemző lehet az is, hogy mindenféle csomagokat meg dll-eket nem talál a program, ez is nagy öröm.

    Hibát amúgy a "profik" is elkövetnek, egyszerű példa erre egy egyszerű MPEG fájl lejátszás, mert sok lejátszó/codec nem tudja felismerni, hogy Mpeg1 vagy Mpeg2 formátumú a videó és nem megfelelő módon próbálja lejátszani.
    Az én XP-m hibáit most nem sorolom, de "vicces", hogy az intéző a bal oldali "mappák" ablakban nem frissíti ha berakok egy új CD-t és a régi nevét és tartalmát jeleníti meg. De majd megnézem friss telepítés után, lehet hogy csak egy vírus vagy más hasonló program módosította az eredeti működést.
    Mutasd a teljes hozzászólást!
  • Ajánlom elolvasásra még e témában:

    http://hungarian.joelonsoftware.com/Articles/LeakyAbstractions.html

    vagy

    http://hungarian.joelonsoftware.com/Articles/BacktoBasics.html

    meg persze az összes többit is érdemes olvasni
    Mutasd a teljes hozzászólást!
  • Itt jutunk el a zárt/nyilt forrás kérdésébe.
    (Persze ez nem az ingyens/fizetős kérdés, hiszen számos nagyon jó fizetős komponenshez adják a forrást is)

    A nyilt forrás elvi esélyt ad, hogy egy nem mainstream probléma esetén (pl. magyar nyelvi változat hibája) esetén is lehessen lépni.
    Persze lehet kérni a fejlesztőktől is hibakeresést és javítást, de ez már nagyon kérdéses, hisz manapság egyre ritkább az olyan felelőségteljes fejlesztő cég, amelyik elvi kötelességének érzi a hibák javítását, nem marketing és költség/haszon számítások adják a döntések alapját.

    Én legalábbis tartózkodni szoktam minden olyan komponens használatától, amelyet nem kapok meg forrásban, már csak azért is, hogy egy-egy verzió váltásnál ne kerüljek (anyagi vagy időbeli) függésbe a gyártótól [az új verziót is meg kell venni, mégha nem is ad nekem többletet, csak az új keretrendszer verzióhoz igazodik, de előfordul hogy csak soká jön ki az új verzióhoz is igazodó komponens]. Aztán végső kegyelemdöfésként ott az esély, hogy a gyártó dobja a projectet és zsákutca a komponens használata.

    Vagyis mégha soha bele sem nézek a kódba, akkor is fontos a forrás megléte, csupán megnyugtatásul; de a beleolvasás mégis gyakran előfordul, hiszen sok nem korrekten dokumentált esetben a forrás a végső menedék.
    Mutasd a teljes hozzászólást!
  • Azért szerintem egy komponens használata még mindig jobb, mert azt sokan használják és így sokkal több tesztelésen megy át mint egy vadi új saját kód.

    Előbbiből mondjuk nem feltétlenül következik utóbbi. Egy jó programozó pl. már eleve általában jobb kódot készít, mint amilyen szintre a rossz programozó kódja még sok-sok tesztelés után is el tud jutni (a rossz tervezésből adódó "javíthatatlan hibákról", hiányosságokról nem is beszélve, amiken a tesztelés sem segít). Ugyanúgy, mint ahogy egy nyílt forrású szoftver sem lesz feltétlenül biztonságosabb egy zárt kódúnál, még akkor sem, ha nem csak többen láthatják, de tényleg többen nézegetik is.

    Tehát ez a tétel csakis akkor áll meg ha amúgy a sokak által használt komponenst kb. hasonló - vagy jobb - képességű programozók készítették, mint amilyen a saját kódot írná.

    Pont ezért van, hogy pl. míg komolyabb nyelvek és platformok - Delphi, .NET, stb. - esetén viszonylag bátran használok 3rd party komponenseket relatíve felületes vizsgálat után is, addig pl. a PHP-s, Perl-es, linuxos könyvtáraknál sokkal inkább hajlok a saját implementáció elkészítésére akkor is, ha amúgy létezik már több kész 3rd party megoldás is, mert utóbbiak minsőge, megbízhatósága és rugalmassága általában kritikán aluli, még a viszonylag elterjedt és sokak által használt példányok esetében is. (Tisztelet a kivételnek persze.)
    Mutasd a teljes hozzászólást!
  • Azért szerintem egy komponens használata még mindig jobb, mert azt sokan használják és így sokkal több tesztelésen megy át mint egy vadi új saját kód.
    Mutasd a teljes hozzászólást!
  • Másrészről meg inkább vicces felvetés volt
    Mutasd a teljes hozzászólást!
  • Igazából én olyasmire gondoltam, hogy miről lehet megismerni az ilyet. Például ha az idióta cowboy-coder kollégától kapok valamit, akkor már szinte meg sem nézem, mert tudom hogy tele van indokolatlan hibákkal.
    Mutasd a teljes hozzászólást!
  • Mások hibái miatt lesz sokszor hibás a mi programunk is


    Igaz, hogy mások hibái miatt sokszor kell "szívni", de magunk is rengeteget hibázunk. Vagyis: semmi nem jogosít fel arra, hogy valamilyen fellépő hiba miatt, elsősorban mások hibáira hivatkozva a magunkéval ne foglalkozzunk...
    Mutasd a teljes hozzászólást!
  • Mi a kérdés?

    A probléma az, hogy egyre nagyobb százalékban külső kódot használunk még arra is, amit mi magunk is megírnánk. És elég ha a használt külső kódok között valamelyik nem működik jól, már borult, az egyébként tökéletes programunk.

    Lehet az alattunk lévő kód önmagában szintén jó, csak nem volt valmire felkészítve, vagy az általa használt szintén külső kód nem szabványos, hibás.

    Képbe jön itt az oprendszer, a meghajtó programok, a fordítók és az általuk használt külső kódot. Ha úgy vesszük az ember "tehetetlen" ezek ellen, csak imátkozhat, hogy ne történjen hiba. Főleg, hogy az oprendszer alól bármilyen jöttment program kicserélheti a használt DLL-eket sajátra, még az oprendszert is módosítják, a 100% kompatibilitás sem létezik. A fordító által elkövetett hibákról sem tehet a programozó.

    A "biztonsági rés" a szememben kevésbé hiba, mert legalább fut a program és nem feltétlenül mondhatjuk, hogy a programozó hibája.

    Bugok meg már a legelső programokban (gépekben) is lehettek (igazi bogarak voltak is).

    Az sem kizárt, hogy földönkívüliek szándékosan gyártják a vírusokat és hardver/szoftver hibákat, így lassítva a fejlődésünket, nehogymár beérjük őket.
    Mutasd a teljes hozzászólást!
  • Ez van. nem kódolhatsz mindent magad, és nincs garantálva, hogy a saját könyvár biztonságosabb lenne.
    Mutasd a teljes hozzászólást!
  • Jah kérem a negyedik generációs nyelvek már csak ilyenek. Mindennek ára van. Félóra alatt, bárki barkácsolhat egy ötszáz soros programot, telis-tele vezérlőkkel úgy, hogy közben háromszor ér hozzá a klavihoz. (Ebből kétszer azért, mert útban van.)
    Közben minden egyes újabb komponens "formra húzásával" vállalja a kockázatot. Azt, hogy frankó ami mögötte van. De ott a bogár az ember fülében: mi van, ha mégse? Azután kiderül, hogy nem csak a fülében, de a kódban is circeg. Ez persze csak idővel derül ki, amikor élesben tolja majd a júzer, mert a béta teszt alatt minden olyan f**a ahogy illik. A bug várat magára. Amikor már majdnem minden rendben, a rendszer felállt, működik is "csontnélkül" vagy kéthete, akkor a bug lecsap. Fejlesztőkém meg ott áll egyedül, kiterítve, és próbál magyarázatot adni, ami egy idő után már csak gyenge konfabuláció, vagy tán még az se.
    Mindenesetre egyvalamire rájöttem. Az innen-onnan összeguberált komponensek csak fejfájást okozhatnak hosszútávon. (Néha még az integráltak is. Lásd Delphi->Indy ami nagyon gyenge, egyem a szívét.)
    Mutasd a teljes hozzászólást!
  • Ez az, amikor már a framework, framework-jének a framework-jét használnuk és 2 kattintással kész a program egy UML ábrából. Ilyenkor a hibát nehezen lehetne a fejlesztőre kenni.
    Mutasd a teljes hozzászólást!
  • Tehát létezik a bugok Ádámja és Évája. Vajon milyen szoftverben?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd