Arukate lepingute arendamine: kahe juhtiva raamistiku võrdlus

Kui alustasin arendustööd Solidity abil, loobusin peagi veebipõhistest IDE-dest ja võtsin oma uueks peamiseks raamistikuks kasutusele Hardhat. Mõne kuu pärast projektide ehitamist ja sellega seotud töövoo loomist tundsin end mugavalt selle võrgustiku ülesehituse, testimisstrateegia ja projektide korraldusega.

Kuid kui keegi ütles, et Foundry jõudlus on muljetavaldav, hakkasin ma piisavalt huvitatud, et teha korralik võrdlus kahe populaarsema nutikate lepingute arendamise raamistiku vahel.

Õiglase hinnangu andmiseks lõin mõlema abil samad projektid ja rakendasin sama MiniBank lepingut ning täiendavaid testiseadeid. See praktiline kogemus näitas, et nende kahe tööriista jõudlus, arendajate kogemus ja töövoog erinevad oluliselt ning seda tasub uurida igaühel, kes nende kahe vahel valib.

Esialgne kogemus nende seadistamisel on kahe raamistiku puhul üsna erinev. Foundry loob võtme-väärtuse paaridel põhineva konfiguratsioonifaili foundry.toml, mis on analoogne Hardhat hardhat.config.js failiga. Mõlemad toetavad ka allikakausta, kompileerimise väljundkataloogi jne kohandamist.

Foundry vaikimisi kaustastruktuur on küll üsna erinev, kuid konfiguratsioonifailis ei saa mitut võrku otse konfigureerida, kuna Hardhat teeb suurepärast tööd mitme võrgu haldamisel. Ülejäänud foundry.toml parameetrid on seotud testimisvalikutega, sealhulgas verbositeedi või konto seadete ja gaasi hinna valikutega.

Näiteks võite pikkade importimisteede kirjutamise asemel kirjutada lühikesi käsitsi kaardistusi, mis muudavad teie koodi loetavamaks ja hooldatavamaks.

Raamistikud erinevad oluliselt sõltuvuste haldamise viisilt:

• •Hardhat kasutab väljakujunenud npm ökosüsteemi, mis on JavaScripti arendajatele kohe kättesaadav
• •OpenZeppelin lepingute installimine on lihtsalt npm install käsk
• •Foundry tugineb Git-i alamooduli sõltuvuste haldamisele forge CLI-tööriista kaudu
• •Sõltuvused salvestatakse lib/ kausta ja lisatakse .gitmodules faili, mitte package.json faili.

See meetod võtab kõik GitHubi repositooriumid, mis sisaldavad sõltuvusena nutikaid lepinguid, ja võimaldab teil olla raamatukogude valikul paindlikum.

Võite määrata GitHubi organisatsiooni ja repositooriumi nime ning valikuliselt määrata installitava haru või sildi. Kui forge on installitud, saab forge remapping-käsku kasutada Foundry poolt kasutatavate vaikimisi importimisteede vaatamiseks, mida saab seejärel konfiguratsioonifailidega edasi kohandada.

Üks valdkondi, kus Hardhat silma paistab, on selle veaparandamise kogemus. Raamistik pakub vaikimisi ka console.log kasutamist, mis sarnaneb JavaScripti arenduses oodatava veaparandamise stiiliga. Seda funktsionaalsust reklaamitakse aktiivselt müügiargumendina ja arendajad saavad selle abil hõlpsasti jälgida, kuidas täitmine on toimunud ja mis on valesti.

Foundry vajab alternatiivset meetodit lepingute registreerimiseks. Kuigi on võimalik Hardhat käsitsi installida ja importida ning installida konsoolileping, oleks parim viis seda teha spetsiaalse konsoolilepingu kopeerimine oma projekti.

Eelkõige testifailide puhul sisaldab lisatud DSTest leping logimissündmusi, nagu logstring, logint ja logaddress, mida saab edastada ilma täiendavate sõltuvusteta.

Testikogemus on ehk kõige märkimisväärsem erinevus kahe raamistiku vahel.

Hardhat-testimise lähenemisviis

Hardhat põhineb standardse JavaScripti testimismudelitel:

• •Kasutab kirjeldusi ja it-blokke koos Mocha-ga vaikimisi kinnitusraamatukoguna
• •Testfailid võivad sarnaneda selle loomulikuma stiiliga, mida kasutavad veebiarenduse valdkonnas kogenud arendajad
• •Pakub kirjeldavaid testinimesid, mis selgelt väljendavad eesmärki
• •Tuttavad asünkroonsed mustrid
• •Õppekõver on minimaalne neile, kes on juba tuttavad kaasaegse veebiarendusega

Foundry testimise lähenemisviis

Foundry toimib täiesti teistmoodi:

