Puh: 040-123 45 67
Bash-skriptit ovat vielä yleinen tapa rakentaa tai ylläpitää yksinkertaisia, tai joskus vähän monimutkaisempiakin automaation palasia. Bash-, tai yleisemmin Shell-skriptit ovat ohjelmanpätkiä, jotka suoritetaan hyvin samantapaisesti kuin käyttäjä joka tekisi samat asiat täysin käsin. Shell-skriptien piirteitä ovat niiden helppo aloittaminen, huomaamaton laajentaminen ja siten monimutkaiseksi kasvaneen skriptin ylläpidon vaikeus.
Python soveltuu kielenä korvaamaan hyvin jo olemassa olevat Shell-skriptit. Python on kypsä sovelluskehitysympäristö, jolle löytyy paljon erilaisia kirjastoja ja käytäntöjä eri tehtävien tekemiseksi. Python soveltuu hyvin myös Shell-skriptien korvaamiseen, koska sekä tekstimuotoisen syötteen parsinta ja käsittely että tiedostojen käsittely ovat hyvin tuetut. Shell-skriptien uudelleenkirjoitus Python-sovelluksiksi kannattaa tyypillisesti tehdä silloin, kun itse skriptin automatiikkaan kohdistuu muutospaineita tai kyseessä olevan skriptin ylläpito on muuttumassa aikaavieväksi ja virheille herkäksi.
Kuinka sitten vaihtaa Shell-skriptistä Pythoniin?
Jos skripti on lyhyt ja yksinkertainen, eikä se ole kriittisessä tuotantoroolissa, ohjelman voi kirjoittaa suoraan Pythonilla ilman sen kummempia seremonioita. Skriptin testaaminen käsin ei vie liikaa aikaa, eikä mahdollisten virheiden kustannus ole suuri.
Kun skriptin kompleksisuus kasvaa, tai sitä käytetään tärkeässä tuotantoroolissa ja mahdollisten virheiden kustannus kasvaa, voi testaamisestakin muodostua vaikeaa, jos kunnollista testiympäristöä ei ole. Tällöin yksi hyvä vaihtoehto on kirjoittaa Shell-skriptille testit, joiden avulla ensin todennetaan skriptin toiminta. Tästä on hyötyä, vaikka uudelleenkirjoitusta Pythonilla ei tehtäisi. Testit suunnitellaan kattamaan kaikki tärkeät toiminnallisuudet, syötteet ja yleiset vikatilanteet.
Tähän työvaiheeseen Shell-skriptien yksikkötestauksen ohjelmointikehys Shunit2 on hyvä ratkaisu. Tällä kehyksellä laaditaan yksikkötestit riittävässä laajuudessa. Tämä vaihe voi edellyttää vähäistä alkuperäisen skriptin modularisointia, sillä pieniä palasia on helpompi testata kuin suuria.
Kun testit on kirjoitettu ja ne menevät läpi, voidaan samat testit kirjoittaa Pythonilla, yksikkötestikehyksellä. Testien uudelleenkirjoituksen jälkeen, ennen itse sovelluskoodin uudelleenkirjoittamista, kaikki testit odotetusti epäonnistuvat. Tässä vaiheessahan itse skriptiä ei ole vielä kirjoitettu. Tällä varmistetaan, että uudet testit toimivat ja testaavat edes jotain.
Kun testit ovat käännetty Pythonille, kirjoitetaan itse sovelluskoodi. Sovelluskoodin edistymistä on helppo seurata testien onnistumisesta. Tähän sovelletaan siis TDD eli Test Driven Development -kehitystapaa. Uuden, hyvin testatun Python-sovelluksen läpäistessä kaikki testit, on aika ottaa se käyttöön.
Käyttöönotossa on mahdollista vielä tuotantotestata Python-sovellusta asentamalla se suorittamaan sama tehtävä kuin alkuperäinen. Python-sovellus muokataan kirjoittamaan lokiin tai konsolille tekemänsä toimenpiteet, ympäristöä muokkaavat kutsut estetään. Tällöin saadaan varmistettua sekä uuden että vanhan toteutuksen toimivan yhtäläisesti. Shell-skripti tekee siis muutokset ja Python-sovellus kirjoittaa konsoliin mitä se aikoo tehdä. Tällöin voidaan varmistaa vielä käsin tarkastelemalla että sovellukset toimivat kuten pitääkin. Testauksen valmistuttua Python-sovellus voidaan ottaa käyttöön ja Shell-skriptistä luopua.
Uusi Python-sovellus on rakennettu suoraan testattavaksi. Muutosten tekeminen sovellukseen on helpompaa kun testien avulla voidaan tarkistaa ettemme ole vahingossa rikkoneet olemassa olevaa toiminnallisuutta. Nykyaikaisilla menetelmillä toteutetut sovellukset varmistavat sovelluksen luotettavan toiminnan myös siihen kohdistuvien vaatimusten ja tarpeiden muuttuessa.
Sovelluskehityksen muuttuessa testien avulla helpommin ennakoitavammaksi, ohjelmistokehityksen tuottavuus kasvaa antaen enemmän aikaa prosessikehitykselle ja sitä kautta todelliselle arvonmuodostukselle!