Sfaturi complete pentru dezvoltatori de la creatorul bibliotecii de formulare Redux

În februarie 2019, echipa comunității Toptal a lansat o inițiativă nou-nouță: o oportunitate lunară de a interacționa cu experții în rețea Toptal în timp real. Sesiunile Ask Me Anything (AMA) sunt deschise tuturor membrilor echipei de bază și rețelei de talente Toptal – oricine poate pune o întrebare. În această piesă, am selectat întrebări și răspunsuri de la un AMA cu expertul JavaScript și Redux Erik Rasmussen. Erik discută despre provocările dezvoltării de software open-source, sfaturi pentru dezvoltatori și lumea fluctuantă a JavaScript, cum se confruntă cu sindromul impostorului și burnout-ul ca dezvoltator la cerere și recomandările sale de top pentru podcast.

Erik este un expert JavaScript full-stack cu peste 25 de ani de experiență în dezvoltare, specializat în React, Redux, formulare în React și GraphQL. Pe GitHub — un serviciu de găzduire web pentru controlul versiunilor cu peste 28 de milioane de utilizatori — el a obținut un loc în top 100 cu peste 20.000 de stele. El este, de asemenea, autorul primei și al treilea cele mai populare biblioteci de formulare din React: Redux-Form și React-Final-Form.

Redux Form și starea software-ului open-source

De ce ați decis să creați o altă bibliotecă de formulare după succesul extraordinar din spatele Redux Form?

Am învățat multe lecții pe parcurs cu Redux Form și am obținut informații despre nevoile dezvoltatorilor React Form din întreaga lume. Unele dintre problemele cu React Form pur și simplu nu au putut fi rezolvate fără a arunca o privire nouă asupra problemei. (Mai multe detalii aici.)

Mulți dezvoltatori visează să creeze un proiect open-source foarte popular. Care sunt câteva dintre consecințele neașteptate (bune și rele) ale unui proiect la fel de reușit ca Redux Form?

Este extrem de satisfăcător când poți remedia o eroare care a împiedicat un dezvoltator sau o întreagă echipă să finalizeze un proiect. De asemenea, este cu adevărat grozav când oamenii găsesc și remediază ei înșiși erorile. Până acum, oamenii au fost foarte drăguți și amabili când au cerut ajutor; Nu am avut încă o interacțiune cu un utilizator corect care să creadă că îi datorez o soluție.

Pe partea provocatoare, burnout-ul este un lucru real și nu am descoperit încă o modalitate de a compensa dezvoltatorii OSS pentru că și-au acordat timpul și energia proiectelor OSS. Redux Form este folosit de corporații de miliarde de dolari din întreaga lume pentru a face tranzacții, iar existența sa a economisit mii de ore de dezvoltare pentru echipele care l-au instalat, dar nu există o soluție bună pentru a oferi măcar o bucată din acești bani autorilor. .

Există soluții promițătoare în lucru pentru a compensa dezvoltatorii open-source ca tine?

Un prieten de-al meu a început această companie numită CodeFund. El a avut ideea: „Dar dacă am putea pune reclame în documentația bibliotecii de coduri?” În calitate de dezvoltatori, petrecem toată ziua uitându-ne la documentație și ne dăm seama cum să implementăm orice lucru pe care îl facem. În plus, dezvoltatorii câștigă mult mai mulți bani decât navigatorul tău mediu, așa că suntem un potențial de produs de lux.

CodeFund a venit cu ideea că documentația este un loc foarte bun pentru a face publicitate. Am fost unul dintre piloții originali. A funcționat destul de bine, dar au avut o problemă cu GitHub. Inițial, puneam reclame în depozitul GitHub în sine, dar GitHub și avocații au intervenit și au spus nu. Ceea ce este păcat. CodeFund a negociat cu ei o vreme, dar până la urmă au spus că nu.

Cu documentația de bibliotecă bine traficată, puteți obține poate 150 de dolari pe lună, ceea ce nu plătește pentru ceea ce valorează. Există câteva biblioteci rare, cum ar fi Babble sau Webpack, în care li se dau destui bani încât să poată susține de fapt doi sau trei dezvoltatori cu normă întreagă care lucrează pentru a îmbunătăți acel lucru. Babble și Webpack — companii în valoare de miliarde și miliarde de dolari stau pe infrastructura lor și, cu siguranță, Redux Form le sprijină.

În aproape orice site web la care accesați, puteți căuta în sursă și puteți vedea un cod care a fost scris de o anumită persoană care nu este compensată corespunzător. Trebuie crescută gradul de conștientizare pentru a face oamenii să aprecieze mai mult ce este sursa deschisă și orele pe care unii dintre noi le depunem.

