Ohjelmointi

7 avainkoodauskäytäntöä ketterille kehittäjille

Ketterä ohjelmistokehitys ei ole vain ketteriä periaatteita ja käytäntöjä. Menestyäkseen sellaisten ohjelmistojen julkaisemisessa, jotka vaikuttavat positiivisesti loppukäyttäjiin, korjaavat teknisen velan ja käyttävät luotettavasti, kehitystiimin on myös otettava huomioon ketteryyttä ajavat koodauskäytännöt ja arkkitehtuuristandardit.

Vielä tärkeämpi näkökohta on vaakalaudalla teknologiaorganisaatioilla. Niin vaikeaa kuin onkin kehittää ohjelmistoja, on vielä vaikeampaa ottaa parannuksia ja päivityksiä käyttöön säännöllisesti pitkiä aikoja. Devopsin CI / CD- ja IAC-toiminnot (infrastruktuuri koodina) käsittelevät osittain yhtä kriittistä tekijää, koska automaatio mahdollistaa luotettavat ja toistettavat tavat sovellusten käyttöönottoon. Lisää jatkuvaan testaukseen, ja kehitystiimeillä on tapa vahvistaa, että koodimuutokset eivät vaikuta olemassa oleviin toimintoihin.

Sovellusten vanhetessa alkuperäiset kehittäjät siirtyvät kuitenkin muihin projekteihin ja joskus muihin yrityksiin. Kun uudet kehittäjät liittyvät tiimiin, heidän on opittava ohjelmiston arkkitehtuuri ja ymmärrettävä koodi, ennen kuin he voivat muuttaa sitä luotettavasti ja tehokkaasti.

Lisäksi sovelluksia rakentavat kehittäjät haluavat usein kehittää uusia. Saatat tuntua mukavalta ja turvalliselta pysyä kiinni kehittämissäsi sovelluksissa, mutta koodiin kytkeminen ei ole terveellistä urallesi tai organisaatiollesi.

Paras tapa siirtyä uusiin ja jännittäviin ohjelmistokehityshankkeisiin on tehdä arkkitehtuurista, sovelluksesta ja koodista helposti muiden kehittäjien tukema. Ketterien tiimien ja kehittäjien on luotava koodauskäytännöt, jotka ylläpitävät jatkuvaa ohjelmistokehitystä.

1. Älä keksi pyörää uudelleen

Ensimmäinen koodaussääntö: Älä koodaa jotain, jota ei tarvitse koodata! Miten?

  • Harkitse kysymysten esittämistä vaatimuksista. Miksi ominaisuus on tärkeä? Kuka hyötyy? Tarkemmin sanoen, etsi koodaamattomat vaihtoehdot ongelman ratkaisemiseksi. Joskus paras ratkaisu ei ole lainkaan ratkaisu.
  • Onko joku organisaatiossasi jo koodannut samanlaisen ratkaisun? Ehkä on mikropalvelu, joka tarvitsee vain parannusta, tai ohjelmistokirjasto, joka tarvitsee pienen päivityksen? Muista etsiä organisaatiosi koodikanta ennen uuden koodaamista.
  • Onko olemassa kolmansien osapuolten ratkaisuja, mukaan lukien edulliset SaaS-työkalut tai avoimen lähdekoodin vaihtoehdot, jotka täyttävät vähimmäisvaatimukset?
  • Oletko tarkastellut avoimia koodausvarastoja, kuten GitHub, koodin esimerkkejä ja katkelmia varten, jotka täyttävät organisaatiosi vaatimustenmukaisuusvaatimukset?

2. Harkitse matalan koodin kehitysvaihtoehtoja

Jos joudut koodaamaan ratkaisun, niin vaihtoehtoiset matalakoodialustat voivat ehkä mahdollistaa ominaisuuksien kehittämisen tehokkaammin kuin Java-, .Net-, PHP- ja JavaScript-koodaus.

Pienikoodialustat, kuten Caspio, Quick Base, Appian, OutSystems ja Vantiq, tarjoavat kaikki työkalut sovellusten kehittämiseen pienellä koodilla ja joskus jopa ilman koodausta ollenkaan. Jokainen alusta on erikoistunut erilaisiin ominaisuuksiin ja soveltuu siten tiettyyn sovellusluokkaan. Esimerkiksi Caspio helpottaa lomakkeiden ja työnkulkujen upottamista verkkosivustoihin. Quick Base tarjoaa vankat työnkulun ja automatisointimahdollisuudet, ja Vantiqin tapahtumapohjainen arkkitehtuuri soveltuu IoT: lle ja muille reaaliaikaisille tietosovelluksille.

Toisinaan tarvitaan koodausta, mutta kehittäjien tulisi myös osata yhtä tai useampaa matalan koodin kehitysvaihtoehtoa ja harkita niitä sopivissa käyttötapauksissa.

3. Automatisoi testaus

Vaatimusten täyttävän koodin kirjoittamisen lisäksi yksi tärkeimmistä asioista, jotka kehittäjien on tehtävä, on testata se. Testiohjatut kehityskäytännöt ja automatisoidut testaustyökalut ovat kypsyneet, ja kehitystiimien tulisi sisällyttää yksikkö-, regressio-, suorituskyky- ja turvatestaus osaksi ketterää arviota.

