Kuinka suuri on bugin hinta?

Mulla on käytössä koneellani avoimen lähdekoodin ohjelmia, joissa on joitain bugeja. Osaako joku arvioida, kunka paljon yksittäisen bugin korjaaminen maksaisi, jos palkkaisi ohjelmoijan tekemään homman, kun käytössä on laajoja miljoonien rivien tuntemattomia koodeja (esim. GTK , Firefox yms.)? Vai onko halvempaa opetella itse paikallistamaan bugi?
Ilmianna
Jaa

43 Vastausta



Tuota on aika mahdoton arvioida.
Riippuu bugin vaikeudesta, koodin määrästä...
Pahimmillaan bugi voi vaatia koodin tekemisen aivan uudelleen helpoimmillaan se on ihan muutaman minuutin juttu. Jos se johtuu ihan näppäily virheestä/ yhdestä väärästä käskystä voi päästä helpollakin. Mutta jos se ongelma on koko koodin huonoudessa tulee se maksamaan paljon.

Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä.
Mutta älä tänne laita sitä turvallisuus syistä.
Paras olisi jos itse pystyt edes paikallistamaan ongelma kohdat.
Kommentoi
Ilmianna
Jaa
12 VASTAUSTA:
"Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä."

Totta. Useimmat ärsyttävät bugit ovat lähinnä sellaisia, että käytän avoimen lähdekoodin ohjelmistoja ja niissä ei sitten joku yksittäinen juttu toimi.

Esimerkiksi jos avaan geditin komennolla valgrind gedit, niin se tulostaa

==10123== LEAK SUMMARY:
==10123== definitely lost: 13,668 bytes in 33 blocks
==10123== indirectly lost: 30,647 bytes in 1,602 blocks
==10123== possibly lost: 39,671 bytes in 1,169 blocks
==10123== still reachable: 2,652,599 bytes in 49,389 blocks
==10123== suppressed: 0 bytes in 0 blocks

Mitenkähän noita kadonneita bittejä ja blokkeja kannattaisi lähteä etsimään? Vai kannattaako vaan tyytyä siihen, että asiat pystyy tekemään ohjelmalla vaikka konepellin alla kaikki ei olekaan täysin kunnossa?
Kommentoi
Ilmianna
Jaa
junnukoodari kirjoitti:
"Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä."

Totta. Useimmat ärsyttävät bugit ovat lähinnä sellaisia, että käytän avoimen lähdekoodin ohjelmistoja ja niissä ei sitten joku yksittäinen juttu toimi.

Esimerkiksi jos avaan geditin komennolla valgrind gedit, niin se tulostaa

==10123== LEAK SUMMARY:
==10123== definitely lost: 13,668 bytes in 33 blocks
==10123== indirectly lost: 30,647 bytes in 1,602 blocks
==10123== possibly lost: 39,671 bytes in 1,169 blocks
==10123== still reachable: 2,652,599 bytes in 49,389 blocks
==10123== suppressed: 0 bytes in 0 blocks

Mitenkähän noita kadonneita bittejä ja blokkeja kannattaisi lähteä etsimään? Vai kannattaako vaan tyytyä siihen, että asiat pystyy tekemään ohjelmalla vaikka konepellin alla kaikki ei olekaan täysin kunnossa?
Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.
Suljetun koodin bugeja on vielä vaikeampi etsiä, sekä korjata!
Siksi avoimmen lähdekoodin bukittomuus on mahdollisempaa, tosin bugi ja bugi on joskus makuasia, mikä on bugi. Toki ihan tyhmät jutut.. mutta ei niittä yleensä päädykkään käännettyyn koodiin.
Avoimen koodin yhteisö, on joukkovoimaa etsiä virheet..

Sitten on ohjelmia jotka etsii virheitä.. ja että yksi hemmo hakisi bugit?? Heh heh.
Kaikki mahdollista jos kaveri olisi oikea bugin haistaja :D

Takaisinkääntäjällä voi myös etsiä bugeja ja reikiä. mm google kunnostautunut tällä alalla.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.
"Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä.

Tässä 1 hyvä syy koodata Delphillä, vaikka M-Karia delphillä koodaaminen tuntuukin v*tuttavan aivan äärettömästi.

Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina.

Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä. Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä, ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot.

C ja C ovat aivan liian kryptisiä kieliä, että niillä saisi mitään laadukasta aikaiseksi.
Kommentoi
Ilmianna
Jaa
delphikoodaaja kirjoitti:
"Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä.

Tässä 1 hyvä syy koodata Delphillä, vaikka M-Karia delphillä koodaaminen tuntuukin v*tuttavan aivan äärettömästi.

Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina.

Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä. Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä, ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot.

C ja C ovat aivan liian kryptisiä kieliä, että niillä saisi mitään laadukasta aikaiseksi.
"siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

Valhe.

Maailmassa on vain kolme ohjelmointikieltä joita kelpuutetaan safety critical käyttöön, eli käyttöön joissa ohjelmointivirheitä EI SAA olla.