De ce să creați ceva care este open-source și gratuit? Care este stimulentul pentru dezvoltatori ca tine?

Motivul pentru care îl creați este pentru că aveți nevoie de el pentru orice lucru la care lucrați în acest moment. Când îl eliberezi, vin alții și îl fac mai bun. Visul cu sursă deschisă este că spuneți: „Am construit o mică roabă care mă ajută să-mi iau pietrele de aici până acolo”, apoi vine cineva și o face mai bună. La următorul tău proiect, te întorci și folosești aceeași bibliotecă și îți spui: „Uau, chestia asta se mișcă mult mai repede. Acum e mai bine.”

De asemenea, este foarte plină de satisfacții. Primesc o lovitură de dopamină când oamenii spun: „Acest lucru ne ține de trei săptămâni și această mică remediere care ți-a luat trei ore ne-a economisit trei săptămâni.” Există un mic ciclu de dependență cu asta, în care primești întărire pozitivă și pur și simplu te simți bine.

Cu cea de-a doua bibliotecă de formulare, nu era atât de mult încât oamenii spuneau: „Hei, vrem o altă bibliotecă de formulare”, ci doar că m-am gândit la o modalitate de a o îmbunătăți.

Acesta este un fel de vis de ce faci asta. Dar cu siguranță nu este pentru bani.

Într-o lume ideală, câtă compensație ați primi pentru crearea de software open-source? Doar niște cireașă de pe tort?

Nu m-ar deranja dacă cineva mi-ar plăti șase cifre pentru a lucra pe open source toată ziua. Dacă te uiți la valoarea generată față de cost, raportul pentru open-source este atât de mare. Ajungi la biblioteci minuscule care fac un lucru și unul foarte, foarte bine.

Dacă fiecare companie din lume ar trebui să-și desemneze propria echipă de dezvoltatori pentru a face asta, rezultatele ar varia foarte mult. Faptul că avem sursă deschisă și că putem avea o soluție pentru asta - o bulă de algoritm în partea de sus care este cea mai bună - înseamnă că toată lumea din lume are acea eficiență încorporată.

O altă valoare din sursa deschisă este aceea că dacă utilizați ceva ce ați scris și numai compania dvs. îl folosește. . . compară asta cu ceva pe care îl folosesc 1.000 de companii. Ei au găsit fiecare colț și colț din spațiul de bug-uri care ar putea fi o problemă, și iei asta și îl conectezi la lucrul tău - ești de aur. Vei avea mult mai multă încredere în asta.

Lumea dinamică a JavaScript

Fiind atât de mult timp în spațiul JavaScript, trebuie să fi văzut atât de multe cadre noi [pentru construirea de aplicații JavaScript] venind și plecând. Cum țineți pulsul industriei, astfel încât să puteți decide în ce cadre să vă angajați?

Trebuie să înțelegeți vânturile comunității dezvoltatorilor. Lupta actuală dintre TypeScript și Flow este un exemplu grozav. Am ales inițial calul greșit în cursa respectivă, presupunând că Facebook ar fi un administrator mai bun al unui cadru de tastare. Dar cred că TS a câștigat destul de mult acea bătălie și acum migrez încet lucrurile în acea direcție.

Există un colț al Twitter care este „dezvoltatorul Twitter”. Dacă urmăriți destui oameni – poate aveți nevoie de o dimensiune a eșantionului de aproximativ o sută – puteți înțelege unde bat vânturile și ce devine popular. Veți primi o mulțime de postări de genul „Obișnuiam să folosim biblioteca A, dar tocmai am învățat despre biblioteca B și totul este mult mai ușor.” Te saturi din acestea și îți spui: „Ei bine, poate ar trebui să verific această altă bibliotecă”.

Tendințele vin și trec în spațiul JavaScript. Va fi mereu în mișcare?

Cred (și sper) că va continua să evolueze. Stagnarea este moarte în tehnologie. Chiar și Java inovează semnificativ în acest moment: lucrurile pe care le poți face în Java 10 nu seamănă cu nimic cu Java 6 al bunicii tale.

Poate fi obositor să construiești în sfârșit aplicația cu Tech X doar pentru a vedea că toți copiii cool folosesc acum Tech Y. Dar asta este industria în care ne aflăm.

În opinia dumneavoastră, ce concepte JavaScript sunt deosebit de importante pentru a înțelege cu adevărat pentru a dobândi stăpânirea limbajului?

Aș spune că programarea funcțională și ideea de a transmite funcții sunt destul de importante. Mai ales dacă veniți dintr-un limbaj precum Java sau C++.

