Kysyisin ihan yleisellä tasolla ohjelmistojen suunnittelusta.

Ensinäkin, millä tavalla te yleensä lähdette hahmottelemaan, jotain isompaa kokonaisuutta? Hajotatteko sen osiin, käytättekö pseudokoodia tai vuokaavioita? Vai millä tavalla? Ja jos ohjelma toteutetaan funktiokirjastojen avulla, niin minkälaisia kokonaisuuksia jaette yleensä funktioiksi?

Tälläisiä ihan perusjuttuja olen miettinyt, kun eteen on tullut php:llä toteuttettavaksi erilaisia projekteja...

Suosin henkilö kohtaisesti hajottamista mutta peruspuuhat pseudokoodista tai vuokakaaviota.

Itse suosin perinteistä lähestymistapaa, jossa kirjoitetaan ensimmäisenä vaatimusmäärittely. Se kertoo mitä sovelluksen tulee tehdä ja mitä se ei saa tehdä. Sitten arkkitehtuurimäärittely, jossa kerrotaan yleisesti mitä sovellus tulee tekemään. Huomaa mitä, ei miten. Se miten sovellus tulee täyttämään vaatimusmäärittelyn kerrotaan n+1 kappaleessa funktionaalisia määrittelyjä. Näiden lisäksi tehdään testisuunnitelmat ja -tapaukset, sekä mahdolliset muut speksit kuten käyttöliittymäkuvaukset.

Pseudokoodia en ole koskaan liittänyt dokumentteihin. Erilaisia kaavioita toki, mutta mielestäni kaaviossa esitetty asia pitää selittää myös sanallisesti.

N+1 kpl funktionaalisia määrittelyjä voisi olla juuri tuota hajottamista. Eli mietitään loogisia kokonaisuuksia tai jos järjestelmä on hyvin pieni, voidaan kaikki kirjoittaa yhteen dokumenttiinkin. Näissä dokumenteissa en ota vielä kantaa juurikaan itse koodaukseen, vaan ehkä lähinnä algoritmitasolla. Koodihan tulee luonnollisesti kommentoida ;)

Mutta back to the reality. Oikeasti projektini ovat suunniteltu postit-lapuille, niitä ei ole juurikaan dokumentoitu ja koodikin on niin suoraviivaista, että mitä sitä suotta kommentoimaan...

Riippuu tietysti projektista, mutta "toiminnallinen määrittely" on kaiken perusta. Sen myötä on useimmiten myös syntynyt tietovarastomalli ja tarvittavat rajoitukset. Tämä määrittää aika tehokkaasti mitä tehdään tietokoneen kannalta (usein tästä saa melko suoraan oliot ja niiden väliset suhteet). "Tekninen" määrittely (ohjelmistoarkkitehtuuri) on sen jälkeen ja useimmiten sen tekee joku systeemisuunnittelija (toki riippuu projektista ja työnantajasta). Tekninen määrittely ei kuitenkaan ole mikään välttämättömyys ja koskee enemmän isoja projekteja. Microsoftin Dynamic Data (joka on rampa ja aiheuttaa helvetisti ongelmia (oma mielipide)) ja ilmeisesti apinoinnin kohteena ollut Ruby on Rails (en oo käyttänyt) tarjoavat perus CRUDiin mahdollisuuden pelkän tietokannan perusteella.

Miusta on hyvä osittaa ohjelma ja tehdä se paloissa. Aina toki on pidettävä kokonaisuus mielessä. Osittamalla toteutuksen pääsee näkemään kättensä jäljen kun saa jotain aikaan, eikä motivaation puute iske. Pseudokoodilla/vuokaavioilla ei hirveesti oo miun mielestä väliä, kunhan toiminto palauttaa määrittelyn mukaisen vasteen (jokainen taaplaa tavallaan, ellei suorituskyky tule vastaan).

Funktiokirjastoina toteutettaessa kannattaa asiat ryhmitellä toiminto/taulu kerrallaan. Esimerkiksi käyttäjän käsittelyyn liittyvät asiat yhteen tiedostoon jne. Tästä ei kuitenkaan ole hirveän pitkä harppaus olio-ohjelmointiin, joten kannattaa vaikka sivutoimisesti opetella sitä muiden maksullisten hommien ohessa.

Niin se unohtui vielä mainita, että pitää muistaa, että dokumentit eivät ole vain koodajalle itselleen. Niiden tarkoitus on dokumentoida järjestelmä/sovellus siinä määrin, että jos sinä kajautat pääsi betoniin ja menetät muistisi, ei seuraavan ohjelmoijan tarvitse käyttää kuukausia sen arvuutteluun mitä järjestelmän pitäisi tosiasiassa tehdä. Joskus myös koodin ylläpitäjä on eri kuin koodin alkuperäinen kirjoittaja, jolloin dokumentaatio on elintärkeää tai ainakin ylläpitäjälle tulee suunnaton *itutus jos niitä ei ole.

Kaikista hankalinta dokumentoinnissa on muuten niiden pitäminen ajantasalla kun järjestelmään tulee muutoksia. Olenkin jo 5 vuotta yrittänyt kirjoittaa tätä varten työkalua, mutta en ole vielä saanut edes Main-funktiota aikaiseksi :)