Ne kielet ovat C, C (subset) ja Ada). Javasta on myös tulossa versio safety critical käyttöön, eli joku subset C :n tapaan.

Se tarkoittaa siis sitä, että näillä kielillä on mahdollista tehdä ohjelmia joissa virheiden määrä on olematon. Sellaisia mitä voi laittaa vaikka lentokoneeseen, ydinohjukseen, avaruussukkulaan jne.

"Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä."

Taidat nyt sekoittaa tähän jotain garbage collectorin puutetta. Garbage collector on tekniikka jolla ohjelmoijan ei tarvitse samalla tavalla huolehtia varatun muistin vapauttamisesta vaan sitä on automatisoitu. Koska muistin vapauttaminen vie aikaa, voi GC:llä saada kivasti lisää suorituskykyä kun muistia vapautetaan silloin kun kuormitusta on vähemmän. Haittapuolena se ei ole sitten niin deterministinen, että jos GC_n tarvitsee vapauttaa se muisti syystä tai toisesta silloin kun on kuormaa niin sehän vie aikaa. Jos on tiukat reaaliaikavaatimukset, GC:tä ei ainakaan vielä voi käyttää.

Muistin käyttö ei siis olennaisesti ole mikään ongelma tässä koska muisti on sitä varten, että sitä käytetään ja saadaan tehostettua asioita. Ei sitä tyhjänä kannata pitää.

"Tässä 1 hyvä syy koodata Delphillä"

Jos se GC häiritsee niin C ja C kyllä toimivat sitten Object Pascalin tapaan ilman GC:tä, että tuo muistinkäyttöasia ei ole mikään syy vaan selvästikin valehtelet.

"Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina."

Delphiä käyttävät ohjelmoijat eivät missään nimessä ole kovia kilpailijoita, etenkin sellaiset jotka väittävät jonkun C :n olevan "kryptinen". Tuollaiset ovat ammattitaidottomia pilipaliohjelmoijia.

Ammattilaiselle ei ole mikään ongelma käyttää mitä tahansa ohjelmointikieltä. Ammattilaiselle ohjelmointikieli on vain työkalu sen työn tekemiseen ja se työkalu valitaan sen projektin vaatimusten mukaisesti mitä ollaan tekemässä ja valitsemalla tähän paras työkalu. Yksi työkalu ei ole kaikissa tilanteissa ikinä paras.

Delphi taas ei taas ei ole missään asiassa paras joten sitä ei ammattilaiset oikein käytä. 10v sitten sai melkein joka suhteessa parempaa maksutta.

"Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä."

Kuten jo sanoin, ovat niitä harvoja kieliä millä voi tehdä virheettömiä ohjelmia.

"Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä"

Roskaa. Kielten syntaksi ei olennaisesti houkuttele mihinkään virheisiin.

"ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot."

C on systeemitason ohjelmointikieli ja sillä ei juurikaan käsitellä merkkijonoja. Sillähän ohjelmoidaan kerneliä, laiteajureita, käyttöjärjestelmän kirjastoja ja jne. Tarve käsitellä merkkijonoja liittyy lähinnä sovellusohjelmointiin. Se toki onnistuu myös C:llä mutta on kömpelöä kun joka asia tehdään omalla funktiolla: https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html

Sovellusohjelmoinnissa käytetään sovellusohjelmointiin tarkoitettua työkalua ja siinä tietystikin homma käy merkkijonotyypillä.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.
Harhaluulo: "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

Tosiasia: Noin yleisesti ottaen C:llä, C++:lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä.

Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä. Delphillä koodatuista yleisin virhe on pikkuvirhe, joka aiheuttaa formin epäsiistin ulkonäön (ja toisinaan sen, että osa formin komponenteista jää piiloon).

Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä.

Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C++ -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista.

Tosin, jos koodaaja on oikeasti osaava, niin siinä tapauksessa
Delphillä koodatuista ohjelmista ei yleensä löydy ensimmäistäkään vakavaa tietoturva -aukkoa, ei vaikka ohjelma olisi käytössä 20 vuotta ilman yhtään muutosta itse koodiin.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

Valhe.

Maailmassa on vain kolme ohjelmointikieltä joita kelpuutetaan safety critical käyttöön, eli käyttöön joissa ohjelmointivirheitä EI SAA olla.

Ne kielet ovat C, C (subset) ja Ada). Javasta on myös tulossa versio safety critical käyttöön, eli joku subset C :n tapaan.

Se tarkoittaa siis sitä, että näillä kielillä on mahdollista tehdä ohjelmia joissa virheiden määrä on olematon. Sellaisia mitä voi laittaa vaikka lentokoneeseen, ydinohjukseen, avaruussukkulaan jne.

"Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä."

Taidat nyt sekoittaa tähän jotain garbage collectorin puutetta. Garbage collector on tekniikka jolla ohjelmoijan ei tarvitse samalla tavalla huolehtia varatun muistin vapauttamisesta vaan sitä on automatisoitu. Koska muistin vapauttaminen vie aikaa, voi GC:llä saada kivasti lisää suorituskykyä kun muistia vapautetaan silloin kun kuormitusta on vähemmän. Haittapuolena se ei ole sitten niin deterministinen, että jos GC_n tarvitsee vapauttaa se muisti syystä tai toisesta silloin kun on kuormaa niin sehän vie aikaa. Jos on tiukat reaaliaikavaatimukset, GC:tä ei ainakaan vielä voi käyttää.

