Kopioi-liitä ohjelmointi

Copy-paste ohjelmointi , C&P-ohjelmointi tai copy-paste ohjelmoinnissa  on prosessi, jossa luodaan ohjelmakoodia, jossa on usein toistuvia osia , jotka on tuotettu copy-paste- operaatioilla ( englanniksi  copy-paste ) [1] [2] . Termiä käytetään yleensä halventavassa merkityksessä tarkoittamaan riittämättömiä tietokoneohjelmointitaitoja tai ilmaisuvoimaisen kehitysympäristön puutetta, jossa plug-in-kirjastoja voidaan tyypillisesti käyttää.

Kopioi-liitä ohjelmointi on yleinen anti -malli , joka johtaa kahteen koodiin, joka on yleensä suuri ja vaikealukuinen. Toistuvat koodinpätkät levittävät alkuperäisessä koodissa tehtyä virhettä, ja useat toistot vaikeuttavat tämän virheen korjaamista kopioissa [1] [3] .

On tapauksia , jolloin ohjelmoinnin kopiointi ja liittäminen voi olla hyväksyttävää tai tarpeellista: mallit, silmukan purkaminen (kun kääntäjä ei tue automaattista tukea), ja myös käytettäessä joitain ohjelmointiparadigmoja tai lähdekoodin tuki editorien katkelmien muodossa .

Plagiointi

Copy-pastea käyttävät usein kokemattomat tai aloittelevat ohjelmoijat, joiden on vaikea kirjoittaa koodia tyhjästä ja jotka haluavat etsiä aiemmin kirjoitettuja ratkaisuja tai osittaisia ​​ratkaisuja, joita voidaan käyttää ongelmansa ratkaisun perustana [4] .

Ohjelmoijat, jotka kopioivat usein jonkun toisen koodia, eivät usein ymmärrä osaa tai kaikkea siitä. Sellaisenaan ongelma johtuu enemmän heidän kokemattomuudestaan ​​ja sinnikkyyden puutteesta kuin itse kopioinnista. Kopioitu koodi on usein otettu ystäviltä, ​​kollegoilta, Internet-foorumeilta , opettajilta tai ohjelmointikirjoilta . Tuloksena on riski, että se on hajanainen tyylijoukko ja voi sisältää ylimääräistä koodia, joka ratkaisee ongelmat, joita ei enää ole.

Copy-paste- ohjelmoinnin ja cargo-kulttiohjelmoinnin välillä on eroa . Ensimmäinen tyyppi ymmärretään enemmän itse ohjelmakoodin osien moninkertaistamisena [5] , toinen tyyppi voi tarkoittaa sekä koodin kopioimista ongelman ratkaisemiseksi, joka suoritetaan ohjelmasta tai ulkoisista lähteistä ja ymmärtämättä järjestelmää. koodista ja kopioida koodin osia ilman tarvetta [5] [ 6] .

Lisäongelmana on, että virheitä voidaan myös vain sisällyttää kopioituun koodiin. Eri lähdekoodeissa käytetyt suunnittelutekniikat eivät välttämättä ole hyväksyttäviä yhdistettyinä uuteen ympäristöön.

Tällainen koodi voi myös vahingossa hämärtyä , koska muuttujien, luokkien, funktioiden jne. nimet säilyvät kopioinnin jälkeen yleensä ennallaan, vaikka niiden tarkoitus olisi uudessa kontekstissa täysin erilainen [4] .

Monistus

Eräänä koodin monistamisen muotona C&P-ohjelmoinnissa on ongelmia, jotka pahenevat, jos koodi ei säilytä semanttista suhdetta alkuperäisen ja kopion välillä. Tässä tapauksessa, jos muutoksia tarvitaan, aikaa kuluu hukkaan kaikkien päällekkäisten osien etsimiseen. Tätä prosessia voidaan osittain nopeuttaa hyvin kommentoidulla koodilla, mutta se ei silti poista useiden muokkausten tarvetta. Koska koodin ylläpito jättää usein huomiotta kommenttien päivittämisen [7] , kommentit, jotka kuvaavat koodin päällekkäisten osien löytämistä, ovat tunnetusti vanhentuneita.

Eric Allen käyttää kirjassaan Common Design Mistakes termiä "false tiling" viittaamaan ohjelmiston kopioimisen aiheuttamiin virheisiin. Toistuvan fragmentin purkaminen menetelmäksi (pääasiallinen "resepti" tällaisten ongelmien ratkaisemiseksi) voi olla ei-triviaali tehtävä [8] .

Kirjastojen käyttäminen

Kopioi-liitä ohjelmointia käyttävät usein myös kokeneet ohjelmoijat, joilla on kirjastoja hyvin testattuja ja käyttövalmiita katkelmia ja yleisiä algoritmeja, jotka on räätälöity tiettyihin tehtäviin [2] .

Sen sijaan, että luotaisiin useita muokattuja kopioita yleisestä algoritmista, oliolähtöinen lähestymistapa ehdottaa algoritmin abstraktiota kapseloituun luokkaan, jota voidaan käyttää uudelleen. Tällainen luokka on luotu joustavalla tavalla, jossa on täysi tuki periytymiselle ja ylikuormitukselle , mikä mahdollistaa kutsuvan koodin vuorovaikutuksen yhden yleisen koodin kanssa usean tai usean muunnetun koodin sijaan [9] . Kun tarvittava toiminnallisuus laajenee, myös kirjaston koko kasvaa (säilyttää samalla yhteensopivuus taaksepäin ). Joten jos virhe korjataan alkuperäisessä algoritmissa, kaikki ohjelmistot, jotka käyttävät tätä algoritmia ja kirjastoa, voittaa.

