am urmărit/ascultat această mare discuție a lui Simon Brown pe monoliți modulari de la GOTO 2018.
în aceasta el menționează un termen numit Cargo Cult programare și într-adevăr a lovit o coardă cu mine.
m-am alăturat recent unei noi companii cu un nou limbaj de programare, noi instrumente, noi procese și o nouă echipă. De fapt, totul e destul de nou.
acest lucru m-a determinat să învăț multe în ultimele luni. Fiind relativ experimentat, îmi place să se uite în ‘De ce’, mai degrabă decât ‘hows’ atunci când învață lucruri noi. Ceea ce am realizat este că aceasta nu este cea mai comună abordare.
când un utilizator este însărcinat să adauge la o bază de cod existentă, extinzând soluția curentă, cel mai probabil va verifica modul în care acest lucru a fost făcut anterior, copiind abordarea soluției lor. Ei pot / vor urma orbește acest model așa cum a fost făcut înainte. Blocuri suplimentare se adaugă pe partea de sus a turnului, fără a pune la îndoială dacă este un lucru bun de făcut. Dacă toată lumea face acest lucru, acest lucru se va întâmpla în cele din urmă.
acest lucru este în cazul în care termenul ‘Cargo Cult programare’ vine de la.
Wikipedia o explică astfel:
programarea cultului Cargo este un stil de programare pe calculator caracterizat prin includerea rituală a structurilor de cod sau program care nu servesc unui scop real. Programarea cultului Cargo este de obicei simptomatică a unui programator care nu înțelege nici un bug pe care încerca să-l rezolve, nici soluția aparentă (comparați depanare pușcă, magie profundă). Termenul cargo cult programator se poate aplica atunci când un programator de calculator necalificat sau novice (sau unul neexperimentat cu problema la îndemână) copiază un cod de program dintr-un loc în altul, cu puțină sau deloc înțelegere a modului în care funcționează sau dacă este necesar în noua sa poziție.
programarea cultului Cargo se poate referi, de asemenea, la practica aplicării orbește a unui model de proiectare sau a unui stil de codare fără a înțelege motivele din spatele acestui principiu de proiectare. Exemple sunt adăugarea de comentarii inutile la codul auto-explicativ, aderarea excesivă la convențiile unei paradigme specifice de programare sau adăugarea de cod de ștergere pentru obiectele pe care colectarea gunoiului le-ar fi colectat automat.
Imaginați-vă un scenariu în care lucrați la un bug, găsind codul care cauzează defecțiunea. Nu ești foarte sigur ce se întâmplă, așa că;
- Google eroarea.
- veți găsi o întrebare StackOverflow.
- caută răspunsul cel mai upticked.
- copiați și inserați soluția în codul dvs.
- încercați să depanați pentru a vedea dacă ați rezolvat problema.
are, așa că verificați-l și mergeți mai departe.
suna familiar?
de ce facem asta? De ce luăm orbește acest fragment și îl folosim așa cum este, în implementarea noastră?
cazul de utilizare nu este probabil același, așa că aș fi surprins dacă soluțiile au fost. Exemple Simple deoparte, înțelegerea raționamentului din spatele soluției este mai importantă decât soluția în sine. Sunt multe lucruri pe care nu le poți face cu ceva ce nu înțelegi. Nu îl puteți modifica, îmbunătăți sau testa. Nu o poți documenta și nu o poți deține.
cu toții iubim ceea ce este nou, iar managementul pare să-i placă în special să urmeze tendințele populare, ținând pasul cu progresul tehnologic.
majoritatea echipelor vor urma Acum o abordare agilă. TDD și testarea automată pot fi foarte utile în anumite scenarii, integrarea continuă elimină o mare parte din cheltuielile generale ale echipei de infrastructură, datele mari și AI pot îmbunătăți considerabil satisfacția utilizatorilor și containerizarea și, cel mai recent, Microserviciile transformă vechea noastră arhitectură monolită în servicii autonome mai mici.
fiecare dintre aceste progrese este genial în sine, și eu nu scuza nici una dintre ele. Situația mea dificilă este dacă trebuie să le adoptăm pe toate în toate procesele și codurile noastre? Vedem postări pe blog de la Netflix, Facebook, Twitter care arată modul în care utilizarea lor a transformat modul în care funcționează. Dacă marile companii le consideră necesare, nu ar trebui și noi? Acesta este locul în care programarea cultului cargo își ridică din nou capul urât.
trebuie să înțelegem problemele cu proiectele noastre actuale, de ce s-au întâmplat și cum pot fi aruncate în viitor. Da, aceste noi procese ne pot ajuta cu problemele noastre, dar urmarea lor orbește în speranța slabă pe care o fac nu este calea de urmat și nici nu are sens logic.
menționez Microserviciile în mod specific, deoarece multe companii par să facă tranziția, citând beneficii precum:
- timp de dezvoltare mai rapid
- scalabilitate ridicată
- ușor de îmbunătățit
- ușurința implementării
- Echipe autonome cu libertatea de a alege tehnologia
cu o listă de genul acesta, la ce să ne gândim? Să sărim cu toții pe bandwagon!
așteptați o secundă… există dezavantaje la această abordare?
- complexitate arhitecturală
în arhitecturi monolitice, complexitatea și numărul de dependențe se află în interiorul bazei de cod, în timp ce în arhitecturi microservicii complexitatea se mută la interacțiunile serviciilor individuale care implementează un domeniu specific
- complexitate operațională
- cum să furnizeze resurse într-un mod scalabil și rentabil
- cum să opereze zeci sau sute de componente Microservice în mod eficient, fără a multiplica eforturile
- cum să se ocupe cu o lipsă de standarde și eterogene medii care includ diferite tehnologii și oameni cu diferite seturi de competențe
- cum să se ocupe de versionare
- cum să urmăriți și să depanați interacțiunile din întregul sistem
- cum să urmăriți sute de conducte de implementări de coduri și interdependențele lor
acestea sunt ridicate din propria „provocare a Microserviciilor” a Amazon. Acum nu știu despre tine, dar dezavantajele arata mult mai infricosator pentru mine decât beneficiile. Încă o dată, nu spun acest lucru nu este abordarea corectă pentru a merge în jos, dar cu excepția cazului în care aceste beneficii depășesc dezavantajele ce câștigi din urma acestei abordări?
problema ‘publică’.
este simplu într-adevăr, nu mai folosiți cuvântul cheie Public, nu mai Creați automat clase publice. De ce o facem?
problema cu utilizarea cuvântului cheie public este că pierdeți beneficiile legate de încapsulare. De ce o folosim atât de mult? Este destul de mult cuvântul implicit pe care îl folosim atunci când creăm clase, toate exemplele vor folosi clase publice, vrăjitorii și fragmentele vor implementa clase publice. E timpul să ne oprim. Câți oameni au un cont public de Facebook? Cele mai multe lucruri din această lume sunt private, așa cum ar trebui să fie clasele noastre. Faceți-le private în mod implicit, iar apoi, dacă aveți nevoie să fie publice, schimbați-le atunci.
cu o mare experiență vine o mare teamă.
cu cât vă aflați mai mult într-un domeniu, cu atât sunteți mai puțin naivi față de îmbunătățirile percepute pe care le va aduce un nou instrument sau proces. Majoritatea ideilor de astăzi provin din cercetări vechi de zeci de ani în domeniu, care sunt în cele din urmă îmbrățișate. Odată ce ceva a câștigat adoptarea în masă, este mai ușor să se simtă confortabil cu îmbrățișând-o pe deplin. Asta este, dacă este un lucru bun de făcut.
„judecata bună vine din experiență, iar experiența vine din judecată proastă”
– Rita Mae Brown
deci, nu ezitați să continuați să curățați interweb-urile pentru soluții și tutoriale pentru problemele dvs.; continuați să explorați noi limbi, cadre și implementări. Doar să fie conștienți de ce funcționează, mai degrabă decât pur și simplu cum. Cu toții învățăm din propriile noastre experiențe și greșeli, astfel încât înțelegerea fundamentelor vă va împiedica să continuați pe aceeași cale în viitor.