Muistin käyttö ei siis olennaisesti ole mikään ongelma tässä koska muisti on sitä varten, että sitä käytetään ja saadaan tehostettua asioita. Ei sitä tyhjänä kannata pitää.

"Tässä 1 hyvä syy koodata Delphillä"

Jos se GC häiritsee niin C ja C kyllä toimivat sitten Object Pascalin tapaan ilman GC:tä, että tuo muistinkäyttöasia ei ole mikään syy vaan selvästikin valehtelet.

"Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina."

Delphiä käyttävät ohjelmoijat eivät missään nimessä ole kovia kilpailijoita, etenkin sellaiset jotka väittävät jonkun C :n olevan "kryptinen". Tuollaiset ovat ammattitaidottomia pilipaliohjelmoijia.

Ammattilaiselle ei ole mikään ongelma käyttää mitä tahansa ohjelmointikieltä. Ammattilaiselle ohjelmointikieli on vain työkalu sen työn tekemiseen ja se työkalu valitaan sen projektin vaatimusten mukaisesti mitä ollaan tekemässä ja valitsemalla tähän paras työkalu. Yksi työkalu ei ole kaikissa tilanteissa ikinä paras.

Delphi taas ei taas ei ole missään asiassa paras joten sitä ei ammattilaiset oikein käytä. 10v sitten sai melkein joka suhteessa parempaa maksutta.

"Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä."

Kuten jo sanoin, ovat niitä harvoja kieliä millä voi tehdä virheettömiä ohjelmia.

"Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä"

Roskaa. Kielten syntaksi ei olennaisesti houkuttele mihinkään virheisiin.

"ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot."

C on systeemitason ohjelmointikieli ja sillä ei juurikaan käsitellä merkkijonoja. Sillähän ohjelmoidaan kerneliä, laiteajureita, käyttöjärjestelmän kirjastoja ja jne. Tarve käsitellä merkkijonoja liittyy lähinnä sovellusohjelmointiin. Se toki onnistuu myös C:llä mutta on kömpelöä kun joka asia tehdään omalla funktiolla: https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html

Sovellusohjelmoinnissa käytetään sovellusohjelmointiin tarkoitettua työkalua ja siinä tietystikin homma käy merkkijonotyypillä.
M-paska sekoilee taas, saatana miten tyhmä juntti, joku voi olla.
Kommentoi
Ilmianna
Jaa
delphikoodaaja kirjoitti:
Harhaluulo: "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

Tosiasia: Noin yleisesti ottaen C:llä, C++:lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä.

Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä. Delphillä koodatuista yleisin virhe on pikkuvirhe, joka aiheuttaa formin epäsiistin ulkonäön (ja toisinaan sen, että osa formin komponenteista jää piiloon).

Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä.

Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C++ -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista.

Tosin, jos koodaaja on oikeasti osaava, niin siinä tapauksessa
Delphillä koodatuista ohjelmista ei yleensä löydy ensimmäistäkään vakavaa tietoturva -aukkoa, ei vaikka ohjelma olisi käytössä 20 vuotta ilman yhtään muutosta itse koodiin.
"Tosiasia: Noin yleisesti ottaen C:llä, C++:lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä."

Samalla tavalla kuin vaikka Delphillä. Olennaisesti tässä vaikuttaa koodirivien määrä ja kompeksisuus. Mitä yksinkertaisemmin saa asian tehtyä, sitä vähemmän on virhettä.

"Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä."

Roskaa. Miksi niitä Delphillä tehtyjä ohjelmia sitten päivitetään jatkuvasti? Skypeä korjataan monta kertaa vuodessa ja välillä on turvareikiä myös.

"Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä."

Normaalisti ne säädetään oikeaan kokoon. Tietysti ohjelman ulkoasun pitää toimia vaikka vaihdellaan teemaa, fontteja, DPI:tä jne. ja näyttö vaihdetaan vaikka 1024x768 koosta 4K näytöksi. Ei muuta kuin bugikorjausta kehiin vaan. Microsoft on noita ongelmia toki korjannut kun Windowsin vanhat rajapinnat juontavat juurensa jostain 80-luvulta mutta vanhaa WinAPI:a on tekohengitetty .NET 3.0:ssa saatiin noita tehtyä paljon fiksummin. HTML5 ja WinRT korjasivat skaalausongelmat lopullisesti.

"Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C++ -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista."

Toki, koska C/C++ koodia on moninkertaisesti enemmän kuin jotain marginaalista Delphi koodia. Sitä kun on koneessa vaikka 150 miljoonaa riviä C koodia ja sitten on tuhat riviä Delphi koodia niin onko se nyt mikään ihme jos C koodista löytyy enemmän virheitä?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Tosiasia: Noin yleisesti ottaen C:llä, C++:lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä."

