Tick-the-Code - julkaisut
Happy Are The Software Engineers.. (artikkeli)
Ensimmäinen koskaan kirjoittamani julkaisu on nimeltään "Happy Are The Software Engineers.." ("Onnellisia ovat ohjelmistosuunnittelijat..") ja se ilmestyi Better Software-lehdessä joulukuussa 2006. Artikkeli kuvaa kaikessa lyhykäisyydessään, kuinka täydellinen keskittyminen voi luoda onnellisuuden tunteen, erityisesti jos tehtävä on mielekäs. Halusin osoittaa, että ohjelmistolaatutyö on mielekästä ja että Tick-the-Code -menetelmällä on mahdollista uppoutua täydelliseen keskittymisen tilaan.
Tiivistettynä: onnea on Tick-the-Code.
Tick-the-Code Inspection: Theory and Practice
Ensimmäinen tieteellinen artikkelini on nimeltään "Tick-the-Code Inspection: Theory and Practice" (Tick-the-Code -katselmointi: teoria ja käytäntö) ja se ilmestyi vertaistarkistetussa ASQ (American Society for Quality, Amerikan Laatuliitto) lehdessä nimeltä Software Quality Professional.
Kuten nimi kertoo, artikkelini paljastaa kaikki Tick-the-Code -menetelmän yksityiskohdat aina 24 koodaussääntöön asti. Artikkeli on kattavin kirjoitettu lähde Tick-the-Code -menetelmästä.
Tick-the-Code Inspection: Empirical Evidence (on Effectiveness)
Toinen tieteellinen artikkeli on nimeltään Tick-the-Code Inspection: Empirical Evidence (on Effectiveness) (Tick-the-Code -katselmointi: empiirisiä todisteita (tehokkuudesta)). Kirjoitettuani artikkelin esitin sen ensimmäisen kerran Pacific Northwest Software Quality Conference (PNSQC)-konferenssissa lokakuussa 2007, Portlandissa, Oregonin osavaltiossa, USA:ssa. Artikkeli esittelee Tick-the-Code-koulutuksista kerättyjä mittauksia (noin 50 koulutuksen yhteensä yli 300 osallistujaa osallistuivat tutkimukseen.) Tulokset ovat paljastavia. Artikkelin päähuomio on, että ohjelmistosuunnittelijat voisivat pitää koodinsa paljon yksinkertaisempana ja välttää tekemästä monia niistä virheistä, joista ohjelmistoprojektit ovat tulleet niin pahamaineisiksi.
Artikkelin lisäosassa on lista Tick-the-Code -menetelmän säännöistä artikkelin kirjoitushetkellä (kesä 2007).
Tick-the-Code - uusvanha tekniikka taistelussa bugeja vastaan
Pirkanmaan Tietojenkäsittely-yhdistys (Pitky ry) julkaisi artikkelini jäsenlehdessään Pitkyn Piiri 1/2008. Se on nimeltään "Tick-the-Code - uusvanha tekniikka taistelussa bugeja vastaan".
Tulossa
Tick-the-Code -katselmointi: kirja
Vuodesta 2006 olen kirjoittanut kirjaa Tick-the-Code -menetelmästä. Siitä tulee yksityiskohtaisin ja täydellisin lähde menetelmään. Olen jo luonnostellut lähes kaikki luvut. Joihinkin niistä olen jo saanut asiantuntijoilta palautetta, jonka olen ottanut huomioon. Olen lähestynyt muutamaa kustantajaa ja saanut lisää palautetta (en vielä hyväksyntää). O'Reilly-toimittaja Andy Oram mainitsi menetelmän Beautiful Code-kirjan blogissa, mikä aiheutti melkoisen ryntäyksen näillekin sivuille. Seuraavaksi täytyy saada syntymään asiasta kiinnostunut yhteisö ja lähestyä kustantajia uudestaan.
Ote kirjasta
Ote vaihtuu viikottain. Kukin ote on vielä luonnos ja voi muuttua ennen päätymistään kirjaan. Otteet ovat englanniksi.
If you are overly cautious as checker, you produce far too many findings for your and the author's own good. You seem allergic to defects. No matter how negligible, if there is a flaw in the code, you mark it. No defect is too trivial for you. For example, typographical errors in comments, cosmetic flaws in the placement of comment boxes, and differences in preferred style will all be marked. You concentrate fully on the Plentiful Principle.
Just the sheer amount of findings dictates that most of the findings will be minor in effect, some of them insignificant or meaningless. When seeing an overwhelming number of findings, the author is discouraged, and once he realizes lack of relevance of the findings, he rejects possibly all of them. Although you honor the Plentiful Principle in trying to play it too safe, you end up breaching the Acceptance Agreement:
The more acceptable findings there are, the better.
The author 'accepts' a finding by fixing it. Sometimes you cannot call improving code 'fixing' it because the code isn't actually broken. In this sense, I prefer to use the word 'change' for whatever the author does to the accepted findings he gets. Sometimes 'changing' the code is very close to refactoring it. Refactoring means to improve the design of the code without changing its functionality. Strictly interpreted, the Acceptance Agreement says that any ignored finding is wasted effort. You shouldn't use it in isolation, though. Combined with the Plentiful Principle, the Acceptance Agreement helps you find the Utopia of code inspection. The Ideal In Inspections is
The more findings the author changes, the better.
Each changed finding is meant to improve the source code, so maximizing the number of changes produces the best value for the effort the checkers and the author spend in a code inspection. This is completely at odds to the thinking of many managers and software developers in denial: "Don't fix it if it ain't broken." I say, "Give quality a chance!"
Sometimes the participants of a code inspection process break it. A part of Chapter 2. "Symptoms" are things that can go wrong with code inspections. Too cautious checkers make it hard for others to take findings seriously, which undermines the whole inspection process.
Olet nyt tässä:
Klikkaamalla sivustokarttaan.
Osanottajien sanomaa:
Klikkaamalla kurssitietoihin.
