Kuinka virheenkorjaus voi tehdä sinusta paremman kehittäjän.

Jokaisen suuren ohjelman sisällä on pieni ohjelma, joka yrittää päästä ulos.

Kuvalainat: unsplash.com Jeshoots

Jos yhdistäisin ohjelmointiurani kahteen kovaan totuuteen, ne ovat seuraavat.

· Kaikki, mikä voi mennä pieleen, menee pieleen.

· Koodi haisee.

Ja ainoa taito, jota vaaditaan vastaamaan näihin katkeraan todellisuuteen, on virheenkorjaus.

Kyllä, virheenkorjaus. Kukaan (tai melkein kukaan!) Ei aloita ohjelmointia rakkaudella virheenkorjaukseen. Sen sijaan se on usein turhautumisen ja pelon lähde. "Kuinka monta tuntia tulen tuhlaamaan tämän virheen korjaaminen?", Monet meistä ihmettelevät. Palaamme mieluummin takaisin rakentamaan hienoja juttuja. (Koska kuka ei halua rakentaa hienoja juttuja!?)

Silti on vaikea löytää ihailtuamme kehittäjää, joka ei pidä virheenkorjausta tärkeänä. Tämä johtuu siitä, että he tietävät, että se on heille korvaamaton kasvun lähde. On muutamia tilanteita, jotka testaavat kykysi kehittäjäksi siinä määrin kuin virheenkorjaus tulee.

Ja todellinen ongelma vianetsinnässä on, että sitä ei voida käyttää aikataulussa. Voit aikatauluttaa melkein minkä tahansa ohjelmoinnin toiminnan suunnittelusta kehitykseen. Mutta virheenkorjaus on erilainen kala. Kun virheenkorjausistunto on tunti, päivä, tai jopa viikko, voi tulla ja mennä etkä löydä sinua lähempänä ongelman löytämistä ja korjaamista.

Siksi sinun pitäisi alkaa lähestyä virheenkorjausta oppimismahdollisuutena. Varmasti, että kipu on edelleen olemassa, mutta pidät sen kurissa, kun teet sen oikein.

Ja tässä on joitain tapoja, joilla voit olla parempi vianetsinnässä.

Ymmärrä ensin järjestelmä

Teemme usein virheen ”ymmärtää ensin ongelma” ja sitten ”ymmärtää järjestelmä”. Sen pitäisi olla päinvastoin.

Jonkin aikaa sitten virheenkorjain asiaa SAP-älykäs muodossa. Jotkut arvot eivät tulleet kunnolla lomakkeeseen, virheenkorjain koko lomaketta kahden päivän ajan eikä en löytänyt ongelmaa. Tarpeetonta sanoa, olin turhautunut. Kummitussa muodossa ei ollut mitään vikaa. Sitten inspiraatio iski minua.

Huomasin, että muotoa kutsutaan samanaikaisesti pääkoodin kahdesta kohdasta. Lisäanalyysien perusteella huomasin, että ongelma oli kutsukoodissa eikä muodossa. Ratkaisin asian selvästi. Kahden päivän ponnisteluni vaati vain erittäin pienen säätämisen eri paikassa.

Mitä tein täällä väärin?

En voinut korjata ongelmaa, ellei ymmärrä kuinka järjestelmä toimi. Heti kun ymmärsin sen, ongelma oli ilmeinen.

Muista aina, että tarvitset toimivia tietoja siitä, mitä järjestelmän on tarkoitus tehdä, miten se on suunniteltu ja joissain tapauksissa miksi se on suunniteltu tällä tavalla. Jos et ymmärrä jotakin järjestelmän osaa, ongelma näyttää aina olevan siellä.

Hyökkäysongelmat eristyksessä

Olen oppinut tämän tärkeän viisauden paimen kovalla tavalla.

Jonkin aikaa sitten työskentelin suuressa SAP-tiedonsiirtohankkeessa. Aikataulut olivat kriittisiä ja liian monta koodilohkoa tapahtui samanaikaisesti. Ja tässä ratkaisevassa vaiheessa törmäsin tietovaurio-ongelmaan.

