9 ways to master horrible code, fast

sinulle on annettu tehtäväksi toteuttaa uusi ominaisuus vanhalla koodilla, mutta koodi näyttää kauhealta. Miten voit ymmärtää sen niin nopeasti kuin mahdollista? Tässä on useita pikakuvakkeita, joiden avulla voit oppia uuden koodin Tärkeät osat eksymättä epäoleellisiin yksityiskohtiin.

ohjelmoijina joudumme usein liittymään uusiin projekteihin, ja koodin laatu voi olla kaikkialla. Jopa organisoidulla tiimillä on haastavaa pitää koodin laatu yhtenäisenä koko keskikokoisessa ja suuressa projektissa.

siksi huonon koodin ymmärtäminen nopeasti voi olla arvokas taito. Se voi auttaa sinua tulla erittäin tuottava lyhyessä ajassa ja vähentää stressiä, joka yleensä tulee kanssa on uusi kaveri ja ottaa pelata kiinni-up. Se, että keskustelee työkaverin kanssa eikä tiedä, mistä se ihminen puhuu puolet ajasta, on kauhea tunne.

toisaalta, tämä on erinomainen tilaisuus näyttää asiakkaallesi tai pomollesi arvosi ja että voit päästä nopeasti vauhtiin ja tehdä heihin vaikutuksen. Useimmat kehittäjät kestää viikoista kuukausiin tulla todella tuottava koodebase he eivät rakentaneet itse.

näin hallitaan kamala koodi nopeasti.

pyydä apua. Se on tehokkain strategia

muut ovat jo oppineet, miten koodi toimii, joten miksemme kysyisi heiltä siitä? Saatat ajatella, että se saa sinut näyttämään tulokkaalta, mutta uteliaisuuden osoittaminen voi vaikuttaa voimakkaasti imagoosi työntekijänä. Jos pomosi odotti sinun tuottavan nopeasti kysymättä kysymyksiä, se on virhearvio häneltä.

jokainen ottaa oman aikansa päästäkseen vauhtiin. Esitä kysymyksiä, niin teet vaikutuksen ihmisiin, joilla on oikea asenne tiimityöhön.

monissa tapauksissa alkuperäiset kehittäjät ovat tehneet outoja tai yllättäviä päätöksiä, ja siinä koodista puhuminen on paljon arvokkaampaa kuin sen lukeminen. Näin on vielä enemmän, jos dokumentointi puuttuu. Muista, että nykyisillä kehittäjillä on arvokasta projektitietoa, jota ei kirjoiteta mihinkään.

Tee luettelo käsitteistä, joissa ei ole sinulle järkeä

saattaa olla sinulle uusia tai liian monimutkaisia bisneskonsepteja. On tärkeää saada selvennystä niistä ennen kuin yrittää työskennellä koodia, joka käsittelee näitä käsitteitä, jotta vältetään väärinkäsityksiä, jotka saattavat kestää jonkin aikaa selvittää.

saattaa olla jopa niin, että nämä ajatukset on merkitty väärin tai esitetty odottamattomalla tavalla tietokannassa. Vältä siis stressaantumasta aivojesi ympärille kietoutumisesta, ja mene vain lähteelle ja kysy siitä työkavereiltasi.

samaan tapaan saattaa olla olemassa moduuleja, luokkia tai entiteettejä, joilla ei ole sopivia nimiä. Kirjoita ne muistiin. Huonosti nimetyt elementit voivat aiheuttaa suurta sekaannusta, joten dokumentoi ne aikaisin, samoin kuin kaikki muu, joka vaikuttaa negatiivisesti kykyysi ajatella koodin toimintaa.

helpota vikojen jäljentämistä

lisäämällä koodiversio ja virtuaalikone kuten Docker tai Vagrant, lyhennät huomattavasti vian toistamiseen ja uuden ominaisuuden testaamiseen kuluvaa aikaa.

kaikenlainen väärinkäsitys siitä, miten koodi toimii, voi johtaa sinut väärien asioiden rakentamisen tielle joko siksi, että se, mitä rakennat, saattaa olla jo olemassa, etkä ole nähnyt sitä, tai siksi, että asiat eivät vain toimi niin kuin luulit.

tässä vaiheessa haluat git-versionhallinnan projektiisi. Näin voit palata vakaaseen vapautukseen tai jopa vain työskennellä erillisillä oksilla, jotka voidaan tarvittaessa hävittää.

Gitin avulla on jopa mahdollista saada parempi toistettavuus, sillä voit käyttää kätköä testauksen tai virheenkorjauksen koodin lisäämiseen, kun kaivelet vaikeasti jäljitettävää ongelmaa.