• •Testid on välja töötatud Solidity nutikate lepingutena, mis pärivad DSTest
• •Kõik testid on funktsioonid, millele on eelnevalt lisatud sõna test või testFail
• •Kõik väited tehakse pärandatud DSTest lepingu kaudu
• •Testfailid on tõelised nutikad lepingud, mida kasutatakse testimisel

Foundry meetodil on mitmeid tagajärgi:

• •Testlepingud tuleb instantsida setUp() protseduuris, mis on analoogne JavaScripti klientide beforeEach-iga.
• •ETH lepingu meetodi saatmine hõlmab teatud süntaksit, mille väärtusparameetrid on sulgudes
• •Alguses järsk õppekõver võib olla kompenseeritud asjaoluga, et see ei nõua asünkroonsete operatsioonide käsitlemist

Foundry tutvustab kontseptsiooni, mida tuntakse nn cheat codes nime all ja mis pakub võimsaid testimisvahendeid. Need on spetsiaalsed funktsioonid määratud lepingu aadressil, mis võimaldavad teil testimise ajal juurdepääsu blockchaini seisundile.

Te võite:

• •Muuda praegust ploki numbrit
• •Ärge esindage teisi kontosid
• •Nõua teatud lepingulist käitumist

Cheat-koodide kasutamiseks peate määratlema liidese ja instantsieerima selle cheat-koodi spetsiaalsele aadressile kui seisundimuutuja. Pärast seadistamist on võimalik cheat-koode kasutada järgmiste funktsioonidega:

• •vm.prank(), et määrata järgmine lepingu kutse teisele vastuvõtjale
• •vm.roll(), et edasi liikuda plokiahelas teatud punktini

Raamistike vahel on märkimisväärne ja silmaga nähtav jõudluse erinevus. Samade lepingute ja teststsenaariumide puhul sain kompileerimise ja testide täitmise aja osas paljastavaid tulemusi:

Need jõudluse erinevused on märgatavamad, kui projekti keerukus suureneb.

Jõudluse eelised on vaieldamatud ja Solidity testi nimed ei saa olla sama kirjeldavad kui JavaScripti omad, mis võib muuta testi eesmärgi ebaselgeks. Cheat code süsteem on küll võimas, kuid selle õppimine nõuab alguses aega.

Deployment on üks valdkond, kus Hardhat pakub praegu paremat arendajakogemust. Raamistik aktsepteerib:

• •JavaScript-põhised rakenduskäsud
• •Ühendus mitmesuguste võrkudega
• •Laadige konfiguratsioon keskkonnamuutujate kaudu
• •Toime tulema keeruliste kasutuselevõtu olukordadega

JavaScript-põhised kasutuselevõtu skriptid on praegu Foundrys vajalikud, kuid need võivad olla tülikad, kui konstruktorid peavad oma argumendid esitama. Soovitatav lahendus on luua kasutuselevõtu bash-skriptid, et toime tulla kasutuselevõtu keerukusega, kuid arendusmeeskond on praegu arendamas veelgi täiustatud kasutuselevõtu lahendusi.

See on üks Foundry praeguseid tõsiseid nõrkusi võrreldes Hardhatiga, millel on arenenud kasutuselevõtu ökosüsteem.

Foundry pakub cast CLI-tööriista, mis võimaldab suhelda plokiahelaga ja teha päringuid nutikatele lepingutele. See on võimas utiliit, mis võimaldab teil:

• •Kutsuge lepingufunktsioone
• •Küsi blockchaini seisundit
• •Teostage mitmesuguseid blockchain-tegevusi käsurealt

Kuigi cast pakub täielikku funktsionaalsust suhtlemisel plokiahelaga, nõuab see keeruliste operatsioonide sooritamiseks keerulist käsurea ülesehitust. Sarnaselt kasutuselevõtuga võib see nõuda bash-skriptide kasutamist, et vältida pikkade käskude korduvat sisestamist.

Foundry näitab oma silmapaistva jõudluse, aktiivse kogukonna ja nutikate lepingute loomingulise testimise meetodiga suurt potentsiaali. Struktuur on suurepärane kiires arendusetsüklis ja sellel on suurepärased testimisvahendid, mis võivad arendust oluliselt kiirendada, kui nende kasutamine on selge.

Sellest hoolimata arendab Foundry end edasi, eriti rakenduste tööriistade ja arendajate kogemuse parandamise osas. Foundry pakub mõningaid huvitavaid eeliseid arendajatele, kes eelistavad hübriidmudelit, mis sisaldab:

• •Foundry lepingute väljatöötamiseks ja testimiseks
• •Hardhat rakendamiseks ja skriptideks

Kasutajad, kes on rohkem harjunud standardse JavaScripti tööriistade ja väljakujunenud kasutusviisidega, võivad nüüd Hardhatiga produktiivsemad olla, kuigi otsus sõltub taas teie taustast ja võimest võtta kasutusele uuemad tööriistad.