Tässä on se, mitä olen oppinut yhdeksän kuukautta ohjelmistosuunnittelutyössäni

Olen työskennellyt noin yhdeksän kuukautta Dexterissä ohjelmistokehittäjänä. Kirjoitin blogiviestin työn laskeutumisesta aluksi sekä teknisen viestin itsesi sijoittavasta komponentista, jonka tein parin ensimmäisen kuukauden aikana yrityksessä. Työn saaminen oli alkuperäinen tavoitteeni, ja sen pitäminen ja kasvaminen kehittäjänä oli luonnollinen seuraava askel eteenpäin.

Ajatukseni roolistani ovat muuttuneet merkittävästi aloittaessani. Luulin, että kehittäjänä oli koodin avaaminen mahdollisimman nopeasti. Se on kauimpana todellisuudesta. Paljon haastavan koodin hakeminen nopeasti ei ole skaalautuva tapa rakentaa yritystä tai uraa kehityksessä. Onneksi löysin saman työn tuntevan työnantajan, jonka tuote on ohjelmisto.

Tavoitteena on kirjoittaa juuri oikea määrä hyvää koodia ja kommunikoida hyvin. Sinulle ei makseta koodia, sinulle maksetaan ajatella ja selvittää ongelmia. Sivutuote on kiteytetty ajatus ja ohjeet koneen seuraamiseksi koodin muodossa. Haluaisin mieluummin ratkaista ongelman yhdellä selkeän luettavan koodin rivillä kuin 10 koodirivillä, joita on vaikea ymmärtää. Haluaisin mieluummin ratkaista ongelman 5 rivillä luettavaa kommentoitua koodia kuin yksi rivi erittäin monimutkaista, monipesäistä koodia, jossa on useita kolminkertaisia ​​operaattoreita. Saat idean.

Esitä paljon kysymyksiä ja dokumentoi vastaukset

Pomoni lähetti minulle tämän linkin, joka keräsi paljon stressiä ja ahdistusta, jonka tunnen uudena insinöörinä. On aliarviointia sanoa, että olen hyvin itsetietoinen kysymysten esittämisessä.

Käytän tätä tarkistusluetteloa ennen kuin pyydän muita apua:

  • Onko tämä kysymys, jonka olen kysynyt aiemmin, ja jos on, missä dokumentoin vastauksen?
  • Voisinko tämän Googlen avulla?
  • Onko joku muu sisäisesti dokumentoinut tämän?
  • Mitä täällä tapahtuu? Mikä on virheen tai odottamattoman käyttäytymisen perimmäinen syy?
  • Ymmärränkö todella kysymyksen, johon yritän vastata? On okei ottaa jonkin aikaa ja lukea ongelma uudelleen sen sijaan, että annat puoliperän tai kiireisen vastauksen.

Kun olen suorittanut nämä vaiheet, ratkaisen ongelman itse, löydän dokumentoidun ratkaisun tai esitän kysymyksen, jossa on paljon parempi konteksti ja yksityiskohtaisuus, mikä helpottaa jonkun muun auttamista. Vielä parempi, jos kysyn hyvän kysymyksen ja siihen voidaan vastata chatin kautta, joukkuetoverini ei tarvitse pudottaa kaikkea auttaakseen minua.

Jos olen mennyt 90% tiestä ongelman ratkaisemiseen ja tarvitsen vain viimeiset 10% apua, vanhempi kehittäjä auttaa mielellään tietäen, että sain itselleni niin pitkälle kuin pystyin. Etsimään jotakuta muuta ratkaisemaan ongelmasi, ei ole hyvä tapa luoda luottamusta tiimisi sisällä.

Älykkäät ihmiset pitävät hyvistä kysymyksistä - niin kysy heiltä.

Vältä samojen virheiden tekemistä ja samojen kysymysten esittämistä uudestaan ​​ja uudestaan

Tämä on helpommin sanottu kuin tehty, ja se voi olla totta missä tahansa työssä, ei vain ohjelmoinnissa. Paljon uusia käsitteitä ja tietoja heitetään tietäsi, ja virheiden tekeminen on väistämätöntä. Ole tietoinen siitä. Ajattele ennen kuin kysyt. Google-tavaraa. Katso asiakirjoja. He ovat ystäväsi. Jos näet trendin, yritä tunnistaa se. Ponnistele aktiivisesti saadaksesi itsesi esille samantyyppisiä kysymyksiä. Kirjoita se muistiin ja aseta tavoitteeksi sen korjaaminen.

