Tiede > Yleistä tieteestä palstalla oli bugeihin liittyvä keskustelu ja jatkan siitä.
Onko arkkitehtuurin suunnittelu kunnolla ennen ohjelmointia ja muutenkin laadukas ohjelmointiprosessi oikeasti työläämpi, vai ollaanko monissa it-firmoissa vain tietämättömiä?
Jos hutiloi alussa ja tekee sitten oireidenmukaisia paikkauksia, niin siinä kai voi mennä jopa enemmän työtä saavuttaa tietyllä tavalla oikein toimiva ohjelmisto kuin kunnolla tekemällä?
Jos ei ole yliopistossa koulutettu ohjelmoija, niin kunnolla tekemisen opin tuleminen tietoon on sattuman varassa. Ehkä jotkut tyytymättömät asiakkaat opastavat ohjelmointiopin lähteille...
Joissain firmoissa kai täytyisi pitää kuukausien loma, että voisi opetella kunnolla ohjelmointia? Ja sitten tuotteen rakentamisen pitäisi alkaa tavallaan tyhjästä uudelleen, suurelta osin ainakin. Ja se voi olla liikaa nykytalouden puristuksessa.
Oli miten oli, pitää olla ohjelmointityökaluja, jotka johdattavat kunnolla tekemiseen tai joilla ei voi tehdä muuten kuin tiettyjä laatuprosesseja noudattaen.
Mahdollisesti pitää olla ohjelmointijärjestelmä, johon syötetään suunnitelmat, ja sitten automaatio/AI hoitaa sen mitä perinteisesti ohjelmoinniksi ymmärretään. Sitten alkaisi olla suorastaan vaikea tehdä bugisia ohjelmistoja?
Onko arkkitehtuurin suunnittelu kunnolla ennen ohjelmointia ja muutenkin laadukas ohjelmointiprosessi oikeasti työläämpi, vai ollaanko monissa it-firmoissa vain tietämättömiä?
Jos hutiloi alussa ja tekee sitten oireidenmukaisia paikkauksia, niin siinä kai voi mennä jopa enemmän työtä saavuttaa tietyllä tavalla oikein toimiva ohjelmisto kuin kunnolla tekemällä?
Jos ei ole yliopistossa koulutettu ohjelmoija, niin kunnolla tekemisen opin tuleminen tietoon on sattuman varassa. Ehkä jotkut tyytymättömät asiakkaat opastavat ohjelmointiopin lähteille...
Joissain firmoissa kai täytyisi pitää kuukausien loma, että voisi opetella kunnolla ohjelmointia? Ja sitten tuotteen rakentamisen pitäisi alkaa tavallaan tyhjästä uudelleen, suurelta osin ainakin. Ja se voi olla liikaa nykytalouden puristuksessa.
Oli miten oli, pitää olla ohjelmointityökaluja, jotka johdattavat kunnolla tekemiseen tai joilla ei voi tehdä muuten kuin tiettyjä laatuprosesseja noudattaen.
Mahdollisesti pitää olla ohjelmointijärjestelmä, johon syötetään suunnitelmat, ja sitten automaatio/AI hoitaa sen mitä perinteisesti ohjelmoinniksi ymmärretään. Sitten alkaisi olla suorastaan vaikea tehdä bugisia ohjelmistoja?
Vastaukset 4
Vanhimmat
"Onko arkkitehtuurin suunnittelu kunnolla ennen ohjelmointia...."
On. Ja ennenkaikkea hitaampi. Jos kuppaat liikaa
projektin alussa, kilpailija vie asiakkaat.
"Jos hutiloi alussa ja tekee sitten oireidenmukaisia paikkauksia, niin siinä kai voi mennä..."
Kyllä.
"Ehkä jotkut tyytymättömät asiakkaat opastavat ohjelmointiopin lähteille..."
Päinvastoin.
Usein asiakkaat haluavat valmistumaisillaan olevaan
työhön "heti" muutoksia jotka pilaavat koko casen.
"Mahdollisesti pitää olla ohjelmointijärjestelmä, johon syötetään suunnitelmat..."
Kokemuksesta voin sanoa, että ongelmaksi muodostuu
että mistä saada tällainen bugiton ohjelmageneraattori?
AI? ohoh...
"
"Ehkä jotkut tyytymättömät asiakkaat opastavat ohjelmointiopin lähteille..."
Päinvastoin.
Usein asiakkaat haluavat valmistumaisillaan olevaan
työhön "heti" muutoksia jotka pilaavat koko casen.
"
Tuota lausetta kirjoittaessani minulla oli lähinnä mielessä vähintään kymmenien tuhansien ehkä miljoonien ihmisten käyttämät ohjelmistot ja verkkopalvelut. Sellaiseen käyttäjämäärään luulisi mahtuvan paljon ohjelmoinnin asiantuntijoita, ellei ole kyseessä joku lasten/teinien peli/palvelu.
hmmm, toisaalta en tiedä miten paljon - jos ollenkaan - sellaiset firmat ulkoistaa ohjelmointityötään siten että ovat asiakkaita, ja kerrotaanko siitä julkisesti eli loppukäyttäjille. Imagon kannalta voisi olla hyväkin jos loppukäyttäjät syyttelee alihankkijoita bugeista.
Äärimmäisen vaikea tehdä virheitä jos ohjelmointi on graafisten komponenttien yhdistelyä viivoilla. Kaikki virheet näkyvät todella nopeasti ja toisten tekemiä juttuja tarkastaa parilla silmäyksellä. Ihminen on kuitenkin sopeutunut lähinnä käsittelemään kuvia ja kyky lukea ja kirjoittaa on evoluutiossa vielä aika keskeneräinen juttu.
Labview:n patentit ovat umpeutumassa, joten meillä taitaa olla pian useampiakin aidosti graafisia kieliä.
Huomatkaa myös että ohjelmointi on noilla kielillä myös huomattavasti tavanomaista nopeampaa. Myös ohjelmien kehittäminen moniytimisiin helpottuu kun koko systeemin toiminnan voi nähdä ja käsittää helposti.
> Äärimmäisen vaikea tehdä virheitä jos ohjelmointi
> on graafisten komponenttien yhdistelyä viivoilla.
Ei pidä paikkaansa.
Kaikkia ongelmia ei voi ratkaista yksinkertaisella ohjelmalla. Monimutkaisen ohjelman tekeminen on virhealtista, ja tulosta on vaikea ymmärtää, oli ohjelma kirjoitettu ykkösinä ja nollina, perinteisellä ohjelmointikielellä tai viivoina ja palloina.
Jokainen, joka on kuvannut vähänkin suurempien ohjelmien toimintaa viivoilla ja palloilla, tietää että jossain vaiheessa kuvauksessa on todella paljon viivoja ja palloja. Silloin ohjelman virheettömyys on kaikkea muuta kuin helppo selvittää. Tarkkaan määriteltyjenkään ominaisuuksien selvittäminen (esim. voiko ohjelma jäädä jumiin) ei yleensä onnistu edes supertietokoneiden avulla.
On tietenkin mahdollista (olen nähnyt omin silmin), että sopivasti rajattuihin tehtäviin visuaaliset ohjelmointikielet sopivat hyvin. Esimerkiksi yksinkertaiset, korkeintaan muutaman kymmenen tilan tilakoneet näyttävät visuaalisella ohjelmointikielellä kuvattuna oikein mukavilta verrattuna vastaavan tilakoneen toteuttavaan ohjelmakoodiin.