Credeți că React ar trebui folosit pentru construirea de SPA-uri [aplicații cu o singură pagină] sau doar pentru componente dintr-o pagină obișnuită?

Aceasta este frumusețea lui React: este atât de versatil. Am introdus încet React pentru toate funcțiile noi într-o veche aplicație Java/jQuery la munca mea de zi cu zi. React funcționează foarte bine, având în vedere un nod DOM pentru a acționa. Nu trebuie să dețină controlul asupra întregii aplicații.

Când porniți o nouă aplicație React, care sunt instrumentele și bibliotecile pe care le utilizați în mod regulat de la zero?

Cred că create-react-app este câștigătorul clar în acest moment. Acum patru ani, când nu era așa ceva, era mult mai greu.

Cum gestionați starea aplicației în aplicațiile dvs. de reacție?

Când a apărut Redux, a fost clar răspunsul. Cu toate acestea, am descoperit că o mare parte din „starea” mea Redux era chestii precum loading și listOfObjects și, cel mai recent, am folosit Apollo GraphQL pentru aceste lucruri. Alte lucruri precum isSideNavOpen pot fi gestionate cu componente bazate pe context destul de ușor. Acestea fiind spuse, există încă câteva cazuri de utilizare legitime pentru Redux, dar niciunul pe care l-am întâlnit în aplicațiile mele simple React.

Care este editorul/IDE-ul tău preferat?

Ah, întrebarea asta !

Vin din Java și sunt foarte mulțumit de JetBrains IntelliJ de mulți ani, dar este puțin lent pentru JS. Mai întâi am fost la Atom, dar în cele din urmă m-am hotărât pe VS Code. Integrațiile sale pentru Jest și Flow și TypeScript sunt imbatabile.

Care este părerea ta despre dezvoltarea izomorfă precum opal , care traduce ruby ​​în JS și apoi deschide calea pentru ca Rubysts să scrie aplicații structurate React/Flux în Pure Ruby (fără a scrie niciun JS)?

Faptul că JavaScript a făcut saltul la server, cred, este o mare problemă. A fi capabil să randați cu același cod atât pe client, cât și pe server este uriaș și, mai probabil, calea viitorului.

Care credeți că este cea mai mare problemă a celor mai populare cadre JS actuale?

Nu sunt pe deplin sigur, dar îmi place foarte mult direcția css-in-js, serverless și SSR pe care companii precum Zeit o urmăresc cu Next.js.

Este foarte amuzant pentru mine, ca cineva care construia site-uri web la sfârșitul anilor 90, că ne întoarcem la site-uri statice. Ne vom întoarce la generarea totul în timpul construirii, iar apoi aveți elementele dvs. statice pe server și apoi puteți adăuga lucruri dinamice prin ceea ce ei numesc rehidratare. După ce ați redat întreaga pagină, puteți obține JavaScript suplimentar pentru a face lucrurile animate și pentru a muta componentele.

Zeit, cu cadrul lor Now, acceptă, de asemenea, crearea statică a site-ului dvs., deoarece nimic nu este mai rapid decât descărcarea unui fișier HTML static. Este doar un fișier text și apoi boom, ai înțeles. În timp ce, dacă accesați un server, acesta trebuie să lovească o bază de date poate de patru sau o sută de ori doar pentru a construi orice pagină pe care trebuie să o afișați. E super lent.

Ideea statică câștigă popularitate.

Considerați că JavaScript poate prelua limbaje „mature” (cum ar fi Java și C++) și poate deveni limba preferată pentru întreprinderi?

Categoric. Lucrurile pe care oamenii le fac acum cu nodul „fără server” sunt extrem de scalabile și cred că API-urile de întreprindere [interfețele de programare a aplicațiilor] pot și vor fi rescrise în JavaScript, cel puțin de către corporațiile mai agile și mai avansate.

Ce ar trebui să caute un dezvoltator la un client?

Vrei să ți se acorde un nivel de încredere și autonomie, presupunând că ești suficient de în vârstă pentru a-l merita. Nu aș vrea să iau o slujbă în care cineva se uita peste umărul meu tot timpul. O mulțime de timp, cu munca de dezvoltare, poți avea ceva care durează cinci minute pentru a remedia, dar petreci patru ore lucrând la o mică problemă cu construcția care îl face, astfel încât să nu îl poți testa efectiv. Sunt de multe ori în care voi petrece opt sau zece ore pe o problemă — unde lucrez cu adevărat, foarte concentrat tot timpul — și soluția reală este ca două linii de cod. Vrei un angajator care să înțeleagă cum este munca ta.

Despre Sindromul Imposter, Burnout și Destresare

Sindromul impostorului pare să fie un fenomen neobișnuit în rândul dezvoltatorilor. Îl experimentezi și, dacă da, cum te descurci cu ea?

