Vuoden 2018 alusta lähtien olen työskennellyt johtajan/pomon/pääkehittäjän asemassa tiimissä - kutsukaa sitä miksi haluatte, mutta pointti on, että olen täysin vastuussa yhdestä moduulista ja kaikista työskentelevistä kehittäjistä. sen päällä. Tämä tehtävä antaa minulle uuden näkökulman kehitysprosessiin, kun olen mukana useammissa projekteissa ja aktiivisemmin päätöksenteossa. Äskettäin näiden kahden tilanteen ansiosta tajusin yhtäkkiä kuinka paljon ymmärryksen mitta vaikuttaa koodiin ja sovellukseen.
Haluan korostaa, että koodin (ja lopputuotteen) laatu liittyy läheisesti siihen, kuinka tietoisia koodia suunnittelevat ja kirjoittavat ihmiset ovat tekemissään.
Saatat ajatella juuri nyt: "Kiitos, Cap. Tietenkin olisi mukavaa ymmärtää, mitä kirjoitat yleisesti. Muuten voit yhtä hyvin palkata ryhmän apinoita lyömään mielivaltaisia näppäimiä ja jättää asian siihen." Ja olet täysin oikeassa. Näin ollen pidän itsestäänselvyytenä, että ymmärrät, että yleinen käsitys tekemisistäsi on välttämätöntä. Tätä voidaan kutsua ymmärtämisen nollatasoksi, emmekä analysoi sitä yksityiskohtaisesti. Katsomme yksityiskohtaisesti, mitä sinun on tarkalleen ymmärrettävä ja miten se vaikuttaa tekemiisi päätöksiin joka päivä. Jos olisin tiennyt nämä asiat etukäteen, se olisi säästänyt minulta paljon hukattua aikaa ja kyseenalaista koodia.
Vaikka alla ei näy yhtään koodiriviä, uskon silti, että kaikki täällä sanottu on erittäin tärkeää laadukkaan, ilmeikkään koodin kirjoittamisen kannalta.
Ensimmäinen ymmärryksen taso: Miksi se ei toimi?
Kehittäjät saavuttavat tämän tason yleensä hyvin varhain urallaan, joskus jopa ilman muiden apua - ainakin minun kokemukseni mukaan. Kuvittele, että sait virheraportin: jokin sovelluksen toiminto ei toimi, se on korjattava. Miten aiot jatkaa?
Vakiokaavio näyttää tältä:
- Etsi ongelman aiheuttava koodinpätkä (tämän tekeminen on erillinen aihe, käsittelen sen vanhaa koodia käsittelevässä kirjassani)
- Tee muutoksia tähän katkelmaan
- Varmista, että virhe on korjattu eikä regressiovirheitä ole tapahtunut
Keskitytään nyt toiseen kohtaan - muutosten tekemiseen koodiin. Tähän prosessiin on kaksi lähestymistapaa. Ensimmäinen on tutkia, mitä nykyisessä koodissa tarkalleen tapahtuu, tunnistaa virhe ja korjata se. Toiseksi: siirry tunteen mukaan - lisää esimerkiksi +1 ehdolliseen lauseeseen tai silmukkaan, katso toimiiko funktio halutussa skenaariossa, kokeile sitten jotain muuta ja niin edelleen loputtomiin.
Ensimmäinen lähestymistapa on oikea. Kuten Steve McConnell selittää kirjassaan Code Complete (jota muuten suosittelen lämpimästi), joka kerta kun muutamme jotain koodissa, meidän pitäisi pystyä ennustamaan luottavaisesti, kuinka se vaikuttaa sovellukseen. Lainaan muistista, mutta jos bugikorjaus ei toimi odotetulla tavalla, sinun tulee olla hyvin huolissasi ja kyseenalaistaa koko toimintasuunnitelmasi.
Yhteenvetona sanotuista, jotta voit suorittaa hyvän virheenkorjauksen, joka ei heikennä koodin laatua, sinun on ymmärrettävä sekä koodin koko rakenne että tietyn ongelman lähde.
Toinen ymmärryksen taso: Miksi se toimii?
Tämä taso ymmärretään paljon vähemmän intuitiivisesti kuin edellinen. Minä, ollessani vielä aloitteleva kehittäjä, opin sen pomoni ansiosta ja selitin myöhemmin toistuvasti asian olemuksen uusille tulokkaille.
Oletetaan tällä kertaa, että sait kaksi virheilmoitusta kerralla: ensimmäinen koskee skenaariota A, toinen skenaariota B. Molemmissa skenaarioissa tapahtuu jotain vikaa. Vastaavasti puutut ensin ensimmäiseen virheeseen. Tason XNUMX ymmärtämistä varten kehittämiemme periaatteiden avulla voit kaivaa syvälle ongelmaan liittyvään koodiin, selvittää, miksi se saa sovelluksen käyttäytymään kuten skenaariossa A, ja tehdä kohtuullisia säätöjä, jotka tuottavat haluamasi tuloksen. . Kaikki menee loistavasti.
Sitten siirryt skenaarioon B. Toistat skenaarion yrittääksesi aiheuttaa virheen, mutta - yllätys! – Nyt kaikki toimii niin kuin pitää. Vahvistaaksesi arvauksesi, kumoat muutokset, jotka olet tehnyt työskennellessäsi bugin A parissa, ja bugi B tulee takaisin. Bugikorjaus ratkaisi molemmat ongelmat. Onnekas!
Et laskenut tähän ollenkaan. Olet keksinyt tavan korjata virhe skenaariossa A, etkä tiedä, miksi se toimi skenaariossa B. Tässä vaiheessa on erittäin houkuttelevaa ajatella, että molemmat tehtävät on suoritettu onnistuneesti. Tämä on aivan loogista: tarkoitus oli poistaa virheet, eikö niin? Mutta työ ei ole vielä valmis: sinun on vielä selvitettävä, miksi toimintasi korjasi virheen skenaariossa B. Miksi? Koska se saattaa toimia väärillä periaatteilla, ja sitten sinun on etsittävä toinen ulospääsy. Tässä on pari esimerkkiä tällaisista tapauksista:
- Koska ratkaisua ei räätälöity virheeseen B, kaikki tekijät huomioon ottaen olet saattanut tietämättäsi rikkoa toiminnon C.
- On mahdollista, että jossain piilee myös kolmas samaan toimintoon liittyvä bugi, josta vikakorjaus riippuu järjestelmän oikeasta toiminnasta skenaariossa B. Kaikki näyttää nyt hyvältä, mutta jonain päivänä tämä kolmas bugi huomataan ja korjataan. Sitten skenaariossa B virhe toistuu, ja se on hyvä, jos vain siellä.
Kaikki tämä lisää kaaosta koodiin ja putoaa jonakin päivänä päähäsi - todennäköisesti kaikkein sopimattomimmalla hetkellä. Sinun on kerättävä tahdonvoimaasi pakottaaksesi itsesi käyttämään aikaa ymmärtääksesi, miksi kaikki näyttää toimivan, mutta se on sen arvoista.
Kolmas ymmärrystaso: Miksi se toimii?
Viimeaikainen näkemykseni liittyy juuri tähän tasoon, ja se on luultavasti se, joka olisi tuonut minulle eniten hyötyä, jos olisin tullut tähän ajatukseen aikaisemmin.
Selvyyden vuoksi katsotaanpa esimerkkiä: moduulistasi on tehtävä yhteensopiva funktion X kanssa. Et ole erityisen perehtynyt toimintoon X, mutta sinulle kerrottiin, että sen kanssa yhteensopivuus edellyttää F-kehystä. X:ään integroidut moduulit toimivat täsmälleen hänen kanssaan.
Koodisi ei ole ollut lainkaan yhteydessä F-kehykseen sen ensimmäisestä käyttöpäivästä lähtien, joten sen käyttöönotto ei tule olemaan niin helppoa. Tällä on vakavia seurauksia joillekin moduulin osille. Panostat kuitenkin kehitykseen: käytät viikkoja koodin kirjoittamiseen, testaamiseen, pilottiversioiden käyttöönotossa, palautteen saamisessa, regressiovirheiden korjaamisessa, odottamattomien komplikaatioiden löytämisessä, alun perin sovittujen määräaikojen noudattamatta jättämisessä, lisää koodin kirjoittamisessa, testaamisessa, palauteviestinnän saamisessa, regressiovirheiden korjaaminen - kaikki tämä F-kehyksen toteuttamiseksi.
Ja jossain vaiheessa yhtäkkiä tajuat - tai ehkä kuulet joltakulta -, että ehkä kehys F ei anna sinulle yhteensopivuutta ominaisuuden X kanssa ollenkaan. Ehkä kaikki se aika ja vaiva on käytetty täysin väärin siihen.
Jotain vastaavaa tapahtui kerran työskennellessäni projektin parissa, josta olin vastuussa. Miksi näin kävi? Koska minulla oli vähän ymmärrystä siitä, mikä funktio X oli ja miten se liittyi kehykseen F. Mitä minun olisi pitänyt tehdä? Pyydä kehitystehtävän antavaa henkilöä selittämään selkeästi, kuinka suunniteltu toimintatapa johtaa haluttuun lopputulokseen, sen sijaan, että vain toistaisi, mitä tehtiin muille moduuleille tai uskoisi hänen sanansa, että tämä on ominaisuuden X:n tehtävä.
Kokemus tästä projektista opetti minua kieltäytymään aloittamasta kehitysprosessia, ennen kuin meillä on selkeä käsitys siitä, miksi meitä pyydetään tekemään tiettyjä asioita. Kieltäytyä suoraan. Kun saat tehtävän, ensimmäinen impulssi on tarttua siihen välittömästi, jotta aikaa ei hukata. Mutta "jäädyttää projekti, kunnes pääsemme kaikkiin yksityiskohtiin" -politiikka voi vähentää hukattua aikaa suuruusluokkaa.
Vaikka he yrittäisivät painostaa sinua, pakottaa sinut aloittamaan työn, vaikka et ymmärräkään tämän perusteita, vastusta. Mieti ensin, miksi sinulle annetaan tällainen tehtävä, ja päätä, onko tämä oikea tie tavoitteeseen. Minun piti oppia tämä kaikki kantapään kautta – toivon, että esimerkkini helpottaa tämän lukevien elämää.
Neljäs ymmärryksen taso: ???
Ohjelmoinnissa on aina enemmän opittavaa, ja uskon, että olen vain raapinut ymmärtämisen aiheen pintaa. Mitä muita ymmärryksen tasoja olet löytänyt vuosien aikana työskennellessäsi koodin parissa? Mitä päätöksiä teit, joilla oli positiivinen vaikutus koodin ja sovelluksen laatuun? Mitkä päätökset osoittautuivat vääriksi ja antoivat sinulle arvokkaan opetuksen? Jaa kokemuksesi kommenteissa.
Lähde: will.com