Samalla tavalla kuin vaikka Delphillä. Olennaisesti tässä vaikuttaa koodirivien määrä ja kompeksisuus. Mitä yksinkertaisemmin saa asian tehtyä, sitä vähemmän on virhettä.

"Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä."

Roskaa. Miksi niitä Delphillä tehtyjä ohjelmia sitten päivitetään jatkuvasti? Skypeä korjataan monta kertaa vuodessa ja välillä on turvareikiä myös.

"Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä."

Normaalisti ne säädetään oikeaan kokoon. Tietysti ohjelman ulkoasun pitää toimia vaikka vaihdellaan teemaa, fontteja, DPI:tä jne. ja näyttö vaihdetaan vaikka 1024x768 koosta 4K näytöksi. Ei muuta kuin bugikorjausta kehiin vaan. Microsoft on noita ongelmia toki korjannut kun Windowsin vanhat rajapinnat juontavat juurensa jostain 80-luvulta mutta vanhaa WinAPI:a on tekohengitetty .NET 3.0:ssa saatiin noita tehtyä paljon fiksummin. HTML5 ja WinRT korjasivat skaalausongelmat lopullisesti.

"Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C++ -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista."

Toki, koska C/C++ koodia on moninkertaisesti enemmän kuin jotain marginaalista Delphi koodia. Sitä kun on koneessa vaikka 150 miljoonaa riviä C koodia ja sitten on tuhat riviä Delphi koodia niin onko se nyt mikään ihme jos C koodista löytyy enemmän virheitä?
Älä sotke näitä asiallisia keskusteluja, kun et tiedä ohjelmoinnista yhtään mitään. HuuHaa höpötykset muualle.
Kommentoi
Ilmianna
Jaa
Sotkijalle kirjoitti:
Älä sotke näitä asiallisia keskusteluja, kun et tiedä ohjelmoinnista yhtään mitään. HuuHaa höpötykset muualle.
Tiedän ohjelmoinnista valtavasti, kaikki mitä tuossa kirjoitin pitää paikkansa ja näitä asioita on mm. sinua viisaammat tutkineet vuosikymmeniä.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.
Sinähän olet äärimmäisen typeryyden huipentuma, emä valehtelija, keskustelujen sotkija, sinun tietosi on vain sitä että OSTA KAUPASTA, siinä on kaikki mitä tietotekniikasta tiedät.
Kommentoi
Ilmianna
Jaa
Valehtelijalle kirjoitti:
Sinähän olet äärimmäisen typeryyden huipentuma, emä valehtelija, keskustelujen sotkija, sinun tietosi on vain sitä että OSTA KAUPASTA, siinä on kaikki mitä tietotekniikasta tiedät.
Kaupasta ostamista harrastetaan sitten kun halutaan hankkia jotain mikä maksaa. Sitä vaan persaukisia asia ehkä kovin harmittaa jos ei ole vara ostella kaupasta.

Itse suosin aika paljon asioiden tekemistä itse tai maksutonta.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Tuohan on sopimuskysymys - millä ehdoilla korjaukset tehdään, jos tehdään.
Ja riippuu tietenkin myös siitä, kuinka kipeästi tarvit korjaukset.

Mutta avoimessa koodissahan kaikki bugit korjataan nopeasti ja ilmaiseksi, eikö se niin ollut?
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
Korjaukset tehdään ylläpidettyihin ohjelmiin tietysti nopeasti, ja kun koodi on avointa niin sen korjauksen saa maksutta kun joku sen tekee.

Korjauksen tekeminen tai teettäminen tietysti maksaa, kuten yleensäkin työvoima.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Helpoin tapa on ostaa ohjelmaan tuki. Kun maksat tuesta, voit avata tukitiketin virheestä ja korjaus tulee sitten päivityksistä.

Toiseksi helpoin tapa olisi ostaa tämä palveluna. Varmasti löytyy yrityksiä jotka tekee tätä palveluna.

Kolmas tapa olisi käyttää aikaa siihen, että rakentaisi testaus/kehitysympäristön koodille josta vikaa pitää etsiä ja käyttäisi automatisoituja menetelmiä virheiden löytämiseksi. Se on käytännössä viikon työ.

Käytännössä tätä varten ei siis kannata palkata ketään töihin, ellei tarkoitus ole korjata niitä virheitä enemmänkin.
Kommentoi
Ilmianna
Jaa
3 VASTAUSTA:
Ei pidä paikkaansa, mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta. Et itse osaa yhtään mitään kuin setkea näitä keskusteluja.

Linux Mint 18 Sarah
Xfce 64-bit
Kommentoi
Ilmianna
Jaa
Sotkijalle kirjoitti:
Ei pidä paikkaansa, mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta. Et itse osaa yhtään mitään kuin setkea näitä keskusteluja.

Linux Mint 18 Sarah
Xfce 64-bit
"Ei pidä paikkaansa"

Todista.

"mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta."