Jotkut siirretyistä asiakastiedoista olivat turmeltuneita, ja oli hankala tehtävä selvittää, mikä meni pieleen miljoonissa siirretyissä tietueissa. Tiesin ongelman, mutta pääaihe oli se, missä ongelma oli olemassa.

Lopuksi ratkaisin prototyyppien ongelman. Loin pienen prototyypin, joka näytti samanlaisia ​​oireita osajoukolla tietoja. Tämän prototyypin kanssa työskenteleminen sai minut perimmäiseen syyhään ja lopulta asia suljettiin.

Tässä on kavennettava hakua.

Suuret järjestelmät ovat monimutkaisia, ja niiden toteuttamiseen liittyy monia tekijöitä. Kun työskentelet koko järjestelmän kanssa, on vaikea erottaa yksityiskohdat, joilla on vaikutusta ongelmaasi, sellaisista, joilla ei ole.

Ratkaisu on jakaa ja valloittaa. Älä yritä työskennellä koko järjestelmän kanssa kerralla. Erota komponentti tai moduuli, jolla sinulla on ongelmia muun koodin kanssa, vakavaa vianetsintää varten.

Ongelman eristämisellä on monia etuja. Pystyt keskittymään suoraan ongelmaan liittyviin kysymyksiin. Pääset ongelmaan nopeasti, koska työskentelet minimillä koodilla.

Muista aina, että virheen on vaikea piiloutua, kun sen piilopaikka leikataan puoleen.

Vaihda yksi asia kerrallaan

Yhdessä vuorauksessa; Käytä kivääriä, älä haulikkoa.

Anna minun selittää.

Kuvittele, että sinun on poistettava hammas ja käy hammaslääkärissä. Hammaslääkäri ”yrittää” löytää asian ja alkaa kutistaa kaikilla hampaillasi. Huokaat turhaan, koska yksi kerrallaan hammasi kantavat iskunsa iskua.

Kuinka sinä tunnet? Mitä helvettiä tapahtuu. Tietääkö kaveri työnsä? ”

Virheellinen virheenkorjaus toimii täsmälleen samalla tavalla.

Vaihda yksi asia kerrallaan. Hanki itsellesi hyvä kivääri. Voit korjata virheitä paljon paremmin. Tunnen kehittäjiä, jotka yrittävät korjata huonon koodin vaihtamalla tai kitkaamalla muita komponentteja. He voivat muuttaa kolme tai neljä asiaa ja huomata, hei, se toimii nyt. Se on tavallaan hienoa, paitsi että heillä ei ole aavistustakaan siitä, mikä osa oli huono. Mikä pahempaa, kaikki tämä hakkerointi voi rikkoa aluksi muita asioita, jotka olivat hienoja.

Monissa tapauksissa haluat muuttaa järjestelmän eri osia nähdäksesi, vaikuttavatko ne ongelmaan. Tämän pitäisi yleensä olla varoitus siitä, että arvaat, sen sijaan että tiedät koodin riittävän hyvin nähdäksesi mitä tapahtuu. Muutat olosuhteita sen sijaan, että etsit epäonnistumista sellaisena kuin se tapahtuu luonnollisesti.

Tämä voi piilottaa ensimmäisen ongelman ja aiheuttaa enemmän. Tämä on harha-ansa, jota kehittäjien on vältettävä.

Muista aina, että voit aina kertoa tarkalleen, mikä parametri vaikutti, jos teet yhden muutoksen kerrallaan. Ja jos muutoksella ei näytä olevan vaikutusta, tee se heti pois!

Tarkista, onko sen todella korjannut.

Virheenkorjauksen kultainen sääntö on, että jos et korjannut sitä, se ei ole korjattu.

Kaikki haluavat uskoa, että vika vain katosi. ”Emme näytä saavan saamaan sitä epäonnistumaan enää.” “Se tapahtui niin pari kertaa, mutta gee, sitten jotain tapahtui ja se lakkasi epäonnistumasta.” Ja tietysti, looginen johtopäätös on: “Ehkä se ei toistu. ." Arvaa mitä? Se tulee.