Haaroittuminen

Haaroittuminen on normaali prosessi ohjelmistokehityksessä suurissa tiimeissä. Se mahdollistaa rinnakkaisen kehittämisen haaroissa ja lyhentää siten kehityssyklejä. Klassisella haarautumisella on seuraavat ominaisuudet:

Kopioi-liitä ohjelmointi on vähemmän muodollinen vaihtoehto klassiselle haaroittamiselle, jota käytetään usein, kun haarojen odotetaan poikkeavan (haarojen koodierot kasvavat) ajan myötä enemmän ja enemmän, kuten silloin, kun uusi ohjelmistotuote irrotetaan olemassa oleva.

Copy-paste-toiminnolla on joitain etuja tapana eristää uusi tuote. Koska uuden tuotteen kehittäminen ei muuta olemassa olevaa tuotetta:

Virheet:

Toinen vaihtoehto C&P-lähestymistavalle on modulaarinen lähestymistapa :

Toistuvat tehtävät tai tehtävämuunnelmat

Yksi haitallisimmista C&P-ohjelmoinnin muodoista on monistettu koodi , joka suorittaa toistuvan tehtävän tai muunnelman päätehtävästä riippuen jostain muuttujasta. Jokainen kopio kopioi aiemmin luodun kopion pienin muutoksin. Kutsutut tehosteet:

Tarkoitettu lähestymistapa

Kopioi liitä ohjelmointi on joskus hyväksytty normaali ohjelmointitekniikka. Voit yleensä nähdä tämän kaavoissa, kuten luokan, mukaan lukien vakiokirjastot, ilmoittaminen tai olemassa olevan koodimallin käyttäminen (tyhjällä sisällöllä tai tynkäfunktioilla ) täytön perustana.

Ohjelmointiidioomien ja suunnittelumallien käyttö on samanlaista kuin copy-paste-lähestymistapa, koska niissä käytetään myös yleiskoodia. Joissakin tapauksissa tämä voidaan ilmaista katkelmana , joka lisätään koodiin pyynnöstä, vaikka usein sitä yksinkertaisesti "kutsutaan" ohjelmoijan mielestä. Muissa tapauksissa idiomien käyttöä ei voida pelkistää yleiskoodiksi. Useimmissa tapauksissa kuitenkin, vaikka idiomi voidaan pelkistää koodiksi, se on joko liian pitkä (joka puretaan funktioksi) tai liian lyhyt (jotta se voidaan kirjoittaa suoraan).

Esimerkki

Yksinkertainen esimerkki lähestymistavan pätevästä sovelluksesta olisi for-silmukka, joka saattaa näyttää tältä . Esimerkki koodista, joka käyttää tällaista silmukkaa, olisi: for (int i=0; i!=n; ++i) {}

void foo ( int n ) { for ( int i = 0 ; i != n ; ++ i ) { } }

Silmukan koodi voidaan luoda seuraavalla katkelmalla (määrittää tyypit ja muuttujien nimet):

for ( $tyyppi $silmukan_muuttuja = 0 ; $silmukan_muuttuja != $stop ; ++ $silmukan_muuttuja ) { }

Monet ohjelmoijat käyttävät usein lähestymistapaa, koska he eivät halua kirjoittaa uudelleen riviä, joka eroaa edellisestä vain muutamalla merkillä (esimerkiksi kutsumalla samaa funktiota kahdelle samantyyppiselle objektille, joiden nimet eroavat hieman). Edellisen rivin kopioiminen (myös pikanäppäimillä) on nopeampaa kuin sen uudelleen kirjoittaminen. Mutta virheen tekemisen todennäköisyys ei pienene [14] , etenkään viimeisellä rivillä [15] .

Jos joudut tekemään useamman kuin yhden muokkauksen monistetulle riville, virheitä esiintyy useammin. Kuten esimerkistä näkyy, kirjoittaja korjasi kopioinnin jälkeen määritetyn arvon, mutta ei korjannut vasemmalla puolella olevaa taulukkoindeksiä:

mArray [ 12 ] = "a" ; mArray [ 13 ] = "b" ; mArray [ 14 ] = "c" ; mArray [ 14 ] = "d" ;

On olemassa tutkimus [16] , jonka tarkoituksena on "dekriminalisoida" copy-paste-ohjelmointi - Subtext-ohjelmointikieli . On huomattava, että tässä mallissa copy-paste on tärkein vuorovaikutusmalli, eikä sitä siksi pidetä anti-mallina.

Katso myös

Muistiinpanot

  1. 1 2 Kopioinnin ja liittämisen etnografinen tutkimus .
  2. 1 2 Kopioi ja liitä koodin seurantatyökalu .
  3. Tutkimus ohjelmistokloonien havaitsemisesta .
  4. 12 Aloittelijoiden ohjelmoijien virheiden uudelleenkäynti .
  5. 12 Antikuvioiden integrointi .
  6. Rahtikultit Javassa .
  7. ASP.NETin rakentaminen .
  8. Tyypillisiä suunnitteluvirheitä, 2003 .
  9. Olio-ohjelmoinnin periaatteet .
  10. Koodin uudelleenkäyttö OO-kehityksessä .
  11. Koodausstandardien edut .
  12. CS 106X .
  13. Täydellinen koodi, 2005 .
  14. Karpov, 2011 .
  15. Karpov, 2014 .
  16. Alateksti .

Kirjallisuus