Vaikka siksi kun on pitkä kokemus ohjelmoinnista ja olen työnpuolesta antanut sitä ohjausta minua junnummille.

Sinun olisi parasta olla vaan hiljaa jos et asioista tiedä. Olennaisesti ohjelmointiin pätee perus projektisuunnittelun lainalaisuudet, että valittavissa on laatua, ominaisuuksia ja halpaa hintaa ja näistä voi valita kahta.
Kommentoi
Ilmianna
Jaa
Olisi hauskaa nähdä karvahatun kirjoittamaa spagettikoodia :)
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Avoimessa lähdekoodissa on bugeja niin paljon ettei kukaan pysty niitä korjaamaan.
Kommentoi
Ilmianna
Jaa
3 VASTAUSTA:
Koodin avoimuus ei liity mitenkään bugeihin.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Koodin avoimuus ei liity mitenkään bugeihin.
Niin, bugit liittyy vain sinuun, ja sinun höpötyksiin.

Linux Mint 18 Sarah
Xfce 64-bit
Kommentoi
Ilmianna
Jaa
Sotkijalle kirjoitti:
Niin, bugit liittyy vain sinuun, ja sinun höpötyksiin.

Linux Mint 18 Sarah
Xfce 64-bit
Mikä bugi? Todista.

Jos et kykene todistamaan väitettäsi, olet puhunut paskaa.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Olipa kysymys..
Voipi olla että tulis niitä bugeja vain lisää!!!

Moni yritys kuten Google, Firefox yms.. Käyttää Bugin etsintään erilaisia botteja.
Takaisinkoodaajilla saadaan selville osa, tietoturva bugeihin on kanssa testiohjelmat jotka ronkkii tunnettuja tapoja.

Pahempi ongelma on jotkut muut bugit kuin ohjalman lähdekoodin bugit.
Kääntäjien bugit, järjetelmän bugit tai sitten tahallaa näihin tehtyjä juttuja..

Ihan bugitonta ohjelaa tuskinlöydät, tai ainakin joku olis tehnyt jonkun eritavalla..
Ilmianna
Jaa
Avoimen lähdekoodin omistaa sen alkuperäinen tekijä.

Jos parannat sitä bugeja poistamalla, hyötyy siitä ohjelman alkuperäinen tuottaja.

Avoimen lähdekoodin perusperiaate on tehdä ohjelmasta aina vain parempi.

Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä.
Kommentoi
Ilmianna
Jaa
5 VASTAUSTA:
"Avoimen lähdekoodin omistaa sen alkuperäinen tekijä."

Tämä nyt taas riippuu lisensoinnista. Yleisesti ottaen jos jonkun koodin on avoimena julkaissut niin sitä voi käyttää kuka tahansa ja kehittää eteenpäin. Se lisenssin muutos ei mene niin, että se aiemmin julkaistujen lisenssi jotenkin muuttuisi.
Kommentoi
Ilmianna
Jaa
"Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä."

Useilla yleisesti käytetyillä avoimen koodin lisensseillä tuo jälkikäteen kaupalliseksi muuttaminen ei onnistu vaan kerran avoimena koodina julkaistu pysyy avoimena samoin kuin siitä edelleen kehitetyt versiot.

Parin yleisen avoimen koodin lisenssin toiminta hyvin lyhyesti esitettynä:

GPL -> Alkuperäinen ja siitä edelleen kehitetyt versiot pysyvät aina avoimena koodina eli GPL-lisensoitua koodia ei voi käyttää kaupallisen ohjelman pohjana.

BSD -> Alkuperäinen koodi pysyy aina avoimena. Siitä voidaan kehittää edelleen suljetun koodin kaupallinen versio, suljetun version oikeudet ovat sen kehittäjällä eivätkä alkuperäisen koodin kehittäjillä eli BSD-koodia voidaan hyödyntää kaupallisen ohjelman pohjana.

Kannattaisi tutustua asiaan ennen kommentointia.
Kommentoi
Ilmianna
Jaa
Tutustu_faktoihin kirjoitti:
"Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä."

Useilla yleisesti käytetyillä avoimen koodin lisensseillä tuo jälkikäteen kaupalliseksi muuttaminen ei onnistu vaan kerran avoimena koodina julkaistu pysyy avoimena samoin kuin siitä edelleen kehitetyt versiot.

Parin yleisen avoimen koodin lisenssin toiminta hyvin lyhyesti esitettynä:

GPL -> Alkuperäinen ja siitä edelleen kehitetyt versiot pysyvät aina avoimena koodina eli GPL-lisensoitua koodia ei voi käyttää kaupallisen ohjelman pohjana.

BSD -> Alkuperäinen koodi pysyy aina avoimena. Siitä voidaan kehittää edelleen suljetun koodin kaupallinen versio, suljetun version oikeudet ovat sen kehittäjällä eivätkä alkuperäisen koodin kehittäjillä eli BSD-koodia voidaan hyödyntää kaupallisen ohjelman pohjana.

Kannattaisi tutustua asiaan ennen kommentointia.
Itseasiassa ei...