Muistan jonkun joskus sanoneen "kommentit voivat johtaa harhaan, mutta koodi itsessään ei koskaan!" ;)

Kommenteista vielä, että nekin onnistutaan turhankin usein pilaamaan kommentoimalla rivit tyyliin:
// Pallojen määrä
$balls->count = 100;

Ja sitten toisaalla on smirgelin monimutkainen preg_replace tjms. mitä ei ole kommentoitu halaistulla sanallakaan, tai korkeintaan tyyliin "Muuttaa syötteen validiksi".

Minä olen ottanut periaatteen, että kommentoin ainakin julkiset metodit, propertyt ja fieldit sekä itse luokat jotenkin tähän tyyliin.


C#


Sekä tietysti näiden lisäksi kommentit sellaisiin paikkoihin joissa tehdään jotain mikä ei ensi silmäyksellä koodista erotu.

Ja kyllä minä saan koodinkin johtamaan harhaan harrastamalla esimerkiksi hieman reflectointia ja uudessa C#:ssa/.NET:ssä dynamicsin käyttöä ;)

Sekava mutta täyttä asiaa http://www.agilemodeling.com/

Muistatko päivittää kaikki kommentit aina kun muutat sitten julkista metodia vai kirjoitatko kommentit niin ympäripyöreästi, etteivät ne oikeastaan kerro mitä metodi oikeasti tekee. :)

Kuulun siis tuohon "kommentit on turhia hyvässä koodissa" -koulukuntaan, kommentoin koodini luokkien, metodien ym. nimiin. Esimerkiksi annan nyt pikkuprojektistani koodinpätkän jonka tein tässä juuri, kielenä Java ja avainsanana reflection, osaatko arvata mitä tapahtuu?

Java


Kyseisessä luokassa ei ole riviäkään kommenttia, ainoastaan yhdessä paikassa allekirjoittaneen nimi.

Oisko tuossakin tapauksessa kannattanut extractata metodi joka olisi jo nimellään kertonut mitä tuossa tehdään? :) PopulateNullStringPropertiesWithEmptyString() ?

Tottakai nämä kyseiset kommentit kirjoitetaan niin, että niistä selviää mitä se tekee. Pilkuntarkasti en ala siinä sepustamaan asiaa, sillä eihän se kutsujalle tosiasiassa edes kuulu mitä rajapinnan takana tapahtuu (esimerkistäni muuten puuttuu se rajapinta interface kokonaan). Rajapinnan muuttaminen on taas niin iso operaatio, että kommentin korjaaminen on pienin ongelmista. Ongelmallisempaa on se, että saadaan n+1 kutsujaa noudattamaan uutta rajapintaa ilman, että ~95000 tilausriviä per pv katoaa jonnekin :D



Eli et välitä rajapintojen stabiliteetistä tuon taivaallista, vaan vaihdat aina luokan/metodin nimeä ja annat kutsujan pähkäillä, että mitähän helvettiä tapahtui, kun mikään ei enää toimi? Kuulostaa ihan TietoTunatorilta ;)

Tarkoitus on itse asiassa lisätä Hamcrest Matcherit tuohon seuraavaksi, mutta pointtini tuli selväksi: Hyvin suunnitellulla API:lla on itsestäänselvää mitä itse vinkula tekee.

Interfaceja en siis muuta kauhean innokkaasti, mutta suunnittelenkin ne mahdollisimman yksiselitteiseksi. Tai "suunnittelen" on ehkä vähän väärä, TDD:ssä ne kehittyvät siinä sivussa ja lopulta saavuttavat stabiilin muodon. Esmes tuossa ylempänä tuo .of() lienee huono nimi, mutten ole vielä keksinyt mitään muutakaan nimeä ko. factory methodille, joka kuvastaisi luodun olion suhdetta parametrina annettuun olioon.

Lisämuoks: Mitä rajapintojen stabiiliuteen tulee, sisäiset rajapinnat saavat elää niin paljon kuin vain kykenevät parhaan lopputuloksen saavuttamiseen. Ulos annettujen rajapintojen on toki puolestaan oltava ainakin major -versioitten välillä stabiileja enkä sellaisia tietenkään menisi muuttelemaan (elääpä eräs tekemäni rajapinta verkossa vieläkin, jossa on parametri "recursive" no-oppina... :) ), mutta noin yleisesti ottaen metodieni nimet muuttuvat sitä tahtia kun huomaan, että niiden muuttamisessa on jotain järkeä.

No minkälaisia ominaisuuksia eri frameworkit tarjoaa, jos nyt otetaan esimerkiksi CakePHP? Eli mitä hyötyä niistä on?

Kai nyt hokaat että frameworkkeja on aika valtavasti erilaisia, erilaisine hyötyineen.

Yleensäottaen framework helpottaa softan tekemistä konsistentilla tavalla ja niin, että usein toistuvia asioita voi tehdä pienemmällä vaivalla. Kehittämisen nopeutuminen ja ylläpidettävyys ois kans tavoitteina. Suomeksi puhutaan sovelluskehyksestä tai ohjelmistokehyksestä.