Ubuntu Suomen keskustelualueet
Muut alueet => Yleistä keskustelua => Aiheen aloitti: matsukan - 25.09.14 - klo:09.49
-
http://www.theverge.com/2014/9/24/6840697/worse-than-heartbleed-todays-bash-bug-could-be-breaking-security-for
Tämä on tällä hetkellä alhaalla :
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
Linux users got a nasty surprise today, as a security team at Red Hat uncovered a subtle but dangerous bug in the Bash shell, one of the most versatile and widely used utilities in Linux. It's being called the Bash bug, or Shellshock. When accessed properly, the bug allows for an attacker's code to be executed as soon as the shell is invoked, leaving the door open for a wide variety of attacks. Worse yet, it appears the bug has been present in enterprise Linux software for a long time, so patching every instance may be easier said than done. Red Hat and Fedora have already released patches for the bug. The bug also affects OS X, and while the company has yet to release an official fix, this Stack Exchange post contains details on how Mac users can check for the vulnerability and patch it once identified.
-
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-6271
Tähän tuli korjaus viimeisimmässä turvapäivityksissä Ubuntun 14.4:ssa.
edit:
http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
-
Virallinen info Suomessa:
https://www.viestintavirasto.fi/tietoturva/tietoturvanyt/2014/09/ttn201409251726.html
Tuossa hyvä postaus aiheesta:
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
Pari muuta viihdyttävää:
https://gist.github.com/anonymous/929d622f3b36b00c0be1
http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html
Joo, aika hyvä security fail. Eiköhän tuohon tule aika nopeasti korjaukset, varsinkin kun toi github paketti on vapaasti käytettävissä, eikä se ollut muutenkaan kovin vaikea käyttää.
Uh, onneksi on päivittäiset automaagiset päivitykset käytössä.
-
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: varoitus: x: ignoring function definition attempt
bash: virhe tuotaessa ”x”:n funktiomääritystä
this is a test
Itsekäännetty/pätsätty bash ollut käytössäni melkein heti kun tuon näin. Lainasin tuolta vinkkejä:
http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-it (http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-it)
-
Mutta ilmeisesti vain LTS-versiot on paikattu. 14.10:iin ei ole vieläkään tullut, ei pääpalvelimellekaan.
- muuten semmoinen mielenkiintoinen seikka oli jossain tuosta asiasta kertovassa postissa että BASH:in merkitys on vuosien varrella kasvanut ja siksi siitä on vaikea päästä eroon. Ja *kaikkialla* hyper-super-virtuoosienkin sivuilla annetaan ymmärtää että BASH sätkii enää heikosti.
- niinkuin tuo BASH:in suurimpia nimiä, Stephane Chazelas joka asiasta ensiksi kertoi. Josta voi päätellä että likaisia on jauhot.
-
Bashiin tuli toinen päivitys, vuorokausi edellisen jälkeen
bash (4.3-7ubuntu1.1) to 4.3-7ubuntu1.3
koska ensimmäinen oli ilmeisesti vain osittainen korjaus.
-
Lähdekoodista käännetty on v4.3.11:
bash --version
GNU bash, versio 4.3.11(1)-release (x86_64-pc-linux-gnu)
Sain kokeiluissa sivutuotteena sotkettua testikoneella promptin väärän näköiseksi, mistähän tuo nyt tulikaan käännöskokeiden lisukkeena... Muilla koneilla normaali.
-
Laiska pääsee näköjään helpommalla, ohjelmalähteistä päivitetty:
GNU bash, versio 4.3.11(1)-release (i686-pc-linux-gnu)
Jostain syystä promptikin näyttää entiseltä. :D
-
Onkohan muissa komentotulkeissa löytyny samaa tai vastaavan kaltaista tietoturva-aukkoa?
Ite kun pitäis Skrolliin tehdä juttu zsh-komentotulkista, niin tuli jo sen takii vaihdettuu normi-tunnukselle zsh.
-
Testi
x='() { :;}; echo HAAVOITTUVA' bash -c : paljastaa vian CVE-2014-6271, mutta se ei paljasta onko CVE-2014-7169 korjattu.
Onko joku saanut selville millä testillä voin tarkistaa onko CVE-2014-7169 korjattu?
Esimerkiksi cygwin/bash on vasta osittain korjattu.
-
Onkohan muissa komentotulkeissa löytyny samaa tai vastaavan kaltaista tietoturva-aukkoa?
Ite kun pitäis Skrolliin tehdä juttu zsh-komentotulkista, niin tuli jo sen takii vaihdettuu normi-tunnukselle zsh.
Kyseistä aukkoa ei löydy zsh:sta (ei käsittääkseni muistakaan shelleistä), mutta toki mistä tahansa shellistä saa avattua kompromisoidun bash istunnon, jos haavoittuva versio bashista on koneella asennettuna.
-
Testi x='() { :;}; echo HAAVOITTUVA' bash -c : paljastaa vian CVE-2014-6271, mutta se ei paljasta onko CVE-2014-7169 korjattu.
Onko joku saanut selville millä testillä voin tarkistaa onko CVE-2014-7169 korjattu?
Esimerkiksi cygwin/bash on vasta osittain korjattu.
Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) - Red Hat Customer Portal (https://access.redhat.com/articles/1200223)
Näyttäisi kertovan, onko molemmat korjattu.
Minulla
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: rivi 1: lauseoppivirhe lähellä odottamatonta avainsanaa ”=”
bash: x: rivi 1: `'
bash: virhe tuotaessa ”x”:n funktiomääritystä
date
cat: /tmp/echo: Tiedostoa tai hakemistoa ei ole
tuntuisi vastaavan CVE-2014-7169 testin negatiivista tulostusta:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directoryeli päivämäärä ei tulostu.
-
Kiitos salai!
Olen päivittänyt Cygwin:n tänään Windows-koneella, ja testin tulos on:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: rivi 1: lauseoppivirhe lähellä odottamatonta avainsanaa ”=”
bash: x: rivi 1: `'
bash: virhe tuotaessa ”x”:n funktiomääritystä
26. syysta 2014 16:21:11
$
eli toinen korjaus ei ole vielä tullut perille (valitsin lähteeksi ftp.funet.fi).
-
Ongelmaa ei vielä ole edes aloitettu korjata niin että se tuntuisi: http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/
Mutta BASH:ia kehittää yksi ukko, eikä voine vaatia että se kykenee yksin juuri mihinkään. Ja päinvastoin kun on kerrottu: lukemattomat ohjelmat käyttää BASH:inpalveluja. Ja joissain ominaisuuksissa BASH on ainoa joka kynnelle kykenee; ei ne voi siirtyä käyttämään toisia.
-
Minulla on vähän semmoinen epäilys, että eiköhän kaikista unix-like käyttisten tukemista komentotulkeista joilla on pitkälle kehittyneet skriptausominaisuudet löytyne turvareikiä, kun oikein etsimään aletaan. Kun on paljon ominaisuuksia on paljon mahdollisuuksia niiden väärinkäyttöönkin.
-
Ja joissain ominaisuuksissa BASH on ainoa joka kynnelle kykenee; ei ne voi siirtyä käyttämään toisia.
Mikähän semmoinen ominaisuus olisi, kysyy vannoutunut zsh:n käyttäjä? ;D
-
ShellShock-ominaisuus ?
-
Niin, ominaisuus, vai bugi? http://paste.lisp.org/display/143864
Tuossa kirjoittelin tällaisen ja totesin, että onko noi sitten vikoja vai ominaisuuksia, vai mitä. Been there, done that. Lopputulos voi olla hirveä sotku, jos tehdään sellaisia asioita mitä ei ollut tarkoitus alunperin edes tehdä.
Kenen vika kun tällasia tehdään? Ei kenenkään? Tällaisella ajatusproessilla helposti syntyy tuollaisia ongelmia, vaikka hommat sujuukin 'tosi kätevästi'. http://pastebin.com/v3syAmtj Jossain vaiheessa jonkun olisi pitänyt huomata jotain, sitten kun ei huomaa, niin kenen vika on? Ei kenenkään?
Sinänsä älytöntä, että mitään ulkopuolista dataa edes passataan bashin kautta, huono käytäntö. Mutta 'se vaan on niin kätevää', niin siksi sitä tehdään ja se luo myös ongelmia.
-
Niin, ominaisuus, vai bugi? http://paste.lisp.org/display/143864
Sanoisin myöskin että se on ominaisuus joka on aina ollut eikä bugi ja aivan samoilla perusteilla kun katsoo historiaa. Se että se ominaisuus halutaan tukkia tällä hetkellä on myöskin ymmärrettävää. Myöskin komentotulkin tehtävä oman näkemykseni mukaan on aina ollut olla komentotulkki ja turva on jo vuotanut muualla jos komentotulkkiin tai sen ympäristöön pääsee asiattomat käsiksi. Komentotulkin tehtävä _on_ ajaa komentoja.
-
Sanoisin myöskin että se on ominaisuus joka on aina ollut eikä bugi ja aivan samoilla perusteilla kun katsoo historiaa. Se että se ominaisuus halutaan tukkia tällä hetkellä on myöskin ymmärrettävää.
Se, että ympäristömuuttujilla voi määrittää funktioita on ilman muuta ominaisuus (tosin se on ominaisuus, johon saattaa liittyä turvariskejä).
Mutta on hyvin vaikea uskoa, että tarkoituksella olisi luotu ominaisuus, joka suorittaa funktiomäärityksen perään ympäristömuuttujaan ympätyt komennot, koska muuten ympäristömuuttujiin asetettuja komentoja ei suoriteta. Eli tämä osa on mielestäni ihan selvästi bugi eikä "dokumentoimaton ominaisuus".
Myöskin komentotulkin tehtävä oman näkemykseni mukaan on aina ollut olla komentotulkki ja turva on jo vuotanut muualla jos siihen pääsee asiattomat käsiksi.
Tämä on siinä mielessä ongelmallinen bugi, että komentojen ajaminen ei vaadi pääsyä komentotulkkiin. Esim. dhclient vastaanottaa ympäristömuuttujia dhcp-serveriltä ja välittää ne ajamilleen bash-skipteille (jolloin ympäristömuuttujiin "funktiomääritysten perään jemmatut" komennot ajetaan...rootin oikeuksin).
-
Joo, tiedetään. Ja samaa mieltä myös epäloogisuudesta.
Esim. dhclient vastaanottaa ympäristömuuttujia dhcp-serveriltä ja välittää ne ajamilleen bash-skipteille
Jos dhcp-serveri lähettää clientille korruptoituneita ympäristömuuttujia niin minä osoittelen kyllä silloin ensisijaisesti dhcp-serveriä. Toki client voi myös filtteröidä mitä laittaa ympäristöön (jos se muuttaa sitä ennen scriptien kutsua).
Yksi hyvä asia näissä ympäristöissä kuitenkin on: Ne periytyvät eli ongelma ei "valu ylöspäin" ja prosessin loppuessa sen ympäristö hävitetään. Silti tuossa on suuri vaara _jos_ ympäristöön pääsee käsiksi ei toivotulla tavalla. Seuraava samasta ympäristöstä käynnistys ajaa koodin.
-
Jos dhcp-serveri lähettää clientille korruptoituneita ympäristömuuttujia niin minä osoittelen kyllä silloin ensisijaisesti dhcp-serveriä. Toki client voi myös filtteröidä mitä laittaa ympäristöön (jos se muuttaa sitä ennen scriptien kutsua).
Ilman muuta ongelman "lähde" tässä tapauksessa on verkossa toimiva murrettu tai tietoisesti pahantahtoinen palvelin, joka vastailee dhcp-kutsuihin.
Mutta tietoturvaongelmat, jotka saattavat olla käyttäjän oman hallinnan ulkopuolella on lähtökohtaisesti vakavampia kuin omin toimin korjattavissa/hallittavissa olevat ongelmat. Tietoturvan lähtökohta (tai tavoite) on, että käyttäjä voi omin toimin tehdä koneestaan turvallisen (mihin ei tietenkään koskaan täysin päästä).
EIhän tämä bugi tietysti ainoa ongelma ole, jos kone sattuu saamaan dhcp-vastauksia pahantahtoiselta lähteeltä esim. avoimessa verkossa.
-
Mutta on hyvin vaikea uskoa, että tarkoituksella olisi luotu ominaisuus, joka suorittaa funktiomäärityksen perään ympäristömuuttujaan ympätyt komennot, koska muuten ympäristömuuttujiin asetettuja komentoja ei suoriteta. Eli tämä osa on mielestäni ihan selvästi bugi eikä "dokumentoimaton ominaisuus".
Toisaalta funktion määrittely voi vaatia ajamaan ne ohjelmat. Siinä mielessä voihan se olla ollut haluttukin ominaisuus, jonka turvavaikutuksia vain ei loppuun saakka ollut mietitty.
En tiedä enkä nyt ehdi tarkistaa, onko Bashissa samanlaista funktion viivästettyä latausta kuin zsh:ssa, missä ”autoload -U funktio” vain merkitsee funktion sisällön ladattavaksi silloin, kun sitä tarvitaan.
-
Mutta on hyvin vaikea uskoa, että tarkoituksella olisi luotu ominaisuus, joka suorittaa funktiomäärityksen perään ympäristömuuttujaan ympätyt komennot, koska muuten ympäristömuuttujiin asetettuja komentoja ei suoriteta. Eli tämä osa on mielestäni ihan selvästi bugi eikä "dokumentoimaton ominaisuus".
Toisaalta funktion määrittely voi vaatia ajamaan ne ohjelmat. Siinä mielessä voihan se olla ollut haluttukin ominaisuus, jonka turvavaikutuksia vain ei loppuun saakka ollut mietitty.
Mahdollista? Totta kai (en mä väitä tietäväni, mitä koodaajan pään sisällä on liikkunut), mutta eikös lähes kaikissa tapauksissa olisi järkevintä laittaa ne "vaadittavat" komennot sinne funktion sisään?
Enkä mä ainakaan itse olis jättänyt tuollaista ominaisuutta dokumentoimatta, jos olisin sen tarkoituksella jostain syystä lisännyt.
-
Tässä taas yhdenlaista näkemystä tähän:
https://weev.livejournal.com/409835.html
Sekä viimeisntä infoa Viestintävirastosta:
https://www.viestintavirasto.fi/tietoturva/tietoturvanyt/2014/09/ttn201409291547.html
-
Enkä mä ainakaan itse olis jättänyt tuollaista ominaisuutta dokumentoimatta, jos olisin sen tarkoituksella jostain syystä lisännyt.
Dokumentointi on ollut monessa isoksi kasvaneessa projektissa kompastuskivi – jopa koko UNIXia on aikanaan aiheesta moitittu siitä, että ainoa käyttöopas on ollut lähdekoodi ::)
-
että ainoa käyttöopas on ollut lähdekoodi
En yhtään ihmettele, musta ainakin useissa projekteissa dokumentoinnin ylläpitäminen on kaikkein rasittavin homma, varsinkin jos sitä dokumentointia on liikaa, liian monessa paikassa ja niissä on cross referenssejä ja samaa asiaa moneen kertaan vähän eri tavalla. Jotain man tyylistä sivua vielä just pystyy ja jaksaa ylläpitää, mutta laajempi dokumentointi, uuh ääh. No sitä voi ylläpitää joku dokumenointi-osasto josta seuraa se, että dokumentointi on kuitenkin aina väärin.
Mä erityisesti vältän monesti dokumentoimasta asioita, joita pelkään että pitäisi jatkuvasti jatkossa päivittää. Kun asiakkaat ei kuitenkaan halua maksaa dokumentoinnin päivittämisestä jne.
-
Minulla oli joskus vaihe jolloin dokumentointi tökkäsi aina siihen kun aloin ihmetellä miksi mä tämmöstä joudun selostamaan - aika monta parannusta tuli tehtyä koodiin ihan vaan siksi ettei tarvi selitellä. Mutta se riippuu rojektista tietty.
-
aika monta parannusta tuli tehtyä koodiin ihan vaan siksi ettei tarvi selitellä.
Toinen hyvä tyyli olisi pitää DRY asenteesta tiukasti kiinni. Aina kun jotain kysytään, jos se puuttuu dokumentaatiosta se lisätään sinne, eikä kysymyksiin vastata. Sitä kautta saisi järjestelmällisesti 'lazy' tyyliin saatettua dokumentaation ajantasalle. Eikä tarvitsisi vastata (samoihin) kyselyihin, uudelleen ja uudelleen.
-
Opiskeluaikana itselläni oli onni päätyä kesätyöhön jossa jouduin tekemään ylläpitoa, jossa ei ollut tarkoitus muuttaa toiminnallisuutta toiseksi. Tein siis puhtaita refactoring-muutoksia. Tein niitä isossa ohjelmistossa. Kaiken huipuksi annettu refactoring-tehtävä koski io-moduleiden kutsuja, eli jouduin korjausta tehdessäni pitämään silmällä ohjelmiston peruslogiikkaa. Jouduin tarkistamaan missä kohdassa luetaan indeksoitua tiedostoa peräkkäin pääavaimella, missä kohdassa sivuavaimella, jne. Minun piti huolehtia siitä että logiikka ei seonnut. Tämä harjaannutti hahmottamaan vierasta koodia tavalla jota en mitenkään muuten olisi voinut oppia. Ylläpito opettaa paljon enemmän kuin se että aina väännetään uutta koodia uusien hienojen menetelmien mukaan.
Tuosta kesätyöstä asti olen aina ajatellut että ihan jokainen ohjelmoija pitäisi opiskeluvaiheessa panna refactoring-sulkeisiin. Vain sillä taattaisiin että kukin oppii hahmottamaan ohjelmiston rakennetta ja laatimaan testitapauksia jatkuvaa testausta varten. Voi kai koodia hakea vaikka GitHubista ja käydä sitä läpi refactoring-tekniikalla vaikkei olisikaan aikeissa palauttaa korjauksia mihinkään, kunhan vaan ottaa sormituntumaa ihan harjoituksen vuoksi. Ja nyt kun eteen tulee näitä heartbleed ja shellshock -tapauksia, löydän itseni pohtimasta ihan vakavasti sitä kuinka paljon vikoja voitaisiin löytää ja korjata ihan ohimennen jos opiskelijoilla teetettäisiin refactoring-sulkeisia avoimen koodin kanssa.
Jossain määrin samaa voisi soveltaa dokumentteihinkin, ehkä.
-
En tiedä enkä nyt ehdi tarkistaa, onko Bashissa samanlaista funktion viivästettyä latausta kuin zsh:ssa, missä ”autoload -U funktio” vain merkitsee funktion sisällön ladattavaksi silloin, kun sitä tarvitaan.
Ei ole vakiona mutta pystyy lisäämään erikseen "enable -f" kautta lisämodulina.
http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/x6632.html (http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/x6632.html)
-
Tein siis puhtaita refactoring-muutoksia.
Tuo refactoring juuri kuten kuvasit, olisi todella hienoa. Mutta tämän asian saa yleensä menemään totaalisen pieleen ne asiakkaat. Yleensä mielenkiintoa maksaa määrittelyistä, dokumentoinnista, testaukseta, ei tahdo löytyä. Löytyy vain mielenkiintoa saada joku koodinkikkare tehtyä mahdollisimman halvalla ja nopeasti. Kukapa maksaisi refactoringista yhtään mitään, miksi kukaan haluaisi tehdä sitä, eihän sillä saavuteta mitään 'lisäarvoa'.
Yleensä tavoitteena on mm. lisätä uusia ominaisuuksia törkeillä kludgeilla mahdollisimman nopeasti. Sillä ei ole mitään väliä jos nuo tuottavat tietoturva tai suorituskyky ongelmia. Kunhan saadaan jotain 'toimivaa' nopeasti ulos.
Nimimerkillä, been there, done that.
Jos sanot että nyt haluttais käyttää 10-50 euroa siihen, että vähän mietiskellään tätä teidän koodia. Niin asiakkaat nauraa sut heti pihalle.
No niin foorumilaiset? Kuka haluaa sponsoroida Open Source / Linux koodin refaktorointia kymppitonnilla? Anyone? Luulen vaan että vähän hiljaista pitää.
Monesti puhutaan että IT projektien laatu on kuraa ja hommat tehdään vähän sinne päin ja huonosti. No kyllä, useinmiten se tuntuu olevan myös tilaajan ensisijainen tavoite, valitettavasti.
Tuollainen shellshockin kaltainen ominaisuus voi ihan hyvin tulla siitä että ääääh, ei hitto, tätä ei pysty hoitamaa nyt tämän kautta kun... Mutta hei, jos mä modaan tuota koodia niin että voin suorittaa siellä vapaavalintaista koodia, niin sitten voin syöttää datassa sen koodin ja voin tehdä tosi kätevästi kaikenlaisia virivirejä, mitä muut sanoi että on kauhean hankalaa muka tehdä. Jees, no niin, nyt tää on hoidettu, ähäkutti. ;)
Sitä siis saa, mitä tilaa. Lisäksi tuollaisen ominaisuuden implementointia voi jopa pitää suorastaan nerokkaana, kaikki muut tollot väitti että homma on jotenkin vaikeeta, mutta nyt sujuu nää asiat tosi kätevästi. Eikä enkä juuri siinä kyseisessä tilanteessa ollut mahdollista syöttää suoraan käyttäjien antamaa dataa.
Jos menet kertomaan että projektin tietoturvasertifiointi maksaa vaikka 50000 euroa, niin vastaus on hyvin nopeasti, että me ei tarvita sitä, eikä meitä kiinnosta. Kuhan se nyt vaan 'toimii'. Ja toimimisella ei todellakaan tarkoiteta mitään kokonaisvaltaista testausta, vaan sitä, että se jotenkuten täyttää liiketoiminta tarpeet, eikä aiheuta kohtuuttomia ongelmia, vaikka ei toimisikaan edes noiden osa-alueiden osalta ihan aukottomasti. Joten, ketä kiinnostaa tietoturva? Useimpia ei kiinnosta, piste. Tämä sama kuvio toistuu jatkuvasti uudestaan ja uudestaan, joten ei pitäisi todellakaan tulla kenellekään yllätyksenä.
-
Tein siis puhtaita refactoring-muutoksia.
Tuo refactoring juuri kuten kuvasit, olisi todella hienoa. Mutta tämän asian saa yleensä menemään totaalisen pieleen ne asiakkaat. Yleensä mielenkiintoa maksaa määrittelyistä, dokumentoinnista, testaukseta, ei tahdo löytyä.
Juuri siksi puhuinkin koulutuksesta - opiskelijoista, jotka eivät ole vielä kiinni noissa paineissa. Kun vanhaa koodia muokataan (onko sanalle refactoring kunnon suomennosta?), siinä nimenomaan oppii välttämään hölmöyksiä jotka pitää jälkeenpäin korjata. Oppii välttämään tyypillisimpiä ja harvinaisempiakin hölmöilyjä. Varsinkin niitä jotka tehdään jonkin hienon menetelmän nimissä. Omassa hommassani löysin aika paljon erilaisia historiallisia kerrostumia koodista, ja siinä todella oppi asioita joita ei voi oppia kirjoista lukemalla tai luentoja kuuntelemalla.
Mutta jotta homma toimisi koulutuksessa, tarvitaan opettajia jotka osaavat suunnitella refactoring-projektin oikein. Jokaisella refactoring-urakalla pitää olla selvä tavoite. Jos esimerkiksi haetaan vikaa, motivaatio refactoring-muutoksien tekemiseen loppuu heti kun vika on löydetty. Tiedän sen omasta kokemuksesta. Urakan pitää myös olla oikein mitoitettu. Jne jne jne. Uuden koulutusajattelun opettelussa on iso työ, mutta sillä olisi hyvin suuri tuottovaikutus pidemmällä tähtäimellä. Olisi yritysten etu vaatia sitä oppilaitoksilta. Mutta kuinkahan moni yritysjohtaja ymmärtää softatuotantoa sillä tasolla...
-
(onko sanalle refactoring kunnon suomennosta?)
Lähdin etsimään suomennosta ja löysinkin suomenkielistä keskustelua siitä miten refactoring ymmärretään väärin, siis että johtajien mielestä on ajanhaaskausta tehdä pelkkää refactoring-hommaa. Vitsi onkin siinä että pelkkä paljas refactoring on tuottavaa vain silloin kun hommaan pannaan kokematon jannu oppimaan. Mutta opetuksen tavoite olisikin se, että työelämässä, tai yhtä hyvin open source-projektissa, koodia tehdään sitten tehokkaasti. Tehokkaalla tarkoitan että ihan normaalissa koodauksessa aina jokainen versionhallintaan menevä muutos on joko puhdas refactoring-muutos (testataan regressiotestillä) tai puhdas toiminnallinen muutos (testataan uudella testitapauksella), ja käytännössä niitä refactoring-muutoksia tehdään pitkä sarja ennen kuin ollaan valmiita muutamaan uuteen toiminnalliseen muutokseen. Siis jos tehdään ihan täysin kurinalaisesti.
Open source -projekteista löytyy ihan varmasti hyvää materiaalia refactoring-koodauksen opetteluun.
-
Mites olisi suomennos refactoring - jälkituotteistaminen?
-
Mites olisi suomennos refactoring - jälkituotteistaminen?
Ei hyvä, tuolla kun ei ole tuotteistamisen kanssa mitään tekemistä.
-
Mites olisi suomennos refactoring - jälkituotteistaminen?
Ei hyvä, tuolla kun ei ole tuotteistamisen kanssa mitään tekemistä.
Joo, ei todellakaan mitään. Eikä oikeastaan edes olio-ohjelmoinnin kanssa, vaikka Martin Fowler käyttääkin Java-esimerkkejä kirjassaan Refactoring. Oliokielellä se on ehkä helpompaa, mutta kyllä vaikkapa muuttujia voi nimetä uudelleen ihan missä tahansa kielessä.
Koodinhuolto on hieman lähempänä, mutta huolto kuulostaa siltä että sitä tehdään erillään koodauksesta.