“Kohandatud Magento arendus” on kirjas iga Magento-agentuuri avalehel, sealhulgas meie omal mingil hetkel. Tippige fraas Google’isse ja teile avaneb hulk peaaegu identseid teenustelehti: kangelaspilt, kolm punkti “kohandatud lahenduste” kohta ja kontaktivorm. Peaaegu ükski neist ei seleta, mida too too tegelikult kujutab.
See on probleem, kui just teie olete maksjaks. “Kohandatud” kasutatakse sünonüümina “kallis” või “eritellimus” ilma kunagi selle all olevat tehnoloogiat kirjeldamata. Nii et siin on versioon ilma turunduseta: mida kohandatud Magento arendus tegelikult tootena tahendab, milline see valjab oigesti versus valesti tehtuna, ja miks hinnasildi taga pole tegelikult sone “kohandatud”.
Mida fraas tehniliselt katab
Eemaldage turundustekst ja kohandatud Magento arendus on kindel, piiritletud hulk tehnilisi tegevusi:
- Kohandatud moodulid, mis lisavad ariloogikat, mida Magento vaikimisi ei paku – hinnareegel, mida teie valdkond vajab, valideerimissamm, mida teie vastavusmeeskond nouab, andmesünkroniseerimine, millele teie tegevusmeeskond tugineb.
- API integratsioonid, mis ühendavad Magento teiste süsteemidega, mis tegelikult äritegevust johtavad: ERP, PIM, tarnemaksumootorid, maksevahendajad, maksustamisteenused.
- Joudlusega seotud kohandamine – indekseerijate, vahemällu salvestamise strateegiate voi päringuteed ümberkirjutamine, mis katkevad teie konkreetse kataloogi suuruse voi liiklusmustri puhul.
- Makseprotsessi ja ostukorvi kohandamine – kohandatud sammud, kohandatud tarnelogika, kohandatud valideerimine, mida vaikimisi makseprotsess ei suuda väljendada.
- B2B-spetsiifiline loogika – ettevottekontod, lepingulised hinnad, kinnitustöovood, hankemistenimekirjad – millest ühtegi pole mõistlikult olemas standardses B2C-ülesehituses.
- Andmemigratsioonid süsteemide vahel – toote-, kliendi- ja tellimisandmete liigutamine Magento sisse voi välja ilma neid vaikselt rikkumata.
Igaüks neist on reaalne tehniline ülesanne oma ulatuse, kompromisside kogumi ning oige ja vale ehitusviisiga. Ükski neist ei ole “me teeme teie saidi eriliseks.” Kui agentuur ei suuda teile öelda, millisesse neist kuuest kategooriast teie projekt kuulub, pole nad seda veel ulatusse pannud – nad on selle lihtsalt hinnastanud.
Magento laiendamine ilma sellega voidlemata
See on osa, mis tegelikult eristab pädeva kohandatud Magento arenduse sellisest, mis kaheksateist kuud hiljem probleeme tekitab: kuidas kohandatud kood Magento tuumaga liitub.
Magento 2 arhitektuur annab teile mitu heakskiidetud viisi käitumise muutmiseks ilma ühtegi tuumafaili puutumata:
- Pluginad (interceptors) – before/after/around-meetodid, mis ümbritsevad avaliku klassi meetodi. Kas soovite muuta, mis juhtub, kui pakkumise kogusummad arvutatakse? Kirjutage plugin, ärge muutke totals collectori.
- Observers – ühenduge Magento sündmussüsteemiga (
sales_order_place_after, catalog_product_save_after ja sadu muud), et käivitada kohandatud loogika, kui midagi juhtub, ilma et tuumaklass teaks, et teie kood eksisteerib.
- Soltuvuse süstimine di.xml kaudu – asendage liidese rakendus oma omaga, nii et Magento kutsub teie klassi vaikimisi asemel, puhtalt objektihalduri eelistussüsteemi kaudu.
- Layout XML – lisage, eemaldage voi paigutage ümber eesliidese plokke (
<block>, <move>, <remove>, <referenceBlock>) ilma malle dubleerimata, mida pole vaja muuta.
- UI Components – eraldi deklaratiivne raamistik peamiselt Admin-raadustike/-vormide ja makseprotsessi lehe JS-paigutuse jaoks, laiendatav ilma kogu raadustiku- voi vormi definitsiooni kopeerimata.
Igaüks neist elab oma moodulis, app/code‘is voi nõuetekohase Composer-paketina, täielikult Magento tuumast eraldatavana. See on erinevus “kohandatud arenduse” ja “häkkimise” vahel.
Integratsioonid: ERP, PIM, tarne, makse
Siia läheb suurem osa kohandatud arenduse eelarvest küpses Magento poes, ja see on kategooria, millest üldised agentuuritekstid kõige vähem räägivad – tõenäoliselt seetottu, et see on kirjeldamiseks kõige vähem glamuurne.
- ERP integratsioon. SAP, NetSuite, Microsoft Dynamics voi tööstusspetsiifiline ERP peab jääma sünkroonis Magentoga varude, hindade ja tellimuse oleku osas – tavaliselt molemas suunas, äri jaoks olulisel ajakaval.
- PIM integratsioon. Akeneo, Pimcore voi sarnased süsteemid valdavad tooteandmeid; Magento peab neid tarbima, muutumata teiseks tõeallikaks, mis asjakohasusest kõrvale kaldub.
- Tarne. Reaalaegsed vedajatariifid, mitme vedajaga loogika, kohandatud tariifireeglid ülesuuruste voi ohtlike kaupade jaoks – ehitatud vedaja tegeliku API vastu, vigade käsitlusega.
- Makse. Kaugemal eelehitatud laienduse installimisest: kohandatud maksevood, jagatud maksed, tellimusarveldus, pettuselogika standardse lüüsi peal.
Miski sellest pole valikuline viimistlus. Kui teie ERP integratsioon vaikselt katkeb, müüte ületäite voi alltäite kaupu, kuni keegi seda märkab – mis on tavaliselt kliendikaebus, mitte monitoorimishoiatus.
Joudluspõhine kohandamine
Iga Magento pood jõuab lõpuks punkti, kus vaikekäitumine ei skaleeru selle konkreetse kujuga – mitte seetottu, et Magento on üldiselt aeglane, vaid seetottu, et teie kataloog, liiklusmuster voi kliendiandmed pole see, mille jaoks raamistiku vaikesätted on häälestatud.
- Kohandatud indekseerijad hinna- voi kataloogiloogika jaoks, mis on liiga spetsiifiline, et sisseehitatud indekseerija saaks seda teie toodete arvu juures tõhusalt käsitleda.
- Päringu optimeerimine kohandatud moodulites – erinevus aruande vahel, mis laadib kahe sekundiga, ja ühega, mis lukustab tabeli kolmekümneks sekundiks.
- Asünkroonne töötlemine sõnumijärjekordade kaudu (RabbitMQ) kõige jaoks, mis ei peaks päringut blokeerima – masstellimuste töötlemine, suured ekspordid, kolmanda osapoole API kutsed, mis aeg-ajalt hanguvad.
- Vahemällu salvestamist arvestav arendus – kohandatud plokkide ja moodulite kirjutamine nii, et need ei moodusta Varnish’i/täislehe vahemälu vaikset ümbersõitu.
Makseprotsess, ostukorv ja B2B-spetsiifiline loogika
Kaks kategooriat, mis praktikas pidevalt kattuvad:
- Makseprotsessi ja ostukorvi kohandamine – kohandatud tarnemeetodi valiku loogika, tingimuslikud väljad, jagatud saadetised, kingioptsioonid, tellimuse lisandmoodulid – kõik, mida vaikimisi makseprotsess ei suuda kastist väljas väljendada.
- B2B-loogika – ettevottekontod mitme ostja ja rolliga, jagatud kataloogid kontopõhiste lepinguliste hindadega, hinnapakkumise töovood, kinnitusahelad enne tellimuse esitamist, korduvostu hankemistenimekirjad. Adobe Commerce’i B2B-moodul katab kasuliku aluse; peaaegu igal reaalsel B2B-kauplejal on vaja midagi, mis on spetsiifiline selle kohta, kuidas nende müügimeeskond tegelikult tegutseb.
Andmemigratsioonid süsteemide vahel
Andmete migreerimine – Magento-sse, Magentost välja voi Magento ja satelliitsüsteemi vahel – on kohandatud arendus, mitte skript, mida üks kord käivitate. Tooteomadused ei kaardista platvormide vahel puhtalt. Tellimuste ajalool on äärjuhud (osalised tagasimaksed, jagatud saadetised, maksude ümberarvutused), mida naiivne eksport/import vaikselt moonutab.
Oigesti tehtuna sisaldab migratsioon valideerimist – arvestust, pistikproove, lepitusaruandeid – mitte ainult lõpetatud impordilogit. Valesti tehtuna avastate kolm kuud hiljem, et 2% ajaloolistest tellimustest kaotas oma reaüksuse maksuandmed, just siis, kui rahandus vajab seda aruande jaoks.
Valesti tehtud versus oigesti tehtud
Siin on osa, mis määrab, kas kohandatud Magento arendus on kahe aasta pärast vara voi kohustus:
- Tuuma häkkimine. Failide otse muutmine
vendor/magento/module-*‘is voi vanade stiiliga app/code alistamised, mis dubleerivad terveid tuumaklasse, et muuta üht meetodit. Igast composer update‘ist saab hasartmäng.
- Testikatte puudumine. Kohandatud hinnaloogika voi makseprotsessi muudatused ilma millegi kontrollimiseta, et need pärast soltuvuse tõuget ikka töötavad.
- Uuendamistee puudumine. Kohandused, mis on nii tihedalt seotud konkreetse Magento versiooniga, et uuendamine tahendab nende osalist ümberkirjutamist.
- Dokumenteerimata “ajutised” parandused, mis muutusid püsivaks, kuna keegi ei kirjutanud üles, miks need eksisteerisid.
Versus:
- Isoleeritud moodulid, mis kasutavad pluginaid, vaatlejaid ja soltuvuse süstimist – igaüht saab iseseisvalt keelata, testida voi asendada.
- Magento uuendamistee austamine – kohandused, mis üle elavad väikese versiooni tõuget, kuna nad ei puudutanud kunagi seda, mis neile ei kuulunud.
- Dokumenteeritud põhjendus – miks kohandatud loogika tükk eksisteerib, nii et järgmine arendaja saab hinnata, kas seda veel vaja on.
Miks “kohandatud” ei tahenda “põhjuseta kallis”
Reaalne kohandatud arendus – ülaltoodud kategooriad – nõuab tõelist tehnilist aega ja see aeg maksab raha olenemata sellest, kes seda teeb voi kus nad asuvad. Palju sellest, mida kauplejad paluvad “kohandatud arendusena”, on tegelikult lihtsalt konfiguratsioon – tarnereeglid, kliendigrupid ja kataloogihinnareeglid on olnud looduslik, koodita adminipaneeli säte juba Magento 1-st peale, mitte midagi, mis oleks kunagi arendajat vajanud.
Aus versioon: makske kohandatud arenduse eest siis, kui vajate loogikat, mida Magentol tõesti pole. Ärge makske arendushindade eest sätete eest, mida saate ise muuta, kui keegi teile näitab, kus need on.
Kus meie sobime
Me spetsialiseerume Magento 2-le – Hyva eesliidese arendus, joudluse optimeerimine, ülaltoodud integratsiooni- ja migratsioonitöö ning B2B-rakendused. Hooldame ka Magento 1 poode kauplejatele, kes pole veel migreerimisvalmis. Kui me kohandatud arendust ulatusse paneme, ütleme teile, milline osa on tõeliselt kohandatud ja milline on konfiguratsioon, mille eest te ei pea maksma – sest see on erinevus, mis tegelikult määrab, kas teie Magento pood on kolme aasta pärast hooldatav voi mitte.
Kui hindate kohandatud Magento arendusteenuseid ja soovite ulatust, mis eristab tõelist tehnilist töod täidetud tundidest, votke meiega ühendust.