Anteeksi pettymys, mutta todellisessa maailmassa ei ole maagisia keijuja.

Kun epäilet, että olet korjannut virheen, korjaa se. Varmista, että se on rikki uudelleen. Laita korjaus takaisin paikalleen. Varmista, että se on jälleen kiinnitetty. Ennen kuin olet pyöräillyt kiinteästä rikki ja takaisin kiinteään uudelleen, muuttamalla vain tarkoitettua korjausta, et ole todistanut korjaavasi.

Korjaukset käyttäytyvät yleensä hauskasti useammin. Joskus he vain "piiloutuvat" sen sijaan, että tosiasiallisesti korjaisivat asian. Ja siihen aikaan kun ymmärrämme, että korjauksella ei ole mitään tekemistä ongelman ratkaisemisen kanssa, tuote olisi toimitettu asiakkaalle, joka ei selvästikään ole tyytyväinen. Älä pudota ansaan.

Muista aina, että jos järjestelmä epäonnistuu tavanomaisesti, kun poistat vain korjauksen, voit vain olla varma, että korjaus todella toimii.

Ja viimeiseksi, pidä ratkaisuloki

Tämä saattaa kuulostaa triviaalia. Mutta se on erittäin tärkeä ongelmanratkaisutyökalu, joka jätetään usein huomiotta. Ongelmia esiintyy ja toistuu elämässä, työssä ja jopa suhteissa monivuotisesti. Ja ei ole järkeä keksiä pyörää uudestaan ​​ja uudestaan.

Sen suhteen, minkä tyyppisiä tietoja ratkaisulokkeissa todella ylläpidetään, on vaikea ennustaa, koska yrityksille asetettavat vaatimukset eroavat toisistaan. Yleisesti ottaen seuraavia seikkoja voidaan kuitenkin harkita.

· Ongelma #

· Aloittaja (joka kirjasi puhelun)

· Aloittajan laajennus tai puhelinnumero

· Päivämäärä / aika avattu

· Yhteenvetokuvaus

· Vaikutus / merkitys

· Tyyppi (vika)

· Omistaja (järjestelmän)

· Nykyinen tila (avoin, käynnissä, suljettu)

· Seuraava askel

· Seuraavan vaiheen päivämäärä

· Valmistumispäivämäärä

· Ratkaisu, kehityspyyntö # tai linkki toimittajan tukipyyntöön

Älä polta kahdesti. Ole tuottavampi pitämällä loki edessä olevista ongelmista ja löydetyistä ratkaisuista. Kun ongelma ilmenee sen sijaan, että sanot “Hei, olen nähnyt tämän aiemmin. Mutta minulla ei ole aavistustakaan kuinka korjaan sen. ”, Voit nopeasti etsiä aiemmin käyttämäsi ratkaisun. Sanomattakin on selvää, että se ei vain säästää aikaa, vaan nostaa itsetuntoa ja luottamusta käsittämättömälle tasolle.

Muista, että virheenkorjaus on oppimismahdollisuus. Toki, joskus huomaat, että olet tehnyt typerän virheen, jota sinun ei olisi ensin pitänyt tehdä. Mutta se on yhtä paljon osa kehittymistä paremmaksi kuin uuden hienon uuden kielen ominaisuuden oppiminen.

Kuten Richard Pattis on perustellusti todennut.

”Kun virheenkorjausta tapahtuu, aloittelijat lisäävät korjaavan koodin; asiantuntijat poistavat viallisen koodin. ”
Kirjailijasta-:
Ravi Rajan on globaali IT-ohjelmien johtaja, joka sijaitsee Mumbaista, Intiasta. Hän on myös innokas bloggaaja, Haiku-runokirjoittaja, arkeologian harrastaja ja historiamiaksi. Ota yhteys Raviin LinkedInissä, Mediumissa ja Twitterissä.

Tämä tarina on julkaistu Mediumin suurimmassa yrittäjyysjulkaisussa The Startup, jota seuraavat +418 678 ihmistä.

Tilaa saadaksesi parhaita tarinoitamme täältä.