Ohjelmaversio joka on julkaistu GPL lisenssillä pysyy GPL:nä, mutta tekijällä on edelleen oikeudet omaan työhönsä niin, että voi tehdä _omasta työstään_ uuden version mikä on suljettu. Se mikä on jo GPL:nä julkaistu toki pysyy GPL:nä. Jos projektiin on joku muu tehnyt GPL koodia niin ne tiedostot pitää siivota sieltä pois. GPL lisensoitua ohjelmaa voidaan myös käyttää kaupallisen ohjelmana pohjana ja niin tehdään myös paljon. Esimerkiksi vaikka tämä Suomi24.

Asian voisi yksinkertaistaa näin:
-GPL julkaistu koodi -> yhteisölliseen käyttöön. GPL koodi suojaa sen, että ohjelman lähdekoodi pysyy avoimena tämän koodin käyttäjille.
-BSD koodi -> vapaaseen käyttöön. Se on olennaisesti public domainia ja sillä voi tehdä mitä haluaa
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Avoimen lähdekoodin omistaa sen alkuperäinen tekijä."

Tämä nyt taas riippuu lisensoinnista. Yleisesti ottaen jos jonkun koodin on avoimena julkaissut niin sitä voi käyttää kuka tahansa ja kehittää eteenpäin. Se lisenssin muutos ei mene niin, että se aiemmin julkaistujen lisenssi jotenkin muuttuisi.
Ei edes tuo mennyt oikein, ottasit asioista selvää ennen kuin rupeat kirjottelemaan soopaa.

Linux Mint 18 Sarah
Xfce 64-bit
Kommentoi
Ilmianna
Jaa
Sotkijalle kirjoitti:
Ei edes tuo mennyt oikein, ottasit asioista selvää ennen kuin rupeat kirjottelemaan soopaa.

Linux Mint 18 Sarah
Xfce 64-bit
Kyllä meni oikein: https://opensource.org/osd

Tietokoneohjelmia on julkaistu vuosikymmeniä avoimesti ja niistä on forkattu uusia ohjelmia.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
GPL 3 ainakin on jotain sellaista mitä pitää vältää jos kyse on firmasta tai aikoo joskus softallaan tehdä rahaa. Myöskään ei pidä sisällyttää omaan softaan mitään noilla hyvin avoimilla lisensseillä katetuista kirjastoista tms. Joutuu nimittäin avaamaan omankin softan kaikille.

Avoimuus on kiva juttu mutta sen riskit ja vaarat pitää ymmärtää.

Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten.
Monasti on halvempaa ostaa softaa tai tukea kuin alkaa itse tuhraamaan. Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu.
Jos paketin saa vaikkapa 200e hintaan per asennus/vuosi, tukineen. Sehän on jopa edullista. Jos pitää omaa väkeä käyttää ongelmien selvittelyyn, tuolla rahalla ei tehdä kuin tunti töitä ja se on pois tuottavasta työstä mikä voi maksaa paljon enemmän.

Ilmaista lounasta ei ole. Ero tehdään sillä mistä milloinkin kannattaa maksaa ja minkä suhteen kannattaa ottaa riskiejä.
Kommentoi
Ilmianna
Jaa
2 VASTAUSTA:
"GPL 3 ainakin on jotain sellaista mitä pitää vältää jos kyse on firmasta tai aikoo joskus softallaan tehdä rahaa. "

Miksi muka?

"Myöskään ei pidä sisällyttää omaan softaan mitään noilla hyvin avoimilla lisensseillä katetuista kirjastoista tms. Joutuu nimittäin avaamaan omankin softan kaikille."

Sehän on lisenssistä riippuva asia, useinkaan koodin avoimuus ei haittaa liiketoimintaa ja esimerkiksi GPL lisenssissä ei ole useinkaan mitään merkitystä vaikka asiakkaalle toimitetun koodin pitää olla avoin koska ohjelmia tavallisesti myydään palveluna pilvestä ja asiakkaalle ei tarvitse toimittaa yhtään mitään.

"Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

Ei tietenkään tarvitse. Suurin osa yritysten laitteista käyttää Linuxia ja henkilöstön määrä näkyy vähenevän.

"Monasti on halvempaa ostaa softaa tai tukea kuin alkaa itse tuhraamaan."

Ostaa tai hankkii ilmaiseksi, ei merkitystä.

"Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu."

Minkä ihmeen "Linux paketin" ?

"Jos paketin saa vaikkapa 200e hintaan per asennus/vuosi, tukineen. Sehän on jopa edullista."

Yleensä saa ilmaiseksi ja niin hyvätasoista, että tukea ei tarvitse kuin kriittisemmät kohteet kuten vaikka jonkun rahoituslaitoksen tai operaattorin serveri. Tosin tiedän kyllä suomessa operaattoria joka ei ole viitsinyt mitään tukea hankkia vaan käyttää melko moneen ihmiseen vaikuttavassa palvelimessa maksutta.

"Jos pitää omaa väkeä käyttää ongelmien selvittelyyn, tuolla rahalla ei tehdä kuin tunti töitä ja se on pois tuottavasta työstä mikä voi maksaa paljon enemmän."