Sen lisäksi, että testeillä on koontiversioiden ja julkaisujen validointi, nämä testit auttavat myös tekemään koodista tuettavamman. Testit ovat asiakirjoja ja muodostavat sopimuksen siitä, kuinka koodin pitäisi toimia. Kun uudet kehittäjät liittyvät joukkueisiin ja toteuttavat vahingossa huonon muutoksen, jatkuva testaus keskeyttää rakennuksen ja antaa mielekästä palautetta kehittäjälle ongelman nopeaan ratkaisemiseen.

4. Ulkoista kaikki kokoonpanoparametrit

Kehittäjille ei pitäisi olla mitään tekosyitä koodikoodin järjestelmäkohtaisille asetuksille, käyttäjänimille ja salasanoille tai muille kokoonpanotiedoille. Olen nähnyt kehittäjien käyttävän pikavalintoja kehittäessään prototyyppejä, jotka löytävät tiensä tuotantoympäristöihin. Nykypäivän arkkitehtuureissa tätä ei pitäisi koskaan tehdä. Kovakoodaus ei ole tekninen velka, vaan laiska, vastuuton koodaustapa, jolla voi olla merkittäviä seurauksia. Jos koodi pääsee vahingossa käsiksi, se luo suojausheikkouden, jos päätepisteet tai käyttöoikeustiedot ovat alttiina.

Yhden askeleen eteenpäin, kun vanhoja koodeja käsitellään, kaikkien koodattujen kokoonpanojen ja parametrien käsittelemisen tulisi olla neuvottelematon tekninen velkaprioriteetti.

5. Noudata nimeämiskäytäntöjä ja lisää kommentteja koodin luettavaksi

Olen kerran työskennellyt uskomattoman lahjakkaan kehittäjän kanssa, joka ei osannut englantia hyvin eikä ollut paras konekirjoittaja. Hän tekisi esineitä sellaisilla nimillä kuin a, b, ja c ja luo sitten paikalliset muuttujat nimeltään zz, yy, xx. Hän sitoutui puhdistamaan tämän ennen julkaisua, mutta seurasi sitä harvoin.

Sinun ei tarvitse olla perustanut pari- tai mob-ohjelmointia tunnistaaksesi, että tämä on kauhea käytäntö.

Joukkueiden tulisi ottaa käyttöön nimeämiskäytännöt, kuten Googlen JavaScript-tyyppinen opas ja Java-tyylinen opas, ja sitoutua kommentoimaan koodia ainakin moduulitasolla ja mieluiten luokan tasolla. Lisäksi organisaatioiden tulisi harkita staattisten koodien analysointityökalujen käyttöä, jotka antavat palautetta kehittäjille, kun koodi tarvitsee korjata rakenteen ja luettavuuden kannalta.

6. Tarkista koodi versionhallintaan usein

Jos et tarkista koodiversiota versionhallintaan päivittäin tai useammin, se voi aiheuttaa ristiriitoja ja muita estoja, jotka vaikuttavat tiimiin. Yksi pieni virhe voi saada ketterät joukkueet menettämään sprinttisitoumuksensa tai luoda lisätyötä riippuvuuksien ratkaisemiseksi.

Joukkueiden tulisi sopia tavoista tarkistaa koodi, joka ei ole valmis tuotantoon. Tavanomaiset lähestymistavat sisältävät ominaisuuslippuja ja Gitin haarautumisen.

7. Vältä sankarien ja monimutkaisuuksien koodaamista

Useimmista tuntemistani kehittäjistä tuli ammattilaisia ​​ohjelmistoinsinöörejä, koska he rakastavat ratkaista koodauksen haasteita. Koodaus on taidetta, tiedettä ja käsityötä, ja paremmat kehittäjät etsivät ajatuksia herättäviä koodaustehtäviä ja tyylikkäitä toteutuksia.

Paitsi että haastavien liike- ja teknisten tehtävien ratkaisun ja koodaamisen sankarien välillä on harmaa viiva, joka jättää seuraaville kehittäjille koodin, jota on vaikea ymmärtää ja jota on vaikea ylläpitää.

Niille meistä, jotka ovat koodanneet jonkin aikaa, muistamme Perlin yhden linjan käyttömukavuuden tai sisäkkäisten mallien käyttämisen C ++: ssa. Joskus on hyviä syitä käyttää näitä lähestymistapoja, mutta jos uusi kehittäjäryhmä ei ymmärrä näitä tekniikoita, koodin muuttaminen on haastavampaa. Joskus yksinkertaiset mutta vähemmän tyylikkäät koodaustavat ovat parempia.

Ajo ketteryyttä ketterässä ohjelmistokehityksessä

Rumpu ja ketterä kehitys, mukaan lukien sitoumukset, standups, sprintitarkastukset ja takautuvat, ovat nyt todistettuja käytäntöjä tiimin yhteistyön mahdollistamiseksi ja onnistuneen toteutuksen edistämiseksi. Mutta osoittamaan ketteryyttä pitkään, kehittäjien on otettava vastuut ja koodauskäytännöt, jotka mahdollistavat kehitetyn koodin pitkän aikavälin tuen ja laajennuksen.

Kehitystiimien on suhtauduttava kriittisesti koodauskäytäntöihinsä. Se ei ole vain tarpeeksi hyvä esittely ja julkaisu tänään; On myös tärkeää, että muut voivat helposti ylläpitää sovellusta ja koodia.

$config[zx-auto] not found$config[zx-overlay] not found