Stanislav Şaşalevici
A venit momentul în care proprietarii de afaceri nu trebuie să explice de ce au nevoie de un site web sau de un magazin online. Acum o absorb pe cont propriu în stadiul formării afacerii. Este timpul să explici clientului: ce CMS platforma este mai potrivită pentru afacerea lui? Și este mult mai greu de explicat acest lucru, atunci când clientul are deja un proiect pe platforma lui, atunci a-l convinge de necesitatea trecerii la o altă platformă este o sarcină foarte dificilă. Dar, în opinia noastră, cu platforma 1C-Bitrix această sarcină este mult mai ușor de rezolvat decât cu altele e-commerce platforme.
Prin urmare, vă invităm să luați în considerare 10 motive de ce trebuie să treci la 1C-Bitrix.
1. Integrare 1C
Aceasta este una dintre cele mai plăcute „bunătăți” ale platformei 1C-Bitrix. În 2007 Bitrix a înființat un joint venture cu "1C" – „1C-Bitrix”. În opinia noastră, acest fapt este cel care a dat dezvoltarea activă a acestei platforme. A venit o nouă eră când integrarea 1C s-a transformat dintr-o sarcină complexă într-o schemă clară de acțiuni simple.
Pe Internet, puteți găsi „povești de groază” în care integrarea în Bitrix este prezentată ca ceva complicat și costisitor. De fapt, astfel de „povești de groază” sunt inventate de cei care nu cunosc foarte bine toate nuanțele integrării și 1C în sine. Problemele de integrare pot apărea numai în următoarele cazuri:
- Șablonul site-ului a fost dezvoltat fără a înțelege caracteristicile Integrare 1C
- 1C în sine este deja bine tăiat
- Calificarea scăzută a dezvoltatorilor
Și, ca dovadă a nevinovăției noastre, oferim un tutorial video în care experții noștri arată cum se face integrare cu1CDoar pentru30 minute. Și fără trucuri. Doar fapte!
2. Integrare CRM
În cazul în care un 1C-integrare nu mai surprinde pe nimeni și aceasta este o funcționalitate obligatorie pentru oricare e-commerce sisteme, atunci Integrare CRM tocmai ia amploare. Dar și aici Bitrixîncercând să fie înaintea tuturor.
In cutie 1C-Bitrix există deja o funcționalitate standard pentru sincronizarea datelor cu CRM Bitrix24. Acest lucru permite echipei de vânzări să lucreze mai eficient cu clienți potențiali, oferte și contacte noi. Imediat din cutie, primești un instrument de vânzare gata făcut.
Un subiect foarte de actualitate in acest moment, care, de altfel, este principalul argument pentru transferarea proiectului catre Bitrix deja în 2017.
DIN 1 februarie 2017 al anului echipamente de casa de marcat ar trebui să trimită versiuni electronice verificări către operatorul de date fiscale - noile reguli sunt stabilite în 54-FZ, articolul 2, paragraful 2.
Legea va intra în vigoare 1 iulie 2017. Fiecare magazin online trebuie să aibă casa de marcat(KKT), conectat la Internet și conectat la operatorul de date fiscale (OFD).
Ce inseamna asta? În cazul în care un in termeni simpli, apoi cu 1 iulie 2017 ani pentru fiecare comandă plătită online (nu în raport cu o factură) prin intermediul magazinului dvs. online, trebuie să eliminați Verificare KKM, adăugați-l la baza de date a site-ului, trimiteți-l la în format electronic cumpărătorului, și chiar o mulțime de date pentru a furniza imediat biroului fiscal. Și toate acestea iau tot 5 minute altfel vei fi amendat.
Cum îți place această problemă? În opinia noastră, este foarte netrivial. Ce ne place Bitrix este că răspunde prompt la toate schimbările pieței. El nu se oprește asupra idealizării produsului său, ci pur și simplu măsoară pulsul tuturor componentelor e-commerceși răspunde instantaneu.
Aici și aici 1C-Bitrix a răspuns prompt și a implementat imediat funcționalitate care satisface toate cerințele 54-FZ. Din câte știm, în acest moment Bitrix testează link-ul de pe propriul site: magazin online - casă de marcat - autorități fiscale. Prin urmare, să 1 iulie vom fi complet înarmați cu Bitrix.
Credem că acesta este un argument foarte serios pentru transferul proiectului pe platformă 1C-Bitrix exact la 2017- deplină concordanță 54-FZ. Credem că în acest sens vor fi probleme pentru mulți plătiți e-commerce platforme, ca să nu mai vorbim de cele gratuite. Proprietarul de afaceri va trebui pur și simplu să acorde atenție 1C-Bitrix pentru a închide problema în siguranță 54-FZ.
4. Instrumente de marketing
Cu toții am auzit despre abilitățile de marketing. 1C-Bitrix. Cineva, invidios în liniște, spune că aceasta este componenta principală a succesului acestei companii. Dar să nu invidiem, ci doar să învățăm din experiență Bitrix. Din fericire, compania însăși 1C-Bitrixîmpărtășește cu plăcere toate instrumentele sale direct în platforma în sine.
Acum vă vom spune despre cele mai interesante, așa cum ni se pare, instrumente de marketing, care va adăuga puncte în favoarea luării unei decizii de transfer al proiectului către Bitrix:
- marketing prin e-mail. Vă va permite să lucrați cu clienții în modul automat prin lista de e-mail-uri. Scripturile deja pregătite pentru lanțuri de e-mailuri de declanșare motivează clientul să revină pe site și să plaseze noi comenzi.
- Marketingul mărfurilor. Motivarea clienților cu promoții și reduceri a avut întotdeauna un efect pozitiv. Iar Bitrix oferă opțiuni de configurare flexibile pentru a putea influența fiecare grup de utilizatori.
5. Instrumente SEO
SEO- a fost, este si va fi un instrument important pentru atragerea traficului pe site. Noi, ca dezvoltatori ai noștri SEO soluții, acordăm o atenție deosebită acestui lucru.Din pacate pana in 2013 SEO componenta platformei 1C-Bitrix era foarte subdezvoltat. Nu a fost posibil să se genereze în mod flexibil meta-etichete obișnuite, cu atât mai puțin sarcini mai complexe. Dar din versiunea 14 Bitrix totul s-a schimbat. Acum SEO instrumentele platformei includ:
- Șabloane metaetichete
- Generare inteligentă de hărți de site
- Generația Robots.txt
- Trimiterea text unic către Yandex
- Și mult mai mult
Date mare- acum nu este doar la modă, ci și necesar. Cumpărătorul nu va mai aprecia doar o ofertă de cumpărare a mărfurilor dintr-un magazin online. Cumpărătorul va aprecia dacă magazinul oferă exact ceea ce are nevoie. Pentru asta sunt aceste servicii.
Companie Bitrixși a reacționat prompt în această direcție și și-a lansat propriul serviciu cloud „1C-Bitrix BigData”. Acest lucru vă permite să faceți oferte personale clientului, adică prin analizarea acțiunilor sale comportamentale în funcție de anumiți algoritmi, pentru a oferi bunurile de care are nevoie. Retragerea bunurilor personale poate avea loc atât în partea publică a site-ului, cât și în listele de corespondență.
Vă rugăm să rețineți că un serviciu similar de la Bitrix nu numai că vă va crește vânzările, dar va avea și un efect pozitiv asupra creșterii loialității față de magazinul dvs. online.
7. Rețea de afiliați
Rețeaua de afiliați este ceea ce o face să crească 1C-Bitrix. Acum există peste 13.000 de parteneri în rețea. Și în fiecare zi sunt din ce în ce mai mulți.
Ce oferă o rețea atât de extinsă unei afaceri?
În primul rând, aveți posibilitatea de a selecta un dezvoltator în funcție de următorii parametri:
- Bugetul proiectului
- Calificarea și expertiza dezvoltatorului
- Regionalitatea
În ceea ce privește alegerea unui partener direct, în opinia noastră, aceasta este etapa cea mai importantă și responsabilă. Depinde de el cum va ieși proiectul tău. Bitrix, desigur, încearcă să filtreze cumva și să găsească dezvoltatori potriviți pentru tine, dar, după cum credem, până acum acest lucru nu a funcționat întotdeauna bine. Același statut „Partener de aur” nu oferă nicio garanție proiectului dumneavoastră. Până la urmă, după cum credem noi, pragul de intrare pentru obținerea acestui statut este prea scăzut și ar merita să-l ridicăm.
Deși acesta nu este subiectul articolului actual, totuși, pe baza celor de mai sus, vă putem oferi câteva recomandări:
- Cazuri de parteneri. Familiarizați-vă cu atenție cu proiectele pe care dezvoltatorul le-a implementat deja, similare ca temă cu ale dvs. Pune întrebări clarificatoare despre cazuri. Nu fi timid.
- Expertiză. Asigurați-vă că verificați calificările partenerului. Testarea începe cu prima atingere. Cu întrebări clarificatoare competente, partenerul vă va dezvălui proiectul, iar cu răspunsurile sale convingătoare la întrebări, vă va sparge toate îndoielile.
8. Platforma de comerț electronic #1
În mod paradoxal, acesta este cel mai simplu și mai important argument în favoarea trecerii la Bitrix.
Din grafic, se poate observa că aproximativ 60% din piata comercial CMS acum ocupat de companie 1C-Bitrix. Și este puțin probabil ca 6 din 10 să greșească. Ei și-au făcut alegerea analizând cu atenție toate avantajele și dezavantajele produsului. Acum este mult mai ușor pentru tine să iei decizia corectă urmându-le exemplul.
as vrea sa imi doresc Bitrix ca să nu se oprească aici și să încerce nu doar să mențină cota de piață actuală, ci și să o crească. Și există loc de creștere: 40% din piața comercială CMS + sisteme libere. 1C-Bitrix pur și simplu obligat să creezi astfel de condiții și o astfel de platformă la care vrei doar să treci.
9. 1C-Bitrix.Marketplace
Am decis să păstrăm ce e mai bun pentru mai târziu. Crearea propriei platforme de vânzări Piata de desfacereîn 2011 deschis înainte 1C-Bitrix noi oportunitati. La urma urmei, datorită acestui pas, popularizarea Bitrix a crescut atât în rândul dezvoltatorilor, cât și direct în rândul participanților la vânzări online. Și există mai multe motive pentru aceasta:
- Soluții tipice - Pornirea rapidă a vânzărilor. După lansare 1 DIN-Piata Bitrix a existat un boom mare în soluțiile șablon standard. Datorită acestui fapt, clienții chiar au lansat magazine online de la câteva zile la săptămâni, în loc de multe luni și proiecte scumpe de la zero. Acest lucru le-a permis să câștige rapid experiență în vânzările online și să aibă o atitudine mai conștientă și mai profesionistă față de dezvoltarea proiectului lor.
- Creșterea funcționalității 1C-Bitrix. Acum ce nu poate face el însuși Bitrix sunt realizate de partenerii săi. Acest lucru extinde posibilitățile platformei și le face aproape nelimitate.
- Creșterea calificărilor dezvoltatorilor.Site-ul a deschis noi oportunități direct pentru artiști. Astfel, a contribuit la creșterea calificării specialiștilor tehnici în dezvoltarea de soluții pentru 1C-Bitrix.
10. Dezvoltare și actualizări constante
Așa cum sa menționat mai sus, 1C-Bitrix monitorizează cu atenție toate tendințele și schimbările e-commerce piaţă. Obțineți nu doar un produs care este relevant doar pentru astăzi, așa cum se întâmplă cu auto-scris CMS– obțineți o platformă în continuă evoluție.
Când primești un an de actualizări gratuite. Aceasta înseamnă că în acest timp proiectul tău va fi mereu la zi. Iar daca achizitionezi produse 1C-Bitrix prin noi, atunci primesti si bonusuri in valoare de 20% din suma comenzii, pe care le poti cheltui pentru achizitionarea modulelor noastre.
Aș dori să remarc faptul că Bitrix există o anumită regulă, care este deja pentru mult timp nu este întrerupt: două lansări de actualizări globale pe an. Aceasta înseamnă că datele și termenele specifice pentru implementarea acestor actualizări sunt deja stabilite în avans. La datele stabilite, se realizează prezentarea eliberării și imediat după aceea, implementarea sistematică a acesteia. Acest model de lucru este foarte eficient. Motivează departamentul de dezvoltare să scape de idealizarea codului și ajută la livrarea rapidă a rezultatelor direct proprietarului magazinului online.
Aici, se pare, ne putem opri. Total 10 motive dar toate motivele Bitrix„a suferit”. Fiecare motiv a trecut testul timpului, experimente eșuate, ipoteze eșuate. Noi sperăm asta 1C-Bitrix ne va oferi noi motive să lucrăm pe această platformă specială.
În tot timpul pe care am lucrat cu Bitrix, am avut șansa de a lucra cu un număr foarte mare de proiecte pe care cineva le-a dezvoltat înaintea mea. Iată îmbunătățiri minore, remedierea diferitelor erori și erori în funcționarea logicii, reproiectarea site-ului și modificări globale ale funcționalității existente. Și, ca orice alt dezvoltator, urăsc să aranjez gunoiul altor oameni, cârjele și patch-urile „temporare” care amintesc de fapt de ediția a 8-a a produsului.
Aici voi încerca să nu mă concentrez pe „cele mai proaste practici” standard atunci când programez în PHP, cum ar fi să nu dau doi bani pe alegerea numelor de variabile și funcții, interogări inutile la baza de date într-o buclă, lipsa validării datelor utilizatorului în formulare, ignorarea comentariilor și altele asemenea. Voi încerca să ating exact momentele inerente dezvoltării pe Bitrix, care ulterior vă vor permite să evitați indignarea și înjurăturile împotriva voastră din partea programatorului care trebuia să vă însoțească codul. Și da, de multe ori tu însuți te vei dovedi a fi acest programator într-un an sau mai mult, când ai uitat complet de ce ai introdus cutare sau cutare cârjă aici.
„Scrie codul ca și cum ar fi însoțit de un psihopat violent care știe unde locuiești” (c) John F. Woods
În primul rând, și cel mai mult, după părerea mea, cel mai important - pentru numele lui Dumnezeu, utilizați folderul local. Acest lucru este pur și simplu vital atunci când utilizați sistemul de control al versiunilor - tot ce aveți nevoie este să adăugați folderul /bitrix/ la excluderi. Tot. În plus, aproape toată dezvoltarea se realizează numai în ea. Acest lucru simplifică foarte mult căutarea fișierelor și componentelor necesare mai târziu, ajută să nu înfundați depozitul cu fișiere inutile și, în general, aduce arborele proiectului într-un aspect mai ordonat, „uman”.
Nu modificați nucleul. Chiar dacă ești sigur că nu va fi actualizat. Chiar dacă este mai rapid. Chiar dacă ești leneș. Uită acest gând, ca un vis urât. Dacă trebuie să schimbați logica unei componente standard, mutați-o într-un nou spațiu de nume /local/components/modify/ și lucrați cu ea. Același lucru este valabil și pentru module, gadgeturi și activități de proces de afaceri.
Nu poluați fișierul init.php. Combinați funcțiile pentru a lucra cu un anumit modul sau funcționalitate într-o clasă, scrieți această clasă întreagă într-un fișier separat și în init.php includeți doar aceste fișiere și scrieți handlere de evenimente. Am văzut fișiere init.php de 500 Kb fiecare, în care funcțiile, definițiile constante, clasele și inițializarea handlerelor au fost amestecate într-o mizerie. Desigur, când a trebuit să mă ocup de aceste fișiere, mi-am înjurat predecesorii.
Următorul punct nu se aplică cazului de dezvoltare soluții gata făcute pentru Piață, când scopul este de a realiza cea mai personalizabilă funcționalitate din partea publică pentru utilizatorul final. Dacă lucrați la un anumit proiect, pentru un anumit TOR - nu ar trebui să încercați să faceți un șablon unificat pentru o componentă pentru toate ocaziile. Personal, aderă la filozofie - este mai bine să aveți mai multe șabloane simple folosite în scopuri diferite decât unul universal, dar în care diavolul însuși își va rupe piciorul mai târziu. Desigur, în fiecare caz specific, trebuie să construiți pe ceea ce este - termenii de referință, opțiunile de implementare și altele asemenea, dar unii folosesc Razorul lui Occam cu prea zel. Ca exemplu, voi da un proiect al unei companii de leasing pe care s-a întâmplat să îl editez. Proiectul în sine, desigur, a fost implementat teribil, adevărata groază a fost în paginile secțiunii de catalog de servicii. Fiecare dintre cele cinci secțiuni avea propriul aspect, care diferea atât prin poziția blocurilor pe pagină, cât și, în principiu, prin prezența unora dintre ele. Și pentru toate cele cinci pagini, un șablon a fost folosit cu o grămadă de apeluri if-else, duplicarea apelurilor componente, stiluri de conectare și scripturi, care, în plus, intrau periodic în conflict unele cu altele. Drept urmare, un dosar imens, în care era ca moartea să înțelegi „fără jumătate de litru”. Deși, s-ar părea, ce te-a împiedicat să faci 5 șabloane diferite și să nu creezi dificultăți din senin?
Utilizați API-ul. Nu reinventați roata acolo unde nu este nevoie. Utilizați documentația - întregul produs este destul de bine descris, precum și fiecare funcție poate fi vizualizată în detaliu pe bxapi.ru.
Evitați interogările directe ale bazei de date. aceasta caz special paragraful anterior - utilizați API-ul. Solicitările brutale, nesecurizate pot duce la coruperea, pierderea sau chiar compromisul datelor.
Nu utilizați componente CNC de la rădăcina site-ului. Consecințele sunt de obicei destul de nefericite, deoarece CNC folosește un fișier de gestionare a adresei, încercarea de a-l folosi de la rădăcină vă rupe cu ușurință adresarea altor componente, precum și 404 pagini. Nu va strica nimic dacă articolele dvs. sunt adresate în raport cu folderul /articole/ și produsele legate de /catalog/.
Includeți css și js folosind API-ul. Până acum, peste tot întâlnesc legătura de scripturi și stiluri folosind tag-uri
În tot timpul pe care am lucrat cu Bitrix, am avut șansa de a lucra cu un număr foarte mare de proiecte pe care cineva le-a dezvoltat înaintea mea. Iată îmbunătățiri minore, remedierea diferitelor erori și erori în funcționarea logicii, reproiectarea site-ului și modificări globale ale funcționalității existente. Și, ca orice alt dezvoltator, urăsc să aranjez gunoiul altor oameni, cârjele și patch-urile „temporare” care amintesc de fapt de ediția a 8-a a produsului.
Aici voi încerca să nu mă concentrez pe „cele mai proaste practici” standard atunci când programez în PHP, cum ar fi să nu dau doi bani pe alegerea numelor de variabile și funcții, interogări inutile la baza de date într-o buclă, lipsa validării datelor utilizatorului în formulare, ignorarea comentariilor și altele asemenea. Voi încerca să ating exact momentele inerente dezvoltării pe Bitrix, care ulterior vă vor permite să evitați indignarea și înjurăturile împotriva voastră din partea programatorului care trebuia să vă însoțească codul. Și da, de multe ori tu însuți te vei dovedi a fi acest programator într-un an sau mai mult, când ai uitat complet de ce ai introdus cutare sau cutare cârjă aici.
„Scrie codul ca și cum ar fi însoțit de un psihopat violent care știe unde locuiești” (c) John F. WoodsÎn primul rând, și cel mai mult, după părerea mea, cel mai important - pentru numele lui Dumnezeu, utilizați folderul local. Acest lucru este pur și simplu vital atunci când utilizați sistemul de control al versiunilor - tot ce aveți nevoie este să adăugați folderul /bitrix/ la excluderi. Tot. În plus, aproape toată dezvoltarea se realizează numai în ea. Acest lucru simplifică foarte mult căutarea fișierelor și componentelor necesare mai târziu, ajută să nu înfundați depozitul cu fișiere inutile și, în general, aduce arborele proiectului într-un aspect mai ordonat, „uman”.
Nu modificați nucleul. Chiar dacă ești sigur că nu va fi actualizat. Chiar dacă este mai rapid. Chiar dacă ești leneș. Uită acest gând, ca un vis urât. Dacă trebuie să schimbați logica unei componente standard, mutați-o într-un nou spațiu de nume /local/components/modify/ și lucrați cu ea. Același lucru este valabil și pentru module, gadgeturi și activități de proces de afaceri.
Nu poluați fișierul init.php. Combinați funcțiile pentru a lucra cu un anumit modul sau funcționalitate într-o clasă, scrieți această clasă întreagă într-un fișier separat și în init.php includeți doar aceste fișiere și scrieți handlere de evenimente. Am văzut fișiere init.php de 500 Kb fiecare, în care funcțiile, definițiile constante, clasele și inițializarea handlerelor au fost amestecate într-o mizerie. Desigur, când a trebuit să mă ocup de aceste fișiere, mi-am înjurat predecesorii.
Următorul paragraf nu se aplică în cazul dezvoltării de soluții gata făcute pentru Piață, când scopul este de a realiza cea mai personalizabilă funcționalitate din partea publică pentru utilizatorul final. Dacă lucrați la un anumit proiect, pentru un anumit TOR - nu ar trebui să încercați să faceți un șablon unificat pentru o componentă pentru toate ocaziile. Personal, aderă la filozofie - este mai bine să aveți mai multe șabloane simple folosite în scopuri diferite decât unul universal, dar în care diavolul însuși își va rupe piciorul mai târziu. Desigur, în fiecare caz specific, trebuie să vă bazați pe ceea ce este - termenii de referință, opțiunile de implementare și altele asemenea, dar tot nu ar trebui să uitați de Occam's Razor. Ca exemplu, voi da un proiect al unei companii de leasing pe care s-a întâmplat să îl editez. Proiectul în sine, desigur, a fost implementat teribil, adevărata groază a fost în paginile secțiunii de catalog de servicii. Fiecare dintre cele cinci secțiuni avea propriul aspect, care diferea atât prin poziția blocurilor pe pagină, cât și, în principiu, prin prezența unora dintre ele. Și pentru toate cele cinci pagini, a fost folosit un șablon cu o grămadă de apeluri de tip if-else, duplicarea apelurilor componente, stiluri de conectare și scripturi, care, în plus, intrau periodic în conflict unele cu altele. Drept urmare, un dosar imens, în care era ca moartea să înțelegi „fără jumătate de litru”. Deși, s-ar părea, ce te-a împiedicat să faci 5 șabloane diferite și să nu creezi dificultăți din senin?
Utilizați API-ul. Nu reinventați roata acolo unde nu este nevoie. Utilizați documentația - întregul produs este destul de bine descris, precum și fiecare funcție poate fi vizualizată în detaliu pe bxapi.ru.
Evitați interogările directe ale bazei de date. Acesta este un caz special al punctului anterior - utilizați API-ul. Solicitările brutale, nesecurizate pot duce la coruperea, pierderea sau chiar compromisul datelor.
Nu utilizați componente CNC de la rădăcina site-ului. Consecințele sunt de obicei destul de nefericite, deoarece CNC folosește un fișier de gestionare a adresei, încercarea de a-l folosi de la rădăcină vă rupe cu ușurință adresarea altor componente, precum și 404 pagini. Nu va strica nimic dacă articolele dvs. sunt adresate în raport cu folderul /articole/ și produsele legate de /catalog/.
Includeți css și js folosind API-ul. Până acum, peste tot întâlnesc legătura de scripturi și stiluri folosind etichete html. Utilizați obiectul clasei \Bitrix\Main\Page\Asset și funcțiile addJs() și addCss(). Acest lucru vă va permite să îmbinați fișiere și, ulterior, să le memorați în cache cu un singur clic al casetei de selectare din setările modulului principal
Și, în sfârșit, eroarea se referă nu numai la Bitrix, dar prea des am început să întâmpin probleme asociate cu aceasta. Verificați matricea goală cu rezultatele eșantionului. De exemplu, ultima dată când am întâlnit această problemă a fost când lucram cu un magazin online. Reclamație: Paginile durează uneori 16 secunde pentru a se încărca. Cu ce este conectat - nu este clar. Prin încercare și eroare, am aflat că paginile se încarcă indecent mult timp doar când coșul este gol. Părea de ce? După cum s-a dovedit, la trecerea cu mouse-ul peste coș, a apărut o fereastră pop-up în care erau afișate imagini cu produsul pus în coș. Deci, ce a făcut dezvoltatorul anterior? Am luat rezultatul muncii componentei „coș mic” și în fișierul result_modifier.php am făcut un apel la GetList() de produse pentru a selecta imagini cu un filtru din matricea de ID-uri de produs, apoi am adăugat src-ul imaginii de la rezultatele selecției până la matricea produsului corespunzător. Ca urmare, atunci când nu existau mărfuri în coș, filtrul s-a golit, iar TOTUL catalog de mărfuri a intrat în selecție. Ei bine, atunci ciclul pentru fiecare și... avem ceea ce avem. Este clar că în stadiul de dezvoltare, cu 15 produse de testare, acest lucru era insesizabil, iar probleme au apărut deja în condiții de luptă. Deși, s-ar părea că a meritat să verificați golul ($arResult[‘ITEMS’])…
Aceasta încheie topul meu personal cu „cele mai proaste practici” în ceea ce privește dezvoltarea Bitrix. Dacă măcar pe cineva această informație ajută să evite greșelile în viitor și să-și îmbunătățească stilul de dezvoltare, atunci nu a fost în zadar.
Puteți ajuta și transfera niște fonduri pentru dezvoltarea site-ului
În tot timpul pe care am lucrat cu Bitrix, am avut șansa de a lucra cu un număr foarte mare de proiecte pe care cineva le-a dezvoltat înaintea mea. Iată îmbunătățiri minore, remedierea diferitelor erori și erori în funcționarea logicii, reproiectarea site-ului și modificări globale ale funcționalității existente. Și, ca orice alt dezvoltator, urăsc să aranjez gunoiul altor oameni, cârjele și patch-urile „temporare” care amintesc de fapt de ediția a 8-a a produsului.
Aici voi încerca să nu mă concentrez pe „cele mai proaste practici” standard atunci când programez în PHP, cum ar fi să nu dau doi bani pe alegerea numelor de variabile și funcții, interogări inutile la baza de date într-o buclă, lipsa validării datelor utilizatorului în formulare, ignorarea comentariilor și altele asemenea. Voi încerca să ating exact momentele inerente dezvoltării pe Bitrix, care ulterior vă vor permite să evitați indignarea și înjurăturile împotriva voastră din partea programatorului care trebuia să vă însoțească codul. Și da, de multe ori tu însuți te vei dovedi a fi acest programator într-un an sau mai mult, când ai uitat complet de ce ai introdus cutare sau cutare cârjă aici.
„Scrie codul ca și cum ar fi însoțit de un psihopat violent care știe unde locuiești” (c) John F. Woods
În primul rând, și cel mai mult, după părerea mea, cel mai important - pentru numele lui Dumnezeu, utilizați folderul local. Acest lucru este pur și simplu vital atunci când utilizați sistemul de control al versiunilor - tot ce aveți nevoie este să adăugați folderul /bitrix/ la excluderi. Tot. În plus, aproape toată dezvoltarea se realizează numai în ea. Acest lucru simplifică foarte mult căutarea fișierelor și componentelor necesare mai târziu, ajută să nu înfundați depozitul cu fișiere inutile și, în general, aduce arborele proiectului într-un aspect mai ordonat, „uman”.
Nu modificați nucleul. Chiar dacă ești sigur că nu va fi actualizat. Chiar dacă este mai rapid. Chiar dacă ești leneș. Uită acest gând, ca un vis urât. Dacă trebuie să schimbați logica unei componente standard, mutați-o într-un nou spațiu de nume /local/components/modify/ și lucrați cu ea. Același lucru este valabil și pentru module, gadgeturi și activități de proces de afaceri.
Nu poluați fișierul init.php. Combinați funcțiile pentru a lucra cu un anumit modul sau funcționalitate într-o clasă, scrieți această clasă întreagă într-un fișier separat și în init.php includeți doar aceste fișiere și scrieți handlere de evenimente. Am văzut fișiere init.php de 500 Kb fiecare, în care funcțiile, definițiile constante, clasele și inițializarea handlerelor au fost amestecate într-o mizerie. Desigur, când a trebuit să mă ocup de aceste fișiere, mi-am înjurat predecesorii.
Următorul paragraf nu se aplică în cazul dezvoltării de soluții gata făcute pentru Piață, când scopul este de a realiza cea mai personalizabilă funcționalitate din partea publică pentru utilizatorul final. Dacă lucrați la un anumit proiect, pentru un anumit TOR - nu ar trebui să încercați să faceți un șablon unificat pentru o componentă pentru toate ocaziile. Personal, aderă la filozofie - este mai bine să aveți mai multe șabloane simple folosite în scopuri diferite decât unul universal, dar în care diavolul însuși își va rupe piciorul mai târziu. Desigur, în fiecare caz specific, trebuie să vă bazați pe ceea ce este - termenii de referință, opțiunile de implementare și altele asemenea, dar tot nu ar trebui să uitați de Occam's Razor. Ca exemplu, voi da un proiect al unei companii de leasing pe care s-a întâmplat să îl editez. Proiectul în sine, desigur, a fost implementat teribil, adevărata groază a fost în paginile secțiunii de catalog de servicii. Fiecare dintre cele cinci secțiuni avea propriul aspect, care diferea atât prin poziția blocurilor pe pagină, cât și, în principiu, prin prezența unora dintre ele. Și pentru toate cele cinci pagini, a fost folosit un șablon cu o grămadă de apeluri de tip if-else, duplicarea apelurilor componente, stiluri de conectare și scripturi, care, în plus, intrau periodic în conflict unele cu altele. Drept urmare, un dosar imens, în care era ca moartea să înțelegi „fără jumătate de litru”. Deși, s-ar părea, ce te-a împiedicat să faci 5 șabloane diferite și să nu creezi dificultăți din senin?
Utilizați API-ul. Nu reinventați roata acolo unde nu este nevoie. Utilizați documentația - întregul produs este destul de bine descris, precum și fiecare funcție poate fi vizualizată în detaliu pe bxapi.ru.
Evitați interogările directe ale bazei de date. Acesta este un caz special al punctului anterior - utilizați API-ul. Solicitările brutale, nesecurizate pot duce la coruperea, pierderea sau chiar compromisul datelor.
Nu utilizați componente CNC de la rădăcina site-ului. Consecințele sunt de obicei destul de nefericite, deoarece CNC folosește un fișier de gestionare a adresei, încercarea de a-l folosi de la rădăcină vă rupe cu ușurință adresarea altor componente, precum și 404 pagini. Nu va strica nimic dacă articolele dvs. sunt adresate în raport cu folderul /articole/ și produsele legate de /catalog/.
Includeți css și js folosind API-ul. Până acum, peste tot întâlnesc legătura de scripturi și stiluri folosind etichete html. Utilizați obiectul clasei \Bitrix\Main\Page\Asset și funcțiile addJs() și addCss(). Acest lucru vă va permite să îmbinați fișiere și, ulterior, să le memorați în cache cu un singur clic al casetei de selectare din setările modulului principal
Și, în sfârșit, eroarea se referă nu numai la Bitrix, dar prea des am început să întâmpin probleme asociate cu aceasta. Verificați matricea goală cu rezultatele eșantionului. De exemplu, ultima dată când am întâlnit această problemă a fost când lucram cu un magazin online. Reclamație: Paginile durează uneori 16 secunde pentru a se încărca. Cu ce este conectat - nu este clar. Prin încercare și eroare, am aflat că paginile se încarcă indecent mult timp doar când coșul este gol. Părea de ce? După cum s-a dovedit, la trecerea cu mouse-ul peste coș, a apărut o fereastră pop-up în care erau afișate imagini cu produsul pus în coș. Deci, ce a făcut dezvoltatorul anterior? Am luat rezultatul muncii componentei „coș mic” și în fișierul result_modifier.php am făcut un apel la GetList() de produse pentru a selecta imagini cu un filtru din matricea de ID-uri de produs, apoi am adăugat src-ul imaginii de la rezultatele selecției până la matricea produsului corespunzător. Ca urmare, atunci când nu existau mărfuri în coș, filtrul s-a golit, iar TOTUL catalog de mărfuri a intrat în selecție. Ei bine, atunci ciclul pentru fiecare și... avem ceea ce avem. Este clar că în stadiul de dezvoltare, cu 15 produse de testare, acest lucru era insesizabil, iar probleme au apărut deja în condiții de luptă. Deși, s-ar părea că a meritat să verificați golul ($arResult[‘ITEMS’])…
Aceasta încheie topul meu personal cu „cele mai proaste practici” în ceea ce privește dezvoltarea Bitrix. Dacă măcar pe cineva această informație ajută să evite greșelile în viitor și să-și îmbunătățească stilul de dezvoltare, atunci nu a fost în zadar.
În tot timpul pe care am lucrat cu Bitrix, am avut șansa de a lucra cu un număr foarte mare de proiecte pe care cineva le-a dezvoltat înaintea mea. Iată îmbunătățiri minore, remedierea diferitelor erori și erori în funcționarea logicii, reproiectarea site-ului și modificări globale ale funcționalității existente. Și, ca orice alt dezvoltator, urăsc să aranjez gunoiul altor oameni, cârjele și patch-urile „temporare” care amintesc de fapt de ediția a 8-a a produsului.
Aici voi încerca să nu mă concentrez pe „cele mai proaste practici” standard atunci când programez în PHP, cum ar fi să nu dau doi bani pe alegerea numelor de variabile și funcții, interogări inutile la baza de date într-o buclă, lipsa validării datelor utilizatorului în formulare, ignorarea comentariilor și altele asemenea. Voi încerca să ating exact momentele inerente dezvoltării pe Bitrix, care ulterior vă vor permite să evitați indignarea și înjurăturile împotriva voastră din partea programatorului care trebuia să vă însoțească codul. Și da, de multe ori tu însuți te vei dovedi a fi acest programator într-un an sau mai mult, când ai uitat complet de ce ai introdus cutare sau cutare cârjă aici.
„Scrieți codul ca și cum ar fi însoțit de un psihopat violent care știe unde locuiți.” © John F. Woods
În primul rând, și cel mai mult, după părerea mea, cel mai important - pentru numele lui Dumnezeu, utilizați folderul local. Acest lucru este pur și simplu vital atunci când utilizați sistemul de control al versiunilor - tot ce aveți nevoie este să adăugați folderul /bitrix/ la excluderi. Tot. În plus, aproape toată dezvoltarea se realizează numai în ea. Acest lucru simplifică foarte mult căutarea fișierelor și componentelor necesare mai târziu, ajută să nu înfundați depozitul cu fișiere inutile și, în general, aduce arborele proiectului într-un aspect mai ordonat, „uman”.
Nu modificați nucleul. Chiar dacă ești sigur că nu va fi actualizat. Chiar dacă este mai rapid. Chiar dacă ești leneș. Uită acest gând, ca un vis urât. Dacă trebuie să schimbați logica unei componente standard, mutați-o într-un nou spațiu de nume /local/components/modify/ și lucrați cu ea. Același lucru este valabil și pentru module, gadgeturi și activități de proces de afaceri.
Nu poluați fișierul init.php. Combinați funcțiile pentru a lucra cu un anumit modul sau funcționalitate într-o clasă, scrieți această clasă întreagă într-un fișier separat și în init.php includeți doar aceste fișiere și scrieți handlere de evenimente. Am văzut fișiere init.php de 500 Kb fiecare, în care funcțiile, definițiile constante, clasele și inițializarea handlerelor au fost amestecate într-o mizerie. Desigur, când a trebuit să mă ocup de aceste fișiere, mi-am înjurat predecesorii.
Următorul paragraf nu se aplică în cazul dezvoltării de soluții gata făcute pentru Piață, când scopul este de a realiza cea mai personalizabilă funcționalitate din partea publică pentru utilizatorul final. Dacă lucrați la un anumit proiect, pentru un anumit TOR - nu ar trebui să încercați să faceți un șablon unificat pentru o componentă pentru toate ocaziile. Personal, aderă la filozofie - este mai bine să aveți mai multe șabloane simple folosite în scopuri diferite decât unul universal, dar în care diavolul însuși își va rupe piciorul mai târziu. Desigur, în fiecare caz specific, trebuie să vă bazați pe ceea ce este - termenii de referință, opțiunile de implementare și altele asemenea, dar tot nu ar trebui să uitați de Occam's Razor. Ca exemplu, voi da un proiect al unei companii de leasing pe care s-a întâmplat să îl editez. Proiectul în sine, desigur, a fost implementat teribil, adevărata groază a fost în paginile secțiunii de catalog de servicii. Fiecare dintre cele cinci secțiuni avea propriul aspect, care diferea atât prin poziția blocurilor pe pagină, cât și, în principiu, prin prezența unora dintre ele. Și pentru toate cele cinci pagini, a fost folosit un șablon cu o grămadă de apeluri de tip if-else, duplicarea apelurilor componente, stiluri de conectare și scripturi, care, în plus, intrau periodic în conflict unele cu altele. Drept urmare - un dosar imens, în care să înțelegi „fără jumătate de litru” era ca moartea. Deși, s-ar părea, ce te-a împiedicat să faci 5 șabloane diferite și să nu creezi dificultăți din senin?
Utilizați API-ul. Nu reinventați roata acolo unde nu este nevoie. Utilizați documentația - întregul produs este destul de bine descris, precum și fiecare funcție poate fi vizualizată în detaliu pe bxapi.ru.
Evitați interogările directe ale bazei de date. Acesta este un caz special al punctului anterior - utilizați API-ul. Solicitările brutale, nesecurizate pot duce la coruperea, pierderea sau chiar compromisul datelor.
Nu utilizați componente CNC de la rădăcina site-ului. Consecințele sunt de obicei destul de nefericite, deoarece CNC folosește un fișier de gestionare a adresei, încercarea de a-l folosi de la rădăcină vă rupe cu ușurință adresarea altor componente, precum și 404 pagini. Nu va strica nimic dacă articolele dvs. sunt adresate în raport cu folderul /articole/ și produsele legate de /catalog/.
Includeți css și js folosind API-ul. Până acum, peste tot întâlnesc legătura de scripturi și stiluri folosind etichete html. Utilizați obiectul de clasă \Bitrix\Main\Page\Asset și funcțiile addJs() și addCss(). Acest lucru vă va permite să îmbinați fișiere și, ulterior, să le memorați în cache cu un singur clic al casetei de selectare din setările modulului principal
Și, în sfârșit, eroarea se referă nu numai la Bitrix, dar prea des am început să întâmpin probleme asociate cu aceasta. Verificați matricea goală cu rezultatele eșantionului. De exemplu, ultima dată când am întâlnit această problemă a fost când lucram cu un magazin online. Reclamație: Paginile durează uneori 16 secunde pentru a se încărca. Cu ce este conectat - nu este clar. Prin încercare și eroare, am aflat că paginile se încarcă indecent mult timp doar când coșul este gol. Părea de ce? După cum s-a dovedit, la trecerea cu mouse-ul peste coș, a apărut o fereastră pop-up în care erau afișate imagini cu produsul pus în coș. Deci, ce a făcut dezvoltatorul anterior? Am luat rezultatul muncii componentei „coș mic” și în fișierul result_modifier.php a făcut un apel la GetList () de mărfuri pentru a selecta imagini cu un filtru din matricea de ID-uri de produs, apoi din rezultatele selecției la matricea produsului corespunzător a adăugat src-ul imaginii. Ca urmare, atunci când nu existau mărfuri în coș, filtrul s-a golit, iar TOTUL catalog de mărfuri a intrat în selecție. Ei bine, atunci ciclul pentru fiecare și... avem ceea ce avem. Este clar că în stadiul de dezvoltare, cu 15 produse de testare, acest lucru era insesizabil, iar probleme au apărut deja în condiții de luptă. Deși, s-ar părea că a meritat să verificați golul ($arResult["ITEMS")...
Aceasta încheie topul meu personal cu „cele mai proaste practici” în ceea ce privește dezvoltarea Bitrix. Dacă măcar pe cineva această informație ajută să evite greșelile în viitor și să-și îmbunătățească stilul de dezvoltare, atunci nu a fost în zadar.
Cum să dezactivați reclamele pe Android: eliminați anunțurile pop-up
Rusul a primit un termen și un milion de amendă pentru „piraterie Consecințele negative ale legii
Identificarea factorilor cheie
S-au schimbat criteriile de clasificare a organizațiilor și a antreprenorilor individuali ca întreprinderi mici și mijlocii
Vezi ce este „Royalty” în alte dicționare Capcanele legislației