Minkä ongelmien selvittelyyn?

"Ilmaista lounasta ei ole."

Ohjelmat ovat useinkin ilmaisia nykyään.
Kommentoi
Ilmianna
Jaa
"Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

Ei tietenkään tarvitse. Suurin osa yritysten laitteista käyttää Linuxia ja henkilöstön määrä näkyy vähenevän.

Tietysti tarvitsee, vai sinäkö osaat ja tiedät jotain Linuxia ylläpitävien palkkaamisesta. Sinä joka et edes ymmärrä mikä Linux on.

Linux Mint 18 Sarah
Xfce 64-bit
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

Kuin sille ny pitäs "palkata omaa henkilöstöä tukea varten" jos henkilösttö ei osaa niin voihan ne irtisanoo ja palkata osaavii tilalle?

"Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu."

Mitä niitä testaan? testaushan voidaan suorittaa käytön aikana? (lisenssi ehdothan sit takaa et testaus ilmasta vaikka joku kuolis käytön aikana?)
Kommentoi
Ilmianna
Jaa
6 VASTAUSTA:
Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti.
Myös security pitää olla testattuna vähintään yleisimmillä reikiä etsivillä testijärjestelmillä. Kuormitus ja stabiliteetti pitää myös testata ennen käyttöönottoa.

Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro.

Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. Mitä itse tuumaisit jos tekisit vaikkapa taloa ja vasarasta lähtisi pää irti. Onko se hyväksyttävää?
Kommentoi
Ilmianna
Jaa
2323423 kirjoitti:
Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti.
Myös security pitää olla testattuna vähintään yleisimmillä reikiä etsivillä testijärjestelmillä. Kuormitus ja stabiliteetti pitää myös testata ennen käyttöönottoa.

Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro.

Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. Mitä itse tuumaisit jos tekisit vaikkapa taloa ja vasarasta lähtisi pää irti. Onko se hyväksyttävää?
"Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti."

Aika usein ei toimiteta kaikkea mahdollista mikä olisi kiva saada vaan toimitetaan henkilöresurssia järjestelmän tekemiseksi. Sitä sitten maksetaan joka kuukausi niistä henkilöresursseista ketkä lisää toiminnallisuutta tilaajan toiveiden mukaan.

Tällä tavalla saadaan järjestelmiä käyttöön nopeasti, jopa vain viikossa ja rahaa säästyy.

"Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro."

Android, Mac OS, Ubuntu ja Windows ovat yleisempiä.

"Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. "

Mitkä ihmeen bugit? Kyllä jokainen toiminto mitä tilaaja pyytää tehdään niin, että ensiksi tehdään hyväksymistestit, sitten tarvittavat yksikkötestit ja toteutetaan toiminto. Toiminto on valmis kun testit menee läpi ja se voidaan viedä tuotantoon.

Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.
Kommentoi
Ilmianna
Jaa
("Mitkä ihmeen bugit?"), no sinä tietysti olet se pahin bugi.

("Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.") Kyllä näkyy hyvin miten Microsoft korjaa, tekee tilalle kaksi bugia. Turha sinun mitään valehdella, se vaan on näin.

Linux Mint 18 Sarah
Xfce 64-bit
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti."

Aika usein ei toimiteta kaikkea mahdollista mikä olisi kiva saada vaan toimitetaan henkilöresurssia järjestelmän tekemiseksi. Sitä sitten maksetaan joka kuukausi niistä henkilöresursseista ketkä lisää toiminnallisuutta tilaajan toiveiden mukaan.

Tällä tavalla saadaan järjestelmiä käyttöön nopeasti, jopa vain viikossa ja rahaa säästyy.

"Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro."

Android, Mac OS, Ubuntu ja Windows ovat yleisempiä.

"Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. "

Mitkä ihmeen bugit? Kyllä jokainen toiminto mitä tilaaja pyytää tehdään niin, että ensiksi tehdään hyväksymistestit, sitten tarvittavat yksikkötestit ja toteutetaan toiminto. Toiminto on valmis kun testit menee läpi ja se voidaan viedä tuotantoon.

Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.
Kaikkea ei voi monimutkaisissa järjestelmissä ennakoida eikä testeillä voi kuitenkaan kattaa kaikkea mutta ainakin ne pitää pyrkiä kattamaan.
Jos tilaan vaikka web-kauppa sovelluksen niin vaatimuksissa varmasti lukee ylikuormanhallinta ja luotettava toiminta ylikuorman aikana.
Sinä sitten testaat sen, eikö niin ja osoitat että se on stabiili.

Osa bugeista tulee esiin vasta kun käytäjiä on enemmän ja samaan aikaan tehdään useita asioita kuten vaikkapa varmuuskopiota. Ajonaikainen varmuuskopio kannasta on jo sellaisenaan aika haasteellinen ja useimmille suunnittelijoille täysin mahdoton asia ilman että palvelu pysähtyy.