Absolut. Mai ales când vorbești la o conferință. (Sau faci un AMA?)

Când vine vorba de predare/mentorat, trebuie să-ți dai seama că știi mai multe despre ceea ce faci decât luna trecută. Prin urmare, există întotdeauna oameni care s-au întors acolo unde erai înainte și care ar putea beneficia de cunoștințele tale.

De asemenea, este important să poți spune: „Nu știu, haideți să investigăm împreună” (de asemenea, un sfat bun pentru părinți).

Cum este o zi din viața ta? Cum programezi totul, astfel încât să nu lucrezi 100 de ore pe săptămână și să te epuizezi?

Când am fost cu adevărat adânc în sursa deschisă, asta îmi ia mult mai mult timp; uneori, trebuie să mă retrag pentru o lună sau cam asa ceva la un moment dat. Îmi duc copiii la școală și apoi mă uit la ce fel de probleme au oamenii. Dacă sunt cu adevărat serioși, atunci depun un efort încercând să le remediez sau să răspund într-un mod util.

Am o slujbă de zi care nu are deloc legătură cu sursa deschisă, ceea ce îmi ia mult timp. Pe tot parcursul zilei, am configurat notificări, astfel încât să pot vedea dacă există o problemă serioasă cu ceva. Dacă a fost lansată o nouă funcție sau ceva de genul acesta, atunci este mai probabil să apară erori în acea perioadă.

Am învățat că oricine scrie cerințele pentru un proiect este sigur că „Ar fi trebuit să se facă ieri, deci de ce nu sa făcut încă?” Am avut atât de multe ori în care orice echipă primește munca mea durează aproximativ trei săptămâni pentru a o pune efectiv în producție. Și îți spui: „Ei bine, despre ce a fost tot stresul?”

Dacă o sarcină trebuie îndeplinită până vineri și aceasta se termină până vineri următoare, afacerea nu se închide aproape niciodată pentru că ai eșuat. Când ești tânăr și nu știi nimic mai bine, te simți ca „O, Doamne, trebuie să scoatem asta pe ușă”. Dar după ce ai făcut asta de destule ori și vezi „Stai puțin, ceea ce ne spuneau ei nu era chiar adevărat”, poți spune „Bine, da. Tot ceea ce. Se va termina când se va termina.”

Eram puțin epuizată în octombrie anul trecut, când React a anunțat chestia asta numită React Hooks. Dacă aș fi fost acolo, gata să iau orice lucru nou și să alerg cu el, aș fi putut câștiga o mulțime de kilometri fiind unul dintre primii oameni care au intrat în React Hooks. Sunt oarecum cu ochii pe ceea ce ar putea fi următorul mare lucru.

Ce faci în timpul liber pentru a reduce stresul?

Fac plimbări și ascult podcasturi care nu sunt despre dezvoltare.

Ai putea recomanda ceva?

Singurele podcasturi tehnologice reale pe care le ascult sunt The Undefined Podcast, care este doar tangențial despre sfaturi de tehnologie și dezvoltatori. Ascult și React Podcast—pe care voi apărea în curând (sper că va avea sens, în funcție de calitatea editorului lor).

Privind la podcast-ul ales de mine, Overcast, podcasturile mele prioritare includ:

• Roderick pe linie
• Făcând sens
• Podcast tehnic accidental
• Lucrări rutiere
• Exponent
• Salutare Internet
• Radiolab
• Răspunde la toate

Recent, am început eu însumi două podcasturi:

Primul se numește Seek Justice, în care eu, o persoană moderată inteligentă care nu știe aproape nimic despre sistemul de justiție penală, intervievez un prieten de-al meu care și-a petrecut întreaga carieră examinând și lucrând la reformarea acestuia. El lucrează direct cu guvernatorii mai multor state din SUA pentru a reduce populația închisorilor și a recidivei după eliberare. Nu este un subiect de care am fost vreodată cu adevărat interesat, dar co-gazda mea mă captivează la fiecare episod.

Al doilea este un spectacol de prostie pură, numit Happy Hour cu Dennis și Erik, în care același prieten și cu mine luăm câteva băuturi de seară, vorbim despre viața noastră și ne facem de râs unul pe altul. Căutați dreptate este pentru naveta dvs. strălucitoare la serviciu, iar Happy Hour este pentru drumul dvs. relaxant spre casă.

Pentru a-l aduce înapoi la dev, eforturile mele de podcast m-au ajutat să rezolv o problemă pentru care nu am putut găsi o soluție în industrie: un MP3 player ușor, cu artă de album, care a funcționat și ca un card Twitter. Așa că am scris AudioCard.