NOTE: Apart from
(and even then it's questionable, I'm Scottish). These are machine translated in languages I don't read. If they're terrible please contact me.
You can see how this translation was done in this article.
Wednesday, 06 November 2024
//Less than a minute
Freelance-kehittäjänä yksi taitokokonaisuuksista, joka sinun on opittava nopeasti, on se, miten voit työskennellä tehokkaasti olemassa olevien koodikantojen parissa. Olen ollut onnekas, kun olen rakentanut joukon scratch-järjestelmiä; tämä on JOY kokeneena kehittäjänä, mutta se ei aina ole niin.
Legacy-järjestelmissä on merkittäviä haasteita, etenkin kun keskeiset kehittäjät / arkkitehdit (jos olet onnekas, että olet saanut ne) ovat siirtyneet eteenpäin.
Tämä unohdetaan usein erityisesti pienemmissä yrityksissä. Yleensä tarvitset neljä keskeistä asiakirjatyyppiä:
Dokumentaatio on yksi niistä asioista, joita kehittäjinä usein vihaamme (se EI ole koodia), mutta se on ratkaisevan tärkeää. Kuten näet, rakastan Markdownia, merenneidon ja Plantumlin kaltaisilla laitteilla voit luoda todella hienoja kaavioita ja vuokaavioita, jotka voidaan sisällyttää asiakirjoihin.
Sen pitää olla CURRENT, kehittäjät puhuvat usein bittirotista, jossa projektin riippuvuudet vanhentuvat / suorastaan turvallisuusriskeistä. Tämä pätee myös asiakirjoihin; jos se ei ole ajankohtaista, siitä ei ole hyötyä.
Dokumentaatiot vaihtelevat, mutta yleisesti ottaen milloin tahansa muutat asiakirjassa mainittua koodia, sinun tulee päivittää kyseinen asiakirja.
Tämä on usein haasteellista, etenkin jos järjestelmä on ollut olemassa jo jonkin aikaa. Sinun täytyy tietää, mikä versio Nodesta /.NETistä jne., mikä versio tietokannasta, mikä versio kehyksestä jne. Tämä jätetään usein huomiotta, mutta se on CRUCIAL, jotta se käynnistyisi ja toimisi nopeasti.
Olen usein nähnyt kehittäjien sanovan, että tällä ei ole merkitystä näinä pilvijärjestelmien ja laajalevikkisten sovellusten aikoina, mutta olen eri mieltä. Järjestelmää pitää pystyä ohjaamaan paikallisesti, jotta ongelmat voidaan selvittää nopeasti ja tehokkaasti.
Response.Write Classicissa ASP on ohi. Vaatimattoman monimutkaisessa sovelluksessa (etenkin niissä, joita et kirjoittanut) koodin läpivieminen on ratkaisevan tärkeää. Seuratakseen sen alusta palvelun kautta esittämää pyyntöä selvittää, mitä MIGHT-tapahtumassa tapahtuu, mitä poikkeuksia ei ehkä saada kiinni jne.LogInformation jokaisesta pyynnöstä. Voit ehkä haluta käyttää mukautettua telemetriaprosessoria suodattamaan pyyntöjä, joita et halua kirjata.Jokaisessa projektissa teen työtä sen eteen, että saamme järjestelmän (tai suuren osan siitä) toimimaan paikallisesti. Näkemällä koodin, käyttämällä koodia, vioittamalla koodia saat tuntuman järjestelmän toimintaan.
Jokaisessa järjestelmässä tämä on sinun totuuden lähdeSanovatpa lääkärit mitä tahansa, mitä muut kertovat siitä, miten sen pitäisi toimia, näin se toimii.
Näin usein haastavaa on se, että löytää tiensä uuteen kaupunkiin, jossa ei ole etenemissuunnitelmaa. Onneksi sovelluksissa on hakupiste (sivun lataus / etupään API-puhelu jne.) Valitse piste ja aloita sieltä.
Käytä sen kanssa vuorovaikutukseen mitä tahansa, oli se sitten Postimies, Rider's HttpClient tai jopa nettisivu. Koputa vianetsintään, soita puhelu ja seuraa sitä. Huuhtele ja toista järjestelmän jokainen osa.
Yleensä jätät tämän väliin, kunnes ymmärrät järjestelmän. On aina houkuttelevaa "heittää se pois ja aloittaa alusta" mutta vastustaa kuitenkin tätä houkutusta. Varsinkin käyttöjärjestelmän osalta Se toimii Järjestelmän uudelleenrakentaminen / jopa uusiminen on HUGE-riski. Kyllä se on hauskaa, mutta jokaiselle koodiriville, jota vaihdat, on riski ottaa käyttöön uusia kiinnostavia vikoja.
Kuten kaikki muukin (etenkin hankittaessa) sinun täytyy perustella tekemäsi työ järjestelmällä. Joko tämä perustelu on keskitettävä johonkin seuraavista:
Tämä jää usein huomiotta, erityisesti kehittäjiltä. Sinun täytyy pystyä perustelemaan työ, jota teet järjestelmän parissa. Tämä pätee erityisesti sopimusympäristössä, jossa palkkaa maksetaan tunnilta. Loppujen lopuksi se ei ole sinun koodisi eikä sinun rahasi. Miksi olet tekemässä muutosta, on usein tärkeämpää kuin itse muutos.
Olen työskennellyt urakoitsijana jo yli vuosikymmenen, eikä se ole helppoa, vaan urakoitsijana jokainen tunti ajastasi on asiakkaalle "hinta". Sinun täytyy lisätä siirtoarvoa järjestelmään enemmän kuin maksat. Jos et ole, etsit nopeasti uutta sopimusta.
Kehittäjinä olemme yleensä surkeita bisnesihmisiä, jotka keskittyvät "täydellisyyteen" joka käänteessä. Todellisuudessa ei tarvitse tehdä järjestelmästä "täydellistä" (mikäli väittäisin, ettei sellaista ole), vaan asiakkaalle pitää vain antaa arvoa.
Pidemmällä aikavälillä tämä sisältää myös sen, että uutta koodi on ylläpidettävä ja kustannustehokas pyöritettäväksi. Perintöjärjestelmissä tämä on paljon pahempaa. Usein on kahlattava suon läpi ja oltava huolissaan siitä, että kun oppii järjestelmän, ei voi tarjota paljonkaan arvoa. I'm not making any changes luulet, että I'm just learning the system.
Tämä on harhaluuloa; opettelet järjestelmää parantamaan sitä. Opettelet järjestelmää tehostamaan sitä. Opettelet järjestelmää tekemään siitä huollettavamman. Jos asiakas ei voi hyväksyä tätä askelta, sinun on oltava hyvin varovainen sen suhteen, miten viestit tästä (tai etsit uutta sopimusta).
Usein unohdetaan, että usein sinut otetaan mukaan urakoitsijaksi, koska joku avainhenkilö on lähtenyt (älä sekaannu tämän politiikkaan, se ei ole sinun huolesi). Projektin tavoitteiden saavuttamiseksi pitää pystyä työskentelemään siellä olevien ihmisten kanssa. Sopimuksessa on yleensä määritelty kihlauksen ehdot (nykyisessä sopimuksessani se on "luotettavuuden parantaminen ja juoksevien kustannusten alentaminen"). Keskity tähän. Jos et ole varma, mitä tämä tarkoittaa, kysy.
Muista, kuka on suora kontaktisi, erityisesti parin ensimmäisen kuukauden aikana. Pidä heidät ajan tasalla (todennäköisesti sinulla ei ole uusia ominaisuuksia, joilla kehuskella, kun innostut järjestelmän toiminnasta). Lähetän yleensä viikoittain/kahden viikon välein tiivistetyn sähköpostin suoralle kontaktilleni. Tämä on hyvä tapa pitää heidät ajan tasalla siitä, mitä olet tekemässä ja mitä olet löytämässä.
Muista, että tämä on se, joka hyväksyy laskusi; laskun aikaan ei pitäisi tulla yllätyksiä. Kun alat tarkistaa koodia säännöllisesti, kyseessä ei ole niinkään ongelma; sinulla on tieto siitä, mitä teit ja millainen vaikutus sillä oli. Siihen asti on pidettävä heidät ajan tasalla. Heidän täytyy tietää, mitä teit ja miksi he maksaisivat siitä.
Takaisin perintökoodiin: jos teet muutoksen yleensä, sinun on otettava se käyttöön.Vaikka parhaatkin meistä joskus munaavat THE UP:n, varsinkin perintökoodijärjestelmissä tulee olemaan jotain. Et voinut tietää kun sijoitat. Tämä palautuu kirjautumiseen - jos sinulla on lavastuspalvelin, se kirjautuu LOT (mutta säilytetään lyhyen aikaa) niin kun laitat THEn käyttöön, voit kerätä lisää tietoa siitä, mikä epäonnistui.
Vaikka olisit kuinka hyvä, kuinka paljon paikallisia testejä olet tehnyt, olemme kaikki ihmisiä. Tämä on keskeinen osa "älä ota käyttöön perjantaina" -sääntöä; odota, että käyttöönotto aiheuttaa uuden ongelman järjestelmässä. Ole valmis tekemään töitä, kunnes asia on ratkaistu. Jos et tiedä, miksi se epäonnistui, lisää lisää testejä ongelman uusimiseksi ja lisää puunkorjuuta, jotta saat vastaavat ongelmat tulevaisuudessa.
Erityisesti tuotantojärjestelmissä pysähdysjärjestelmäsi ei välttämättä ole 1:1 (varsinkaan kuorman osalta), kuten k6 Se voi auttaa simuloimaan kuormaa (ja vielä paremmin paikallisesti, missä voit tehdä oikean profiloinnin kuten aiemmin mainittiin).
CI/CD:n kiihko on usein jäänyt huomaamatta. Yksinkertaista, sinä mokaat. Hyvin nopea ja tehokas tapa ottaa järjestelmä käyttöön tarkoittaa, että kun rikot sen, voit myös korjata sen nopeammin. Jos CI-koodin tarkistusjärjestelmä tarkoittaa, että PR:n yhdistäminen kestää kaksi päivää, se on nopeinta, mitä järjestelmää voi kohtuullisesti käyttää. Jos CD-järjestelmäsi tarkoittaa, että poistat juoksujärjestelmän, totu pitkiin iltoihin.
Tehokas mekanismi koodin korjaamiseksi ja käyttämiseksi on välttämätön tehokkaan kehitysputken kannalta. Jos korjauksen käyttö kestää kauemmin kuin sen löytäminen ja toteuttaminen koodilla, niin todennäköisesti korjaaminen on epätodennäköisempää.
Sanon tämän lainauksin, koska tämä on ongelma. Perinnöllisissä sovelluksissa (varsinkin silloin, kun laajamittainen uudelleentyö on rajatonta) on kaksi päälähestymistapaa.
Tämä on yksinkertaisesti olemassa olevan koodin kiinnittämistä. Varmista jälleen, että testaat perusteellisesti ja sinulla on käytössäsi prosessit, joiden avulla mahdolliset korjaukset voidaan palauttaa / siirtää nopeasti. En valehtele, että tällainen kehitys on harvoin hauskaa, koska olet edelleen todennäköisesti kahlaamassa olemassa olevan koodipohjan suolla. Monissa tapauksissa se on kuitenkin välttämätön paha.
Kuten tavallista, sinun tulisi varmistaa, että sinulla on jonkinlainen testimuoto nykyisen koodin selvittämiseksi. Ihannetapauksessa sen pitäisi myös testata epäonnistumista asiassa, jota yrität ratkaista, ennen kuin teet korjauksen. . He haluavat, että heille tehdään yksikkötesti, joka kohdistaa tarkasti koodialueen, joka sinun on korjattava, mutta tämä ei useinkaan kuulu suurten, hajautettujen järjestelmien työskentelyn piiriin.
Käytän yleensä testijärjestelmää tässä järjestyksessä:
Jotta voit päivittää järjestelmän osia, voit tunnistaa osia, jotka voidaan erottaa olemassa olevasta monoliittista mikropalveluksi (jostakin'mikron' arvosta). Tämä voi olla hyvä tapa aloittaa järjestelmän uudenaikaistaminen ilman, että vaarana on täyskäännös. Yleisiä esimerkkejä voivat olla API-päätteiden jakaminen uusiin projekteihin, joissa käytetään päivitettyjä elementtejä. DRY:n kauhu voi kuitenkin tulla kuvioihin tässä asiassa. Huonosti jäsennetyssä ratkaisussa on usein paljon "auttaja" tai "palvelu" -komponentteja, joiden pitäisi todella olla eri projekteissa (tai jopa sankoissa paketeissa, joissa käytetään enemmän globaalia uudelleenkäyttöä).
Käsittelen tätä lähestymistapaa tarkemmin tulevassa artikkelissa, koska se on keskeinen osa sitä, miten työskentelen perintöjärjestelmien parissa ja se ei ole monelle kehittäjälle itsestään selvää.
Nyt kun olemme saaneet tämän kaiken ulos, tulee kinkkinen maksuongelma. Minulla on yleinen sääntö:
Kaikki maksuongelmat, joita haluan jatkaa
Jos he ovat myöhässä maksamisesta, riippuu sopimuksestasi, mutta LEASissa 30 päivän kuluessa, mutta yleensä lähempänä seitsemää, tämä on huono merkki. Jos laskustasi on riitelyä, mieti, pystyykö yhtiö jatkuvasti maksamaan palveluistasi.
Älä pelleile tämän kanssa; jos olet tehnyt työsi, sinulle pitää maksaa ajallaan. Sillä ei ole väliä, kuinka paljon nautit siitä; jos huono asiakas voi käyttää sinua hyväkseen, he käyttävät. Se ei ole koskaan sen arvoista.
Ole rehellinen; veloita vain ajasta, jonka olet todella työskennellyt; varmista, että on selvää, mitä teit ja miksi teit sen.
Olen johtanut kehittäjien tiimiä ja ollut kehittäjä; olen ollut urakoitsija ja olen ollut asiakas. Olen nähnyt kaikki puolet tästä ja voin kertoa, että jos et saa palkkaa ajoissa, sinun on jatkettava eteenpäin. Jos kääntöpuolella on urakoitsija (tai kokoaikainen urakoitsija), joka ei toimita, tähän on puututtava nopeasti. Kaikilla on henkilökohtaisia kamppailuja, mutta etenkin sopimusympäristössä pitää tuottaa arvoa tai olla veloittamatta aikaa, kun ei ole.
Mitä korkoon tulee, löydät tasosi; henkilökohtaisesti veloitan enemmän hankkeista, joissa minulla on enemmän vastuuta (tai jotka eivät näytä hauskoilta). Veloitan vähemmän projekteista, joissa opettelen uutta teknologiaa, tai aloittelevista yrityksistä. Olen myös tehnyt vähemmän töitä, mutta pitänyt kurssini tasaisena. Mutta älä hyväksy matalaa hintaa; olet ammattilainen ja sinulle pitäisi maksaa sellaisenaan.
Siinä kaikki. Olen tänään ja huomenna poissa töistä isoäitini hautajaisissa ja suoraan sanottuna panikoin hieman, että minulla on HUGE-perintöjärjestelmä opeteltavana, joten ajattelin oksentaa ajatukseni siitä, mitä työskentely näissä järjestelmissä on ja mitä haasteita.