Varmista, että kun seuraavan kerran kohtaat saman ongelman, tiedät mitä tehdä. Me kaikki teemme virheitä, mutta olemalla itsetietoinen ja pyrkimällä muutokseen, kaikki paranevat.

Tarkista työsi aina

Kukaan ei tykkää käydä PR-palvelua ja käskeä sinua poistamaan konsoli.logit ja virheenkorjaajat tai käskemään korjaamaan nukkausvirheet. En julkaisi tätä viestiä lukematta sitä muutaman kerran ja pyytäen myös kaveria katsomaan.

Katso todella koodisi ja kysy itseltäsi nämä kysymykset:

  • Kirjoitin monimutkaisen logiikan. Onko sovelluksessa vastaavia toimintoja, jotka ehkä tekevät tämän luettavammalla, joustavammalla tai yleisemmällä tavalla?
  • Jos ei, muistanko miksi kirjoitin tämän koodin viikossa? Jos vastaus on ei, haluan todennäköisesti muuttaa koodin tai kommentoida sitä. PR-tarkistuksen tekevällä henkilöllä on oltava jonkinlainen konteksti siihen, miksi tein päätöksen.
  • Varmista, että koodisi läpäisee nukkauksen ja testit, ennen kuin annat sen kenellekään muulle.
  • Toistanko itseni? Voinko kapseloida toistamani logiikan funktioksi?
  • Jos tämä oli jonkun toisen koodi, jota tarkastelin, mitä kommentteja tekisin? Mitä haluaisin muuttaa, jotta siitä tulisi suoraviivaisempi?

Katso koodiasi tuoreilla silmillä (ehkä seuraavana päivänä). Onko komponenttien kohdalla erityistä logiikkaa, jonka ei pitäisi olla? Käsitteleekö komponenttisi liiketoimintalogiikkaa, jonka pitäisi mennä säilöön?

Lisäksi hyvä omakoodin tarkistus säästää aikaa ja rahaa yritykselle. On paljon halvempaa löytää omat vikasi ja korjata ne itse sen sijaan, että joku muu löytää ne kaksi päivää myöhemmin.

Viimeinen asia koodisi tarkistamisesta. Kosketa ja napsauta KAIKKI mitä olet työskennellyt. Haluan kenellekään lähettämäni koodin olevan erittäin vaikea rikkoa. Jos he napsauttavat uutta sivua ja saavat suuren virheen tai valkoisen kuolemanäytön, se osoittaa, etten ole oikeastaan ​​tarkistanut työni. Ota huomioon muokkaamasi koodi ja varmista, ettet rikkonut jotain muuta lisäämällä jaettuun komponenttiin.

Se saattaa tuntua typerältä, mutta suuret koodipohjat ovat monimutkaisia, etkä ehkä ymmärrä, että rikot jotain ennen kuin teet.

Vakavasti, et halua nähdä tämän blogikirjoituksen ensimmäistä luonnosta :)

Mikään ei ole taikaa

Yleensä on hyvä syy sille, miksi koodi on LGTM'itetty (hyväksytty ja koodipohjassa). Jos et ymmärrä, miten se toimii, viettää aikaa sen selvittämiseen. Loki tavaroita, hajota juttuja, katso joitain käytettyjen toimintojen ja kuvioiden dokumentaatioita.

Voisitko kertoa kumiankkalle kuinka se toimi? Jos et ole vielä varma, kysy joitain kysymyksiä ymmärryksen aukoista.

Hanki mukava virheenkorjaus, koska teet sen paljon

Virheenkorjaus on ymmärtää koodin toiminnassa oleva ongelma ja ratkaista vika. Sinun on ymmärrettävä, miten asia toimii, jotta voit selvittää, miksi se ei toimi ensiksi. Selaimen virheenkorjaustyökalujen käyttö helpottaa elämääsi ja työtäsi. Debuggeri- ja konsolimenetelmät ovat ystäväsi.