HA on sitten yksi asia mikä pitää monimutkaisiin systeemeihin aina vaatia koska koodarit ja suunittelijat tekee kuitenkin virheitä. Ylläpitäjät sitten kuorruttaa omilla virheillään koko sopan. Ylipäänsä kaikki tekee virheitä jatkuvasti, myös testaajat :-)
Kommentoi
Ilmianna
Jaa
323423 kirjoitti:
Kaikkea ei voi monimutkaisissa järjestelmissä ennakoida eikä testeillä voi kuitenkaan kattaa kaikkea mutta ainakin ne pitää pyrkiä kattamaan.
Jos tilaan vaikka web-kauppa sovelluksen niin vaatimuksissa varmasti lukee ylikuormanhallinta ja luotettava toiminta ylikuorman aikana.
Sinä sitten testaat sen, eikö niin ja osoitat että se on stabiili.

Osa bugeista tulee esiin vasta kun käytäjiä on enemmän ja samaan aikaan tehdään useita asioita kuten vaikkapa varmuuskopiota. Ajonaikainen varmuuskopio kannasta on jo sellaisenaan aika haasteellinen ja useimmille suunnittelijoille täysin mahdoton asia ilman että palvelu pysähtyy.

HA on sitten yksi asia mikä pitää monimutkaisiin systeemeihin aina vaatia koska koodarit ja suunittelijat tekee kuitenkin virheitä. Ylläpitäjät sitten kuorruttaa omilla virheillään koko sopan. Ylipäänsä kaikki tekee virheitä jatkuvasti, myös testaajat :-)
Kahdennetusta kannasta on helppo ottaa backuppia ajon aikana. Sitä kun käytetään aktiivisesti toista niin toisesta voidaan ottaa backuppia.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Kahdennetusta kannasta on helppo ottaa backuppia ajon aikana. Sitä kun käytetään aktiivisesti toista niin toisesta voidaan ottaa backuppia.
Lisäksi useimmiten riittää transaktiologiin perustuva varmistus, toki hieman RTO/RPO-määrityksistä riippuen.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Ohjelman oikeaksi todistaminen on vaikeaa. Siksi tyydytään yleensä testaamiseen. Joku yksinkertainen ohjelma voidaan todistaa oikeaksi tietyillä lähtöarvoilla. Jos koodia on miljoonia rivejä testaaminen on mahdotonta. Tiedetään, että ohjelma toimii tietyllä testiaineistolla. Tilastoihinkin vaikutetaan paljon siihen miten otos tehdään. Tutkimukseen saadaan rahoitusta ja toivotaan tietynlaisia tuloksia. C on minusta vaikeasti ymmärrettävää verrattuna Delphiin tai Pascaliin jolla tein ensimmäiset ohjelmani. C:llä saa toki lyhyttä ja tehokasta koodia, mutta ymmärtämisen kustannuksella. Toki on niitä jotka kirjoittavat luettavaa koodia, niin että toinenkin ymmärtää. Sitten on niitä joiden koodista ei saa tolkkua. Sitten kun siitä korjataan virheitä ja niistä tulleita virheitä ei koodia lopulta osaa kukaan ylläpitää. Debuggerilla löytyy yksinkertaiset virheet ja niiden korjaaminen joskus helppoa esim. ehtolause hieman väärin. C:n muistinhallinta ja erilaiset osoittimet hankalia seurattavia. Vahvasti tyypitetyssä kielessä virheitä tulee vähemmän.
Kommentoi
Ilmianna
Jaa
2 VASTAUSTA:
Vaikeaa ja vaikeaa. Jälkikäteen se kyllä on sitä, mutta jos suunnitteluvaiheessa jo hommat ovat tehty formaalia spesifikaatiokieltä käyttäen niin ohjelmasta saadaan kyllä tehtyä todistettavissa oleva matemaattinen malli.
Kommentoi
Ilmianna
Jaa
hjghjghfghgh kirjoitti:
Vaikeaa ja vaikeaa. Jälkikäteen se kyllä on sitä, mutta jos suunnitteluvaiheessa jo hommat ovat tehty formaalia spesifikaatiokieltä käyttäen niin ohjelmasta saadaan kyllä tehtyä todistettavissa oleva matemaattinen malli.
Tuo on totta. Mutta usein otetaan koodia ja erilaisia kirjastoja sieltä täältä. Osa siitä on testattu ja osa ei. Usein vielä kiire. Osaa koodista on vielä kirjoitettu eri kääntäjälle. Noissakin on hieman eroja. Jos aloitus tehty tosiaan fiksusti todistaminen on mahdollista ja monilta virheiltä vältyttäisiin. Silti pitää tietysti testata.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Kuinka suuri on bugin hinta?

Mulla on käytössä koneellani avoimen lähdekoodin ohjelmia, joissa on joitain bugeja. Osaako joku arvioida, kunka paljon yksittäisen bugin korjaaminen maksaisi, jos palkkaisi ohjelmoijan tekemään homman, kun käytössä on laajoja miljoonien rivien tuntemattomia koodeja (esim. GTK , Firefox yms.)? Vai onko halvempaa opetella itse paikallistamaan bugi?

5000 merkkiä jäljellä

Peruuta