Mulla oli joskus töissä ongelma, että en osannut korjata kirjastossa olevaa koodia. Kuuluuko IT-alan ammattilaisen taitoihin osata korjata toisen koodia vai voiko ohjelmistoja kehittää siten, että ohjelmistotuotannossa voi hyödyntää kirjastoja, mutta jos kirjastossa on bugi, niin sitä ei korjata vaan tehdään kirjaston ulkopuolelle uusi funktio, joka kiertää bugin ja kutsutaan sitä?
Viestistäsi ei käy ilmi, onko kyseessä talon sisäinen kirjasto vai jonkun ulkopuolisen tahon kehittämä. Mikäli kyseessä on ulkopuolisen tahon kehittämä, niin voisi olla fiksuinta yrittää saada korjaus mukaan kirjastoon kehittäjän toimesta ettei kirjaston päivittyessä tarvitse erikseen itse ylläpitää omaa korjattua versiotaan.
Jaska kirjoitti:
Kuuluuko IT-alan ammattilaisen taitoihin osata korjata toisen koodia
Joo.
jalski kirjoitti:
(20.06.2023 22:33:52): Viestistäsi ei käy ilmi, onko kyseessä talon...
Näin juuri. En lähtis korjaileen mitään talon ulkopuolisen tahon tekemää API:a/Frameworkikkä. Ikävää tilanne tulee jos jostan syytä tekijät tai tekijät otavat lopettaneet koodin päivittämisen kokonaan. Ja tarkoitan nyt julkisissa repoissa olevia Open Source kirjastoja. Eli kanattaa olla kokemusta mitäs kopasataan netistä. Jos niillä on vain yhdenmiehen harrastelija kehittämässä koodia niin on suuri riski, että se jotuu joskun loetaan kehittämisen, ylläpidon ja tuen.
Jaska kirjoitti:
Kuuluuko IT-alan ammattilaisen taitoihin osata korjata toisen koodia vai voiko ohjelmistoja kehittää siten, että ohjelmistotuotannossa voi hyödyntää kirjastoja, mutta jos kirjastossa on bugi, niin sitä ei korjata vaan tehdään kirjaston ulkopuolelle uusi funktio, joka kiertää bugin ja kutsutaan sitä?
Yleensä itse teen niin että mahdollisuuksien mukaan joko teen bugiraportin tai korjaan itse bugin ja lähetän siitä Pull Requestin. Ja jos homma pitää saada valmiiksi ennen kuin mahdollinen PR otetaan mukaan kirjastoon tai bugi korjataan muiden toimesta, niin teen workaroundin omaan koodiin, johon laitan kommenttiin viittauksen bugiraporttiin tai PR:iin. Sitten jos myöhemmin bugi korjaantuu kirjastossa, niin workaround on helppo poistaa.
walkout_ kirjoitti:
En lähtis korjaileen mitään talon ulkopuolisen tahon tekemää API:a/Frameworkikkä.
Itse olen kyllä monesti lähettänyt Pull Requesteja selviin bugeihin ulkopuolisissa kirjastoissa ja ne on useimmiten hyväksyttykin.
Miksi ulkopuolisen tahon tekemää APIa ei voisi korjata, jos sen koodi on saatavilla? Vai oliko tuo vaan sinun henkilökohtainen tapa.
Grez kirjoitti:
(21.06.2023 08:28:25): ”– –” Yleensä itse teen niin että mahdollisuuksien...
No siis joskus ulkopuolisen tekemä API on todettu vaaralliseksi ja poistettu jakelusta kokonaan ja kopiot ovat vain niiden kovoilla joilla sattuu olemaan ne. Sittenmin koko taho tehnyt samat apit erinimellä kokonaan uusiksi, joka tarkoittaa vain sitä, että pitää päivitää niihin sitten ja korjata omat koodit toimiviksi uusilla apeilla. Ja toki jos lyötää itse bugeja jonkun tekemästä koodista niin siitä voi pistää ilamoituksen ja pyytää korjaamaan että API on kaikelle eikä vain itselle samanlainen. Vain harvoissa tapauksissa kuten PHP Maven jolla sai testata ja ajaa Continous Integraatiota PHP-koodiin J2EE-pohjaisessa CI-softassa katosi kokonaan kuten tekiä. Mutta uusia esim. Jenkinsiin on jo olemasa joten no suuri hätä.
Ja jotkut taas ekee API:ja versionia 1, 2, jne ja toiset vain kokoajan yhtä ja samaa samassa ropossa Composerilla ladattavaki.
Totta kai koodia pitää osata korjata, jos se on tehty samoilla vehkeillä kuin millä itsekin koodaa työkseen. Jos ei osaa lukea ja debugata toisen tekemää koodia, ei ole koodari eikä ansaitse olla töissä.
Aktiivisessa kehityksessä olevaan kolmannen osapuolen kirjastoon en lähtisi koskemaan, ellei tarkoituksena ole sitten julkaista omaa korjausta protokollan mukaisesti. Kunnollisessa kehysympäristössä komponentteja voi kyllä ohittaa ihan konffien kautta, jolloin voi korvata viallisen komponentin omalla koodillaan ja saada bugit korjattua silläkin tavalla.
Olen myös toisaalta laajentanut olemassa olevaa koodia tukemaan minun haluamiani ominaisuuksia ohittamalla tarvittavat komponentit ja kirjoittamalla omat tilalle. Tällaisia asioita ei välttämättä kannata edes yrittää saada ns. upstreamiin, jos ne eivät ole selkeästi yleishyödyllisiä. Uusien ominaisuuksien saaminen läpi voi muutenkin vaatia väittelyä frameworkin ylläpidon kanssa.
muuskanuikku kirjoitti:
Totta kai koodia pitää osata korjata, jos se on tehty samoilla vehkeillä kuin millä itsekin koodaa työkseen. Jos ei osaa lukea ja debugata toisen tekemää koodia, ei ole koodari eikä ansaitse olla töissä.
Mikäli kyseessä on joku matalan tason kirjasto, on aika kärjistettyä olettaa jokaisen koodarin kykenevän siinä oleva virhe suoraan korjaamaan.
Juuri kuten Grez kirjoitti, eli pull requestia tai muuta vastaavaa menemään. Aivan normaalia toimintaa. Millä muulla tavoin kriittisen bugin saisi kirjastosta korjattua?
vesikuusi kirjoitti:
Juuri kuten Grez kirjoitti, eli pull requestia tai muuta vastaavaa menemään. Aivan normaalia toimintaa. Millä muulla tavoin kriittisen bugin saisi kirjastosta korjattua?
Mietin vaan, että jos saan oman ohjelman toimimaan korjaamalla bugin, niin miten voi olla varma, ettei jonkun toisen tekemä ohjelma mene rikki, jos jonkun funktion toiminta muuttuu? Siksi ajattelin, että säilytetäänkö alkuperäinen kirjasto muuttumattomana. Kerran kävi niin, että oma ohjelma lakkasi toimimasta kun kirjaston tekijä päivitti koodia ja piti muokata paljon omaa koodia, jotta se toimisi kirjaston uuden version kanssa.
Jaska kirjoitti:
Mietin vaan, että jos saan oman ohjelman toimimaan korjaamalla bugin, niin miten voi olla varma, ettei jonkun toisen tekemä ohjelma mene rikki, jos jonkun funktion toiminta muuttuu?
Tottakai jokin ohjelma voi mennä rikki kun kirjaston toiminta muuttuu, mutta muutokset tulee kirjaston uuteen versioon, joten ne muut ohjelmat eivät lakkaa toimimasta ennen kuin päivittävät kirjaston ja siinä yhteydessä luonnollisesti ajetaan testit uusiksi.
Toisaalta ihan vaan selkeiden bugien korjaaminen ei yleensä riko mitään, ellei sitten kirjasto tai sitä käyttävä ohjelma ole melkoista purkkaa. Enemmänkin siinä käy niin että monet ohjelmat alkavat toimia paremmin.
Tietenkin jos ei ole huolellinen, voi käydä niin että yhden bugin korjaaminen tuo tilalle toisen tai jopa useamman bugin. Eli tarkkana täytyy olla. Jos kyseessä on hyvin ylläpidetty kirjasto, niin mahdolliset koodiehdotukset yleensä tarkistaa joku muukin kriittisesti.
Jaska kirjoitti:
(21.06.2023 22:08:54): ”– –” Mietin vaan, että jos saan oman ohjelman...
Mikäli kyseessä on ihan rehellinen bugi, niin sen korjaaminen ei riko toisten ohjelmia, mikäli he ovat käyttäneet kirjastoa tarkoitetulla tavalla.
Käyttäjien ohjelmien rikkoutuminen estetään muutoksien tekemisen jälkeen ajettavilla testeillä kuten yksikkötesteillä ja komponenttitesteillä.
Tietysti kirjastoon voi tulla rikkovia muutoksia ja sitten käyttäjien on muutettava koodiaan, mikäli haluavat käyttää kirjaston uudempaa versiota.
Katsos vaan kun kirjoitettiin Grezin kanssa käytännössä sama viesti ;P
vesikuusi kirjoitti:
Juuri kuten Grez kirjoitti, eli pull requestia tai muuta vastaavaa menemään. Aivan normaalia toimintaa. Millä muulla tavoin kriittisen bugin saisi kirjastosta korjattua?
Onko tämä mahdollista jos 3. osapuolen tiimi ei kutsu sinua Githubissa ks. repoon korjailemaan koodia?
walkout_ kirjoitti:
vesikuusi kirjoitti:
Juuri kuten Grez kirjoitti, eli pull requestia tai muuta vastaavaa menemään. Aivan normaalia toimintaa.
Onko tämä mahdollista jos 3. osapuolen tiimi ei kutsu sinua Githubissa ks. repoon korjailemaan koodia?
Pull requestin voi lähettää omalla GitHub-tunnuksellaan mihin tahansa julkiseen GitHub-repoon. Pull request joko hyväksytään (eli mergetään), hylätään, tai pull requestin muutoksiin pyydetään korjauksia ja parannuksia ennen hyväksymistä. Toki jos projekti on kuollut ja sen kehittäjät eivät käsittele lähetettyjä pull requesteja, niin sitten lähetetty pull request jää roikkumaan GitHub-projektin "pull requests"-listaukseen (josta muut käyttäjät voivat halutessaan poimia sen omiin versioihinsa).
vesikuusi kirjoitti:
Millä muulla tavoin kriittisen bugin saisi kirjastosta korjattua?
Jos projektin kehittäjät/ylläpitäjät eivät reagoi bugirapsoihin tai pull requesteihin (melko harvinaista jos kyseessä on oikeesti kriittinen bugi aktiivisesti ylläpidetyssä kirjastossa), niin ainoaksi vaihtoehdoksi jää bugin korjaaminen omaan patchattuun versioon kirjastosta. Tai voihan sitä myös kirjastoa käyttävään softaprojektiin koodata workaround-purkkaa kirjaston bugien ympärille, mutta se on tietysti rumempi vaihtoehto eikä välttämättä aina edes mahdollista.
vesikuusi kirjoitti:
Mikäli kyseessä on ihan rehellinen bugi, niin sen korjaaminen ei riko toisten ohjelmia, mikäli he ovat käyttäneet kirjastoa tarkoitetulla tavalla.
Ei pidä paikkaansa. Kukaan ei edellytä, että jokainen kirjastoa käyttävä koodari erikseen varmistaisi, että kaikki kutsutut funktiot toimivat dokumentaatiossa asetettujen speksien mukaisesti. Se on kirjastoa ylläpitävän tahon vastuulla.
Lisäksi jos kirjastossa on bugi ja bugin voi jollain tavalla kiertää omassa koodissa, niin se purkkakorjaus voi hajota kirjastoon tehdyn bugikorjauksen jälkeen.
vesikuusi kirjoitti:
Käyttäjien ohjelmien rikkoutuminen estetään muutoksien tekemisen jälkeen ajettavilla testeillä kuten yksikkötesteillä ja komponenttitesteillä.
Eipä nyt oikeastaan. Testeillä ei estetä hajoamista vaan tunnistetaan hajoaminen ennen ohjelman jakamista eteenpäin.
Parempi vastaus olisi, että asiallisella versioinnilla ja paketinhallinnalla varmistetaan se, ettei oma softa hajoa odottamatta kolmannen osapuolten kirjastoihin tehtyjen muutosten johdosta. Tästä syystä PHP-maailmassakin on käytetty paketinhallintaa, Composeria, jo kymmenkunta vuotta.
muuskanuikku kirjoitti:
Ei pidä paikkaansa. Kukaan ei edellytä, että jokainen kirjastoa käyttävä koodari erikseen varmistaisi, että kaikki kutsutut funktiot toimivat dokumentaatiossa asetettujen speksien mukaisesti. Se on kirjastoa ylläpitävän tahon vastuulla.
Siis tarkoititko että kirjastoa ylläpitävän tahon vastuulla oleva asia on "funktioiden toimiminen dokumentaatiossa kuvatulla tavalla"? No silloinhan dokumentaation vastaisesti toimivan (eli bugisen) funktion korjaaminen on juuri sitä mitä kirjaston ylläpitäjän kuuluukin tehdä. Mikä tässä on ongelmana?
Ja Vesikuusen väitehän oli, että jos ohjelma toimii kirjaston dokumentaation speksin mukaan (tarkoitetulla tavalla), niin se ei rikkoudu siitä että kirjasto korjataan toimimaan dokumentaation mukaan. Voitko avata tilannetta jossa tämä ei pidä paikkaansa.
Toki kaikki tiedämme että ohjelmat voivat rikkoutua bugikorjauksista. Silloin kirjastoa on käytetty muulla kuin tarkoitetulla tavalla. Ketä kiinnostaa?
Jos joku käyttää kirjastoa dokumentaation vastaisesti, niin eihän se lähtökohtaisesti kirjaston ylläpitäjän ongelma ole. Toki esim. joku tukisopimus voi tehdä siitä sellaisen.
muuskanuikku kirjoitti:
Lisäksi jos kirjastossa on bugi ja bugin voi jollain tavalla kiertää omassa koodissa, niin se purkkakorjaus voi hajota kirjastoon tehdyn bugikorjauksen jälkeen.
Kaikkihan on mahdollista, mutta onpa sitten paska purkkakorjaus.
Mutta joo, luulen että viittaa tässä huonosti dokumentoituihin ja rakenteeltaan epäloogisiin kirjastoihin, jolloin koodaaminen niitä käyttäen nimenomaan edellyttää, että yritetään arvata mitä mikäkin funktio oikeasti tekee. Tässä tapauksessa sanoisin, että kannattaa välttää moisia kirjastoja tai jos niitä on pakko käyttää niin tiedostaa se, että päivittäminen uuteen versioon voi räjäyttää oman softan.
muuskanuikku kirjoitti:
Eipä nyt oikeastaan. Testeillä ei estetä hajoamista vaan tunnistetaan hajoaminen ennen ohjelman jakamista eteenpäin.
No kylläpäs nyt saivarrellaan. Jos hajoaminen on tunnistettu ennen kirjaston jakamista eteenpäin niin silloinhan käyttäjien ohjelmat eivät hajoa, koska rikkinäistä kirjastoa ei ole jaettu käyttäjille. Toisin sanoen tarkennuksesi on merkityksetön.
Deffi kirjoitti:
vesikuusi kirjoitti:
Millä muulla tavoin kriittisen bugin saisi kirjastosta korjattua?
Jos projektin kehittäjät/ylläpitäjät eivät reagoi bugirapsoihin tai pull requesteihin (melko harvinaista jos kyseessä on oikeesti kriittinen bugi aktiivisesti ylläpidetyssä kirjastossa), niin ainoaksi vaihtoehdoksi jää bugin korjaaminen omaan patchattuun versioon kirjastosta. --
Kyllä, ja yleensä tämä onkin itsellä mennyt näin:
vesikuusi kirjoitti:
Kyllä, ja yleensä tämä onkin itsellä mennyt näin:
- patchaa itse
- tee pull request
- toivo, että korjaus tulee joskus upstreamiin
Miksi pitäsi patchata itse? Itse tykkään käyttää mielummin aikani siihen projektiin mitä teen enkä lukea tuhansia rivejä muiden koodia. Helpompaa kirjoittaa vähän lisää koodia omaan projektiin ja laittaa kommentti, että voi myöhemmin korvata kirjaston funktiolla, kun saavat virheen korjattua. Avoimen lähdekoodin projektit ovat laadultaan kaikkein pahimpia elleivät langat ole tiukasti jonkun käsissä. Onneksi nykyään kaikki tarvitsemani toiminnallisuus tulee 8th:n mukana ja mahdollisiin bugeihin saa bugiraportin jälkeen korjaukset melkein välittömästi. Lisäksi suurin osa ehdottamistani parannuksista on toteutettu.
Grez kirjoitti:
Jos joku käyttää kirjastoa dokumentaation vastaisesti, niin eihän se lähtökohtaisesti kirjaston ylläpitäjän ongelma ole. Toki esim. joku tukisopimus voi tehdä siitä sellaisen.
Koodari lukee dokumentaatiota sen verran kuin tarvitsee kerätäkseen ymmärrystä kirjaston toiminnasta. Koodarin vastuulla ei ole jokaisen kirjaston tuottaman lopputuloksen vertaaminen speksien yksityiskohtiin. Se on auditointia ja kuuluu muille tahoille.
Se kuuluu vielä täysin "tarkoitettuun käyttötapaan", että pienellä speksin lukemisella oppii tekemään järkeviä asioita. Jos kirjasto tuottaakin joitakin virheellisiä tuloksia, niin niitä ei aina edes huomaa, jos ne eivät sillä hetkellä aiheuta ongelmia oman koodin toimintaan.
vesikuusi kirjoitti:
Toisin sanoen tarkennuksesi on merkityksetön.
Olisit lukenut koko viestin. Lainaamasi virkkeen alla oli pidempi täsmennys.
muuskanuikku kirjoitti:
Koodarin vastuulla ei ole jokaisen kirjaston tuottaman lopputuloksen vertaaminen
Yleensähän jos kirjasto toimii väärin, niin koodari joko huomaa sen siinä että hänen kirjastoa käyttävä ohjelmansa toimii väärin tai sitten koodari ei huomaa mitään kun ohjelma ei käytä kirjastoa tavalla, joka bugittaa. Tai sitten ongelman huomaa loppukäyttäjä.
Eli ei koodarin tarvitsekaan aktiivisesti verrata kirjaston toimivuutta dokumentaatioon.
Jos kuitenkin koodari sattuu ymmärtämään väärin mitä kirjaston kuuluisi tehdä ja perustaa koodinsa siihen miten kirjasto toimii väärin, niin koodarin vastuulla on käytännössä sitten sen oman koodin korjaaminen kun kirjasto korjataan (mikäli ottaa uuden version käyttöön). Ihan samalla tavalla kuin muidenkin itse tekemiensä bugien korjaaminen. Bugin taustalla oleva syy ei ole hirveän olennainen.
No yleisesti, siksi kirjastoissa pitäisi olla ci-putki kytketty testeillä pull requesteihin, jotta voidaan varmentua että kyseessä ei ole ns. breaking change. Eli sen bugikorjauksen ei pitäisi luonnollisesti rikkoa mitään, koska silloin kyse ei ole bugista vaan uuden ominaisuuden lisäämisestä tai vanhan ominaisuuden muutoksesta.
Aihe on jo aika vanha, joten et voi enää vastata siihen.