Joitakin hyödyllisiä resursseja, jotka löysin:

  • CSS-temppuja virheenkorjaukseen
  • Etupään päälliköiden virheenkorjaus (se on maksettu, mutta melko hyvä)

Pro-tip: console.log-ulostulo voidaan tyylitellä CSS: llä. Tämä tekee haluamastasi lokista helpommin tunnistettavissa.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Seuraa tietoja

Tämä tuli esiin yhä uudelleen, koska tosin se oli virhe, jota tein jatkuvasti. Se on jotain, josta sain paremman, mutta tarvitsen silti työtä.

Suuri osa ohjelmistokehityksestä sisältää tietojen manipuloinnin muotoon, jotta käyttäjä voi saada siitä hyödyllisen käsityksen tai päivittää sen itse.

Sovelluksissa, joissa on yksisuuntainen tietovirta ja globaali tila, on suora tietojohto. Kaikki nämä tiedot ovat peräisin jostakin. Kun selvität, mistä se tulee, virheenkorjaus on helpompaa.

Eristää ongelmat ja integroi ne sitten työhösi

Codepen.io on läheinen ystäväni, ja sen pitäisi olla myös sinun. Kun en pysty selvittämään, mikä aiheuttaa ongelman, teen yksinkertaisen version rakentamastani. Varmistan, että se toimii, ja integroin sen sitten kehitysympäristöni. On helpompi selvittää, mikä saattaa rikkoa käyttöliittymääsi riisutussa ympäristössä.

Ajattele, kuinka toiminnallisuuden pitäisi toimia

Sen kirjoittaminen, kuinka jotain pitäisi toimia 30000 jalan tasolta ja sitten tekniseltä tasolta, on auttanut minua ymmärtämään, mitä minun pitäisi rakentaa, miten minun pitäisi rakentaa sitä, ja auttaa lieventämään kaatumisia. Jos en osaa selittää, miten rakennamani asia toimii (korkealta ja matalalta tasolta), teen itselleni karhunpalveluksen. Ilman suunnitelmaa aion tehdä paljon pyörän pyörimistä lähitulevaisuudessa.

Lisäksi voin viitata takaisin kirjoittamaani tai näyttää jollekulle ajatteluni, mikä auttaa vähentämään väärinkäsitystä.

Ota vastaan ​​taistelu

10000 tunnin työssäkäynnin jälkeen pystyt paremmin kamppailemaan ja ratkaisemaan ongelmia. Sinun on tehtävä se riippumatta, joten kokemuksen nauttiminen tekee päivästäsi paljon, paljon parempaa. Nauraa itsellesi vähän ja yritä todella hajottaa ongelma. Pääset sinne, vaikka tarvitset hieman ylimääräistä apua.

Ota rakentavaa kritiikkiä ja toista sitä jatkuvasti

Tiimikaverit haluavat sinun tekevän paremmin. Vanhemmat kehittäjät haluavat tehdä sinusta vahvemman kehittäjän. Toimi heidän neuvojensa mukaan, vaikka et aluksi ymmärrä, miksi he käskevät sinua tekemään niin. Koskaan ei ole vain yksi henkilö, joka tietää kaiken. Keskustele sen kanssa.

Ei kiirettä

Työn läpi kiirehtiminen aiheuttaa edestakaisin, paljon hämmennystä ja lisää turhautumista. Pomoni haluaa mieluummin paremman koodin myöhemmin kuin huonon koodin aikaisemmin. Tarkoitan, eikö me kaikki?

Jatka oppimista työn ulkopuolella

Niin paljon kuin opin työpaikalla, haluan edelleen oppia uusia asioita sen lisäksi, että työskentelen vain koodipohjamme kanssa. Se voi olla Pythonin poiminta, botin rakentaminen, videosarjan tai henkilökohtaisen projektin parissa työskentely. Tein taulun Zenhub + Githubin kanssa seuratakseni missä olen ja mihin olen sitoutunut kuukauden aikana. Kuukauden yleisen tavoitteen pitäminen on pakottanut minut jatkamaan oppimista, rakentamista ja kyllä, bloggaamista omalla ajallaani.