jos haluat oppia projektisi arkkitehtuurista, ota kokoonpano-ja dokumentointitehtävät jo varhaisessa vaiheessa.

samaa voidaan sanoa VMs: stä ja uusittavuudesta. Niistä on tullut kaikkialla kaikissa nykyaikaisissa kehitystiimissä, mutta tulet varmasti törmäämään projekteihin, jotka eivät käytä niitä tai ovat jopa valmiita toimimaan yhden sisällä. Joskus ensimmäinen askel uutena tiimin jäsenenä on dokumentoida vaiheet, jotka otit saadaksesi ympäristön toimimaan, ja lopulta muuttaa nämä vaiheet VM-asetusohjelmaksi.

Rakenna kaavio komponenteista

liiketoimintakäsitteiden mielikartta, tietokantataulukoiden entiteettirelaatiokaavio (ERD) ja yksinkertainen kaavio koodin komponenteista voivat suuresti vähentää uuden koodin ymmärtämisen tuskaa. Etkö muista, miten jokin toimii? Pidä hätäkeskus auki.

itse asiassa jokainen graafinen työkalu, joka auttaa sulattamaan tietoa nopeasti ja jolla on kymmenentuhannen jalan näkymä projektiin, on arvokas. Muita esimerkkejä työkaluista, jotka voivat auttaa Sinua, ovat riippuvuuskäyrät, lokit ja kartta projektin teknologiapinosta.

yksi kehityksen suurimmista ajankuluttajista on järjestelmien välinen integraatiopiste. Kokonaisnäkemys projektimaisemasta auttaa tunnistamaan, mitkä integraatiopisteet ovat kiinnostavia tutkittavia. Niihin on laitettu eniten työtä ja eniten vikoja.

toisaalta teknologia liikkuu nopeasti, ja suuria osia koodebaasista voisi olla mahdollista korvata nykyaikaisemmilla ja oikein integroiduilla ratkaisuilla. Vanha kehys olisi voinut kehittää uuden ja virallisen tavan ratkaista jokin ongelma, tai kokonaan uusi kirjasto olisi voitu kehittää parempi yhteensopivuus mielessä.

käytä visualisointi-ja mallinnusvälineitä kokonaiskuvan tarkasteluun.

valmistaudu automaattiseen testaukseen

ennen kuin aloitat asioiden rikkomisen, on aina järkevää lisätä asiaankuuluvat yksikkötestit. Testauksen ja huonon koodin ongelma on se, että huono koodi on yleensä tiukasti kytkettynä ja vaikea (ellei mahdoton) testata. Et voi eristää komponentteja, jotka ovat kietoutuneet yhteen ja jakamattomia.

näissä tapauksissa ota askel taaksepäin ja testaa kauempaa. Yleensä se tarkoittaa integraatiotestauksen tekemistä, johon on olemassa monia työkaluja. Verkkosovelluksia voidaan testata HTTP-pyyntöjä vastaan, joten on ainakin mahdollista varmistaa, että Järjestelmä vastaa samalla tavalla samoihin syötteisiin.

Integrointitestauksen suorituskyky on kuitenkin paljon huonompi kuin yksikkötestien. Toteuta yksikkötestit aina kun voit, jotta saat nopeammin palautetta koodimuutoksista. Jos se ei ole mahdollista, valitse funktionaalinen tai jopa integraatiotestaus.

tämän vaiheen pitäisi valottaa niitä säännöstön osia, joita on työstettävä. Jos on olemassa suuri määrä tiiviisti kytkettyä koodia, se on hyvä kohde refactoring integraatiotestien jälkeen, ja sitten yksikkötestaukseen myöhemmin.

tunnista epätavalliset tai riittämättömät koodausstrategiat

on aika aloittaa refaktorointi, mutta mistä aloitat?

yleensä paras paikka on paikka, jossa asiat näyttävät oudoilta, tai jossa kehityksen parhaita käytäntöjä ei ole noudatettu. Web-kehitys, joka voisi tarkoittaa rasvaa ohjaimet tiukasti kytketty mallikoodi.

pidä mielessä, että samat strategiat saattavat olla käytössä muuallakin. Joten jos, esimerkiksi, tunnistat, että rasvaa ohjaimet ovat läsnä, niin on todennäköistä, että aiemmat kehittäjät eivät yrittäneet olla ohut ohjaimet. Voit odottaa näkeväsi saman ongelman myös muissa ohjaimissa, koska se heijasteli kehitystä edeltänyttä tyyliä tai puutteita.

aluksi pienen tehtävän työstäminen

pienen vian kiinnittäminen käsitteellisesti yksinkertaiseen ominaisuuteen on hyvin valaisevaa ja auttaa tuntemaan itsensä tuotteliaaksi alusta alkaen.

tämä on samankaltainen ajatus kuin mitä Andy Hunt ja Dave Thomas kutsuvat “tracer bulletsiksi” Pragmatic Programmerissa. Taustalla oleva logiikka on sama: työskentele jonkin asian parissa päästä päähän todistaaksesi itsellesi, että se on mahdollista, ja sitten vähitellen parannat tuota alkuperäistä työtä.

“tracer bullet” – lähestyminen. Luotto: pragmaattinen ohjelmoija

hyvä esimerkki yksinkertaisesta parannuksesta on ottaa pieniä refaktorointivaiheita yksinkertaisella koodilla. Tunnistettava yhteinen ohjelmointikäytäntö, jota ei noudateta, ja sovellettava sitä.

yksi suosikeistani tähän on pesimättömät ehdolliset lohkot. Joten sen sijaan, että sinulla olisi useita if-if-lohkoja, yksi toisen sisällä, kumoa ensimmäinen ja palaa, ja tee sama kaikille löytämillesi validointityyppisille tarkistuksille. Tämä voi olla niinkin yksinkertaista kuin kääntää “jos”-tarkistus ja siirtää jonkin koodin ympäri, joten riski on lähes olematon ja tasainen koodi on helpompi lukea.

muista työstää ensin refactoring-ominaisuuksia, joita on helppo testata, sillä vaikka muutokset ovat vähäriskisiä, on aina hyvä pystyä vahvistamaan koodi ennen sen lähettämistä tuotantoon.

Hakeudu tutulle maaperälle ennen kuin tartut kriittiseen koodiin

opettele aina ensin, miten projekti on perustettu, ja vasta sitten sukella arkkitehtuuripuolelle. Kriittisimmät liiketoiminnan ja integraatiokoodin osat ovat vaikeimmin ymmärrettäviä ja muokattavia. Vältä joutumasta vaikeuksiin varhain.

vältä pääsääntöisesti sellaisia liikeasioita, jotka vaatisivat sinua tietämään projektista tai yrityspuolesta nykyistä enemmän. Se tarkoittaa yleensä pysyä erossa kauppa, maksut tai matematiikan raskas koodi, kunnes se alkaa tulla tutuksi.

kun olet tuottelias, olet tyytyväinen projektin koodaustyyliin, eikä sinulla ole vaikeuksia korjata yksinkertaisia asioita, on aika työstää vaikeampia juttuja—mutta ei ennen.

vaikka esimerkiksi maksuasioiden korjaamisella olisi jokin kiire, tuollainen tehtävä voi olla uskomattoman riskialtis. Virhe siellä voi maksaa hankkeelle kalliisti, ja se koituu myös sinulle. Ehdottomasti kieltäydyttävä tekemästä riskialttiita tehtäviä varhaisessa vaiheessa, jos suinkin mahdollista.

miten käsitellä tuntematonta tekniikkapinoa

viimeisen pisteen kohdalla yleinen ongelma, johon olen törmännyt, on se, että jokainen uusi projekti sisältää yleensä jotain teknologiaa, jota en tunne.

kun niin käy, minulla on pari strategiaa, joiden avulla pääsen nopeasti vauhtiin. Oppimispolku on dokumentaation lukeminen ja uuteen teknologiaan tutustuminen. Mutta vaikka opit paljon rakenteesta, että polku ei auta sinua oppimaan kulma tapauksissa, jotka tyypillisesti tulevat kokemusta. (“Kulmatapaus” on insinööritermi, joka viittaa tilanteeseen, joka tapahtuu normaalien käyttöparametrien ulkopuolella.)

yksi tapa nopeuttaa tätä kokemusprosessia on ottaa kysymyspohjaisia resursseja, kuten Stack Overflow ja Quora, ja vain lukea ne läpi kuin kirja. Etsi suosituimmat kysymykset oppimastasi kirjastosta ja katso, millaisiin ongelmiin muut ihmiset tyypillisesti törmäävät. Et välttämättä törmää niihin itse, mutta sen tietäminen, mikä on mahdollista, on kuin loihtisi kirkkaan valon mielikartalle niistä uusista ideoista.

Leverage Stack ylivuoto kysymyksiä saada kokemusta nopeasti. Luotto: Stack Overflow

jos haluat tarkemman lähestymistavan, Etsi tietoa kirjaston ominaisuuksista, joita käytetään erityisesti uudessa projektissasi. Tutustu niihin, jotka ovat sinulle uusia, ja opi ne etukäteen, ennen kuin sinun täytyy koskea siihen koodiin lainkaan.

Jaa ideasi