Ohjelmoijat käyttävät suuren osan ajasta virheenkorjauksesta koodin kirjoittamisen sijaan. Sinulla on todennäköisesti ollut jonkin verran koulutusta kielen tai kehyksen oppimiseen - mutta miten opit korjaamaan ohjelmiston viat?
Kun rakastuit ohjelmointiin (tai ainakin päätit, että se oli palkitseva ura), luulit luultavasti sitä luovaksi pyrkimykseksi. Suunnittelet hienon ohjelmiston, kirjoitat koodin ja Pöh!- se toimisi täydellisesti ensimmäistä kertaa.
Joo. Aivan.
Todellisessa maailmassa vietit joukon aikaa koodin virheenkorjaukseen sen sijaan, että kirjoitit uusia juttuja. Olen varma, että voisin kaivaa epäselvän prosenttiosuuden kehittäjien ajasta, joka on tarkoitettu vikojen korjaamiseen eikä uusien toimintojen luomiseen, mutta epäilen sinun täytyy kuulla numero. Voit liian helposti kuvata päivät, jotka vietit etsimällä Bug From Hell -tapahtumaa, ja sen vaikutuksen projektisi aikatauluun.
Nyt on monia tapoja, joilla ohjelmoijat voivat oppia ja oppivat uusia ohjelmistotaitoja, olivatpa ne sitten kirjan lukemista, teknikonferenssiin osallistumista tai JavaWorld.comin kaltaisten sivustojen vierailua. (Olen melko iloinen siitä, että teet jälkimmäisen.) Nämä keskittyvät kuitenkin yleensä työkaluihin, kuten kieliin tai kehyksiin, eivät metatekniikoihin, kuten "Kuinka löytää vika kahdessa tunnissa kahden päivän sijaan". Kieliä voi tulla ja tulla, samoin myös IDE-virheenkorjaajat, mutta kyky erottaa, minkä kiven alla vika piiloutuu, pysyy kanssasi ikuisesti.
Suuri osa virheenkorjauksen oppimisen taidoista on tietysti kokemusta. Se voi olla oma kokemuksesi tai mahdollisuus olla Heinäsirkka pääohjelmoijan jalkoilla. Epäilen myös, että joillakin ihmisillä on synnynnäinen kyky vianmääritykseen (yhtä tärkeä asia rikkoutuneen auton korjaamiseksi väärin käyttäytyvänä sovelluksena), ja ne meistä, joilla ei ole sitä, voivat vain kateuttaa.
Kuitenkin, jonkin verran tästä voidaan oppia. Esimerkiksi yhdellä tuttavani pääohjelmoijalla oli aksioma: Jos olet etsinyt vikaa (suhteellisen) pitkään etkä löydä sitä, hän sanoi: "Etsit väärästä paikasta." Selvästi kuulostava, mutta varmasti totta ... ja kuinka usein olet tuhlannut aikaa katsoessasi XYZ-moduulia, kun ongelma oli muualla kokonaan?
Kysyin useilta kehittäjiltä tapoja, joilla he oppivat tai parantivat virheenkorjaustaitojaan. Yllättävä määrä heistä puhui hallitsevansa IDE: n virheenkorjaajaa tai muuta työkaluosaamista, mutta suurin osa mitä halusin tietää, on heidän neuvonsa virheiden korjaamisen parantamiseksi. Tässä on lyhyt yhteenveto heidän vastauksistaan.
- Ole kurinalainen. Virheenkorjaus on prosessi, sanoi yksi kehittäjä, ei sarja satunnaisia tapahtumia. Älä säädä nuppeja satunnaisesti; seuraa koodin suoritusprosessia. Aivan kuten ruohonleikkurin kiinnittäminen, hän sanoi. Saako osa A tarvitsemansa panoksen? Entä tuotos? Jos se on OK, siirry eteenpäin.
- Paranna taitojasi virheenkorjauksella muiden ihmisten koodien sijaan. On helpompaa nähdä virheet toisen henkilön oletuksissa kuin nähdä omasi. Voit tehdä tämän osana vertaisarviointikoodin tarkistusta ja vertaisverkko virheenkorjausta. Kehität kykyä tunnistaa vikojen yleiset syyt nopeammin, lupaat yhden kehittäjän ja opetat tunnistamaan (ja hylkäämään) omat huonot kehityskäytänteesi.
- Teeskentele, että olet kääntäjä. Etsi ja korjaa niin monta virhettä kuin mahdollista, ennen kuin painat Käännä-painiketta. Vaikka useimmissa nykyaikaisissa IDE: issä on integroituja virheenkorjaajia (kuten Visual Studion Intellisense), opit vähemmän heidän automatisaatiostaan kuin prosessin tietoisesta tutkimisesta. (Samalla tavalla et koskaan opi oikeinkirjoitusta oikein luottaen oikeinkirjoituksen tarkistajaan kaiken työn tekemiseen.)
- Opi korjaamaan vikoja mahdollisimman varhaisessa kehitysprosessissa. Se voi tarkoittaa jotain virallista, kuten testilähtöistä kehitystä. Tämä tarkoittaa myös aikaa omistaa suunnittelun virheenkorjaus koodaamisen sijaan.
- Virheenkorjaus on helpointa, kun pystyt pitämään koko järjestelmää mielessäsi. Älä tee virhettä keskittymällä vain yhteen sovelluksen osaan. Kiinnitä huomiota moduulien keskinäisiin suhteisiin. Lue koodi useilla abstraktiotasoilla, neuvoi yksi ohjelmoija. "Virheen löytäminen on vaikeinta, ja se vaatii selkeän käsityksen siitä, mitä useita koodin osia tekee", hän sanoi.
- Osa samasta neuvosta on mielestäni jonkun toisen ehdotus: hanki hyvä käsitys järjestelmästä tasolle alaspäin siitä, mitä työskentelet. "Jos olet virheenkorjauksessa järjestelmätason C-ohjelmaa, se auttaa tuntemaan kokoonpanon ja jotain käyttöjärjestelmästä", selitti järjestelmäohjelmiston johtava insinööri. "Jos testaat J2EE-sovellusta, se auttaa tietämään jotain Java-ketjuista, RMI: stä ja GC: stä." Monissa tapauksissa hän huomautti, virheilmoitukset tulevat tuosta tasosta alaspäin. "Jos pystyt ymmärtämään, mitä se tarkoittaa, se auttaa sinua selvittämään, mikä abstraktiotasollasi menee pieleen", hän selitti.
Muutama kehittäjä suositteli myös ylimääräisiä resursseja. Heidän joukossaan on David Aganin kirja Debugging, joka lupaa yhdeksän välttämätöntä sääntöä, ja Why Programs Fail: A Guide to Systematic Debugging, joka on ilmestymässä toisessa painoksessa. Kehittäjä, joka suositteli jälkimmäistä, sanoo, että se opettaa järjestelmällistä lähestymistapaa virheenkorjaukseen runsaalla käytännön esimerkillä. Toinen ehdotti online-essee, Kymmenen taitoa erittäin tehokkaista ohjelmistojen testaajista.
Pidän kaikista vastauksista, mutta epäilen jakavan enemmän viisautta. Kuinka hankit virheenkorjaustaitosi? Kuinka olet auttanut muita parantamaan omaansa?
Tämän tarinan "Vianetsintätaitojen oppiminen ja parantaminen" julkaisi alun perin JavaWorld.
