Pełne porady dla programistów od twórcy biblioteki formularzy Redux

W lutym 2019 r. zespół społeczności Toptal uruchomił zupełnie nową inicjatywę: comiesięczną możliwość interakcji z ekspertami sieci Toptal w czasie rzeczywistym. Sesje Ask Me Anything (AMA) są otwarte dla wszystkich członków podstawowego zespołu i sieci talentów Toptal — każdy może zadać pytanie. W tym artykule wybraliśmy wybrane pytania i odpowiedzi z AMA z ekspertem JavaScript i Redux, Erikiem Rasmussenem. Erik omawia wyzwania związane z tworzeniem oprogramowania typu open source, poradami dla programistów i zmiennym światem JavaScript, jak radzi sobie z syndromem oszusta i wypaleniem jako programista na żądanie, oraz przedstawia swoje najlepsze rekomendacje dotyczące podcastów.

Erik jest pełnoprawnym ekspertem JavaScript z ponad 25-letnim doświadczeniem programistycznym, specjalizującym się w React, Redux, formularzach w React i GraphQL. W GitHub — internetowej usłudze hostingowej do kontroli wersji z ponad 28 milionami użytkowników — uzyskał miejsce w pierwszej setce z ponad 20 000 gwiazdek. Jest także autorem pierwszej i trzeciej najpopularniejszych bibliotek formularzy w React: Redux-Form i React-Final-Form.

Formularz redux i stan oprogramowania typu open source

Dlaczego zdecydowałeś się stworzyć kolejną bibliotekę formularzy po ogromnym sukcesie Redux Form?

Po drodze nauczyłem się wielu lekcji z Redux Form i uzyskałem wgląd w potrzeby programistów React Form na całym świecie. Niektórych problemów z React Form po prostu nie można było rozwiązać bez ponownego spojrzenia na problem. (Więcej szczegółów tutaj.)

Wielu programistów marzy o stworzeniu masowo popularnego projektu open source. Jakie są nieoczekiwane konsekwencje (dobre i złe) posiadania projektu tak udanego jak Redux Form?

To niezwykle satysfakcjonujące, gdy możesz naprawić błąd, który powstrzymywał programistę lub cały zespół przed ukończeniem projektu. To naprawdę niesamowite, gdy ludzie sami znajdują i naprawiają błędy. Do tej pory ludzie byli bardzo mili i uprzejmi, gdy proszą o pomoc; Nie miałem jeszcze interakcji z prawym użytkownikiem, który myśli, że jestem im winien poprawkę.

Jeśli chodzi o wyzwania, wypalenie jest realne i nie odkryliśmy jeszcze sposobu na zrekompensowanie deweloperom OSS za poświęcenie czasu i energii na projekty OSS. Redux Form jest używany przez miliardowe korporacje na całym świecie do zawierania transakcji biznesowych, a jego istnienie zaoszczędziło tysiące godzin pracy zespołów, które go zainstalowały, ale nie ma dobrego rozwiązania, aby przekazać autorom choćby odłamek tych pieniędzy .

Czy są jakieś obiecujące rozwiązania w zakresie wynagradzania programistów open-source takich jak ty?

Mój przyjaciel założył tę firmę o nazwie CodeFund. Wpadł na pomysł: „A co, gdybyśmy mogli umieścić reklamy w dokumentacji biblioteki kodu?” Jako programiści spędzamy cały dzień na przeglądaniu dokumentacji i zastanawianiu się, jak zaimplementować to, co robimy. Ponadto programiści zarabiają znacznie więcej pieniędzy niż przeciętny internauta, więc mamy potencjał w zakresie produktów luksusowych.

CodeFund wpadł na pomysł, że dokumentacja to naprawdę świetne miejsce na reklamę. Byłem jednym z pierwszych pilotów. Działało całkiem dobrze, ale napotkali problem z GitHub. Początkowo umieszczaliśmy reklamy w samym repozytorium GitHub, ale GitHub i prawnicy wkroczyli i powiedzieli „nie”. A szkoda. CodeFund negocjował z nimi przez chwilę, ale w końcu odmówili.

Z dobrze przemyconą dokumentacją biblioteczną można dostać około 150 dolarów miesięcznie, co nie jest równoznaczne z opłaceniem tego, co jest warte. Istnieją pewne rzadkie biblioteki — takie jak Babble lub Webpack — w których otrzymuje się wystarczająco dużo pieniędzy, aby faktycznie mogły wspierać dwóch lub trzech programistów na pełny etat, pracujących nad ulepszeniem tej rzeczy. Babble i Webpack — firmy warte miliardy dolarów korzystają ze swojej infrastruktury i z pewnością wspiera je Redux Form.

W prawie każdej witrynie, na którą wchodzisz, możesz zajrzeć do źródła i zobaczyć kod napisany przez jedną konkretną osobę, która nie otrzymuje odpowiedniego wynagrodzenia. Należy podnieść świadomość, aby ludzie bardziej docenili, czym jest open source i godzinami, które niektórzy z nas poświęcają.

Po co tworzyć coś, co jest otwarte i bezpłatne? Jaka jest zachęta dla programistów takich jak Ty?

Powodem, dla którego go tworzysz, jest to, że potrzebujesz go do tego, nad czym aktualnie pracujesz. Kiedy ją wypuścisz, inni przyjdą i ją ulepszą. Marzeniem o otwartym kodzie źródłowym jest to, że mówisz: „Zbudowałem małą taczkę, która pomaga mi zabierać moje kamienie stąd, tam”, a potem pojawia się ktoś i robią to lepiej. W swoim następnym projekcie, cofasz się i używasz tej samej biblioteki i myślisz: „Wow, ta rzecz porusza się dużo szybciej. Już lepiej."

To także bardzo satysfakcjonujące. Dostaję uderzenie dopaminy, gdy ludzie mówią: „To powstrzymywało nas przez trzy tygodnie, a ta mała poprawka, która zajęła ci trzy godziny, zaoszczędziła nam trzy tygodnie”. Jest z tym trochę cyklu uzależnień, w którym otrzymujesz pozytywne wzmocnienie i po prostu czujesz się dobrze.

W przypadku mojej drugiej biblioteki formularzy nie chodziło o to, że ludzie mówili: „Hej, chcemy kolejną bibliotekę formularzy”, po prostu wymyśliłem sposób, aby to ulepszyć.

To rodzaj marzenia o tym, dlaczego to robisz. Ale na pewno nie dla pieniędzy.

W idealnym świecie, jakie wynagrodzenie można by otrzymać za stworzenie oprogramowania open source? Tylko wisienka na torcie?

Nie miałbym nic przeciwko, gdyby ktoś zapłacił mi sześć cyfr za pracę nad open source przez cały dzień. Jeśli spojrzysz na generowaną wartość w porównaniu z kosztami, stosunek open source jest tak wysoki. Dostajesz się do małych, małych bibliotek, które robią jedną rzecz, a jedną naprawdę, naprawdę dobrze.

Gdyby każda firma na świecie musiała wyznaczyć do tego własny zespół programistów, wyniki byłyby bardzo zróżnicowane. Fakt, że mamy otwarte oprogramowanie i możemy mieć na to jedno rozwiązanie — jedną bańkę algorytmu na górze, która jest najlepsza — oznacza, że ​​każdy na świecie ma wbudowaną tę wydajność.

Inną wartością z open source jest to, że jeśli używasz czegoś, co napisałeś i używa tego tylko Twoja firma . . . porównaj to z czymś, z czego korzysta 1000 firm. Znaleźli każdy najmniejszy zakamarek w przestrzeni robaka, który potencjalnie może stanowić problem, i bierzesz to i podłączasz do swojej rzeczy – jesteś złoty. Będziesz miał o wiele więcej zaufania do tego.

Dynamiczny świat JavaScript

Będąc w przestrzeni JavaScript od tak dawna, musiałeś widzieć tak wiele nowych, gorących frameworków [do tworzenia aplikacji JavaScript] pojawiających się i odchodzących. Jak monitorujesz branżę, aby móc decydować, w jakich ramach się zaangażować?

Musisz wyczuć wiatry społeczności deweloperów. Świetnym przykładem jest tocząca się obecnie walka między TypeScript a Flow. Na początku wybrałem niewłaściwego konia w tym wyścigu, zakładając, że Facebook byłby lepszym zarządcą ram do pisania. Ale myślę, że TS wygrał tę bitwę, a teraz powoli migruję rzeczy w tym kierunku.

Jest taki zakątek Twittera, który jest „twitterem dla programistów”. Jeśli śledzisz wystarczającą liczbę osób — może potrzebujesz próbki o wielkości około stu — możesz wyczuć, gdzie wieją wiatry i co staje się popularne. Dostaniesz wiele postów typu: „Kiedyś korzystałem z biblioteki A, ale właśnie dowiedziałem się o bibliotece B i wszystko jest o wiele łatwiejsze”. Masz ich dość i myślisz: „Cóż, może powinienem sprawdzić tę inną bibliotekę”.

Trendy pojawiają się i znikają w przestrzeni JavaScript. Czy zawsze będzie w ruchu?

Myślę (i mam nadzieję), że będzie się dalej rozwijać. Stagnacja to śmierć w technologii. Nawet Java jest teraz bardzo innowacyjna: rzeczy, które możesz zrobić w Javie 10, nie przypominają Java 6. Twojej babci.

Stworzenie aplikacji opartej na Tech X może być męczące, aby zobaczyć, że wszystkie fajne dzieciaki korzystają teraz z Tech Y. Ale to jest branża, w której działamy.

Twoim zdaniem, które koncepcje JavaScript są szczególnie ważne, aby naprawdę zrozumieć je, aby opanować język?

Powiedziałbym, że programowanie funkcjonalne i idea przekazywania funkcji jest bardzo ważna. Zwłaszcza jeśli pochodzisz z języka takiego jak Java lub C++.

Czy uważasz, że React powinien być używany do budowania SPA [aplikacji jednostronicowych], czy tylko do komponentów na zwykłej stronie?

Na tym polega piękno React: jest tak wszechstronny. W mojej codziennej pracy powoli wprowadzałem React dla wszystkich nowych funkcji w starej aplikacji Java/jQuery. React działa dobrze, biorąc pod uwagę węzeł DOM, na którym ma działać. Nie musi kontrolować całej aplikacji.

Kiedy uruchamiasz nową aplikację React, jakich narzędzi i bibliotek regularnie używasz od zera?

Myślę, że create-react-app jest teraz wyraźnym zwycięzcą. Cztery lata temu, kiedy nic takiego nie było, było dużo trudniej.

Jak radzisz sobie ze stanem aplikacji w aplikacjach Reaguj?

Kiedy wyszedł Redux, była to wyraźna odpowiedź. Jednak odkryłem, że większość mojego „stanu” Redux to rzeczy takie jak loading i listOfObjects , a ostatnio używałem do tego Apollo GraphQL. Innymi rzeczami, takimi jak isSideNavOpen można łatwo zarządzać za pomocą komponentów kontekstowych. To powiedziawszy, nadal istnieją pewne uzasadnione przypadki użycia Redux, ale żaden z nich nie spotkałem się w moich prostych aplikacjach React.

Jaki jest twój ulubiony edytor/IDE?

Ach, to pytanie!

Pochodzę z Javy i od wielu lat jestem bardzo zadowolony z JetBrains IntelliJ, ale JS jest trochę powolny. Najpierw poszedłem do Atom, ale ostatecznie zdecydowałem się na VS Code. Jego integracje z Jest, Flow i TypeScript są nie do pobicia.

Jaka jest twoja opinia na temat rozwoju izomorficznego, takiego jak opal , który tłumaczy ruby ​​na JS , a następnie otwiera drogę Rubystom do pisania aplikacji o strukturze React/Flux w Pure Ruby (bez pisania żadnego JS)?

Myślę, że fakt, że JavaScript przeskoczył na serwer, to wielka sprawa. Możliwość renderowania za pomocą tego samego kodu zarówno na kliencie, jak i na serwerze to ogromna i bardziej prawdopodobna droga na przyszłość.

Jak myślisz, co jest największym problemem naszych obecnych najpopularniejszych frameworków JS?

Nie jestem do końca pewien, ale naprawdę podoba mi się kierunek css-in-js, serverless i SSR, który firmy takie jak Zeit podążają za pomocą Next.js.

To naprawdę zabawne dla mnie, jako kogoś, kto budował strony internetowe w późnych latach 90., że wracamy do stron statycznych. Wracamy do generowania wszystkiego w czasie kompilacji, a wtedy masz swoje statyczne rzeczy na serwerze, a następnie możesz dodać dynamiczne rzeczy przez to, co nazywają ponownym nawodnieniem. Po wyrenderowaniu całej strony możesz uzyskać dodatkowy JavaScript, aby faktycznie animować rzeczy i przenosić komponenty.

Zeit, dzięki swojej strukturze Now, obsługuje również statyczne budowanie witryny, ponieważ nic nie jest szybsze niż pobranie statycznego pliku HTML. To tylko plik tekstowy, a potem boom, masz to. Podczas gdy trafiasz na serwer, musi on trafić do bazy danych może cztery lub sto razy tylko po to, aby zbudować to, co jest stroną, którą chcesz wyświetlić. To bardzo wolno.

Pomysł statyczny zyskuje na popularności.

Czy uważasz, że JavaScript może przyjąć „dojrzałe” języki (takie jak Java i C++) i stać się preferowanym językiem dla przedsiębiorstw?

Zdecydowanie. To, co ludzie robią teraz z węzłem „bezserwerowym” jest niezwykle skalowalne i myślę, że korporacyjne API [interfejsy programowania aplikacji] mogą i będą przepisywane w JavaScript, przynajmniej przez bardziej zwinne i myślące przyszłościowo korporacje.

Czego deweloper powinien szukać w kliencie?

Potrzebujesz pewnego poziomu zaufania i autonomii, zakładając, że jesteś wystarczająco starszy, by na to zasłużyć. Nie chciałbym podjąć pracy, w której ktoś cały czas patrzył mi przez ramię. Dużo czasu podczas prac programistycznych możesz mieć coś, co zajmuje pięć minut, aby naprawić, ale spędzasz cztery godziny pracując nad jakimś małym problemem z kompilacją, który sprawia, że ​​nie możesz go faktycznie przetestować. Często zdarza się, że spędzę osiem lub dziesięć godzin nad problemem — gdzie naprawdę pracuję, naprawdę skoncentrowany przez cały czas — a rzeczywiste rozwiązanie jest jak dwie linijki kodu. Potrzebujesz pracodawcy, który ma taki poziom zrozumienia, jak wygląda twoja praca.

O zespole oszusta, wypaleniu i odstresowaniu

Syndrom oszusta wydaje się być częstym zjawiskiem wśród deweloperów. Czy tego doświadczasz, a jeśli tak, to jak sobie z tym radzisz?

Absolutnie. Zwłaszcza podczas przemawiania na konferencji. (Albo robisz AMA?)

Jeśli chodzi o nauczanie/mentoring, musisz zdać sobie sprawę, że wiesz więcej o tym, co robisz, niż w zeszłym miesiącu. Ergo, zawsze są ludzie, którzy są z powrotem tam, gdzie byłeś, i którzy mogą skorzystać z Twojej wiedzy.

Ważne jest również, aby móc powiedzieć: „Nie wiem, zbadajmy to razem” (również dobra wskazówka dla rodziców).

Jak wygląda dzień w twoim życiu? Jak zaplanować to wszystko tak, że nie pracujesz 100 godzin tygodniowo i nie wypalasz się?

Kiedy byłem naprawdę głęboko w open source, zajmuje to dużo więcej czasu; czasami muszę wycofywać się na około miesiąc za każdym razem. Zabieram dzieci do szkoły, a potem spędzam czas przyglądając się, jakie problemy mają ludzie. Jeśli są naprawdę poważne, staram się je naprawić lub zareagować w pomocny sposób.

Mam codzienną pracę, która nie jest związana z open source, co zajmuje mi dużo czasu. Przez cały dzień mam ustawione powiadomienia, dzięki czemu mogę sprawdzić, czy jest z czymkolwiek poważny problem. Jeśli została wydana nowa funkcja lub coś takiego, w tym czasie jest bardziej prawdopodobne, że pojawią się błędy.

Dowiedziałem się, że każdy, kto pisze wymagania do projektu, jest pewien, że „powinno to być zrobione wczoraj, więc dlaczego jeszcze tego nie zrobiono?” Tyle razy zdarzało mi się, że niezależnie od tego, jaki zespół otrzymuje moją pracę, wdrożenie jej do produkcji zajmuje około trzech tygodni. A ty pytasz: „Cóż, o co chodziło w tym stresie?”

Jeśli zadanie musi zostać wykonane do piątku, a kończy się to do następnego piątku, prawie nigdy firma nie zamyka się, ponieważ nie udało ci się. Kiedy jesteś młody i nie znasz się lepiej, czujesz się jak: „O mój Boże, musimy to wynieść za drzwi”. Ale kiedy zrobisz to wystarczająco dużo razy i zobaczysz: „Chwileczkę, to, co nam mówili, nie było prawdą”, możesz powiedzieć: „Ok, tak. Cokolwiek. Zakończę, kiedy się skończy”.

Byłem trochę wypalony w październiku ubiegłego roku, kiedy React ogłosił coś o nazwie React Hooks. Gdybym tam był, gotowy do podjęcia wszelkich nowych rzeczy i biegania z tym, mógłbym wiele osiągnąć będąc jedną z pierwszych osób, które dostały się do React Hooks. W pewnym sensie nie spuszczam oka z tego, co może być następną wielką rzeczą.

Co robisz w wolnym czasie, aby zmniejszyć stres?

Chodzę na spacery i słucham podcastów, które nie dotyczą rozwoju.

Czy mógłbyś polecić?

Jedynymi prawdziwymi podcastami technicznymi, których słucham, są The Undefined Podcast, które tylko pośrednio zawierają wskazówki techniczne i dla programistów. Słucham też React Podcast – na którym wkrótce się pojawię (mam nadzieję, że ma to jakiś sens, w zależności od jakości ich edytora).

Patrząc na wybrany przeze mnie pod-catcher, Overcast, moje podcasty o najwyższym priorytecie obejmują:

• Roderick na linii
• Mieć sens
• Przypadkowy podcast techniczny
• Roboty drogowe
• Wykładnik potęgowy
• Witaj w Internecie
• Radiolab
• Odpowiedz wszystkim

Ostatnio sam zacząłem dwa podcasty:

Pierwsza nazywa się Seek Justice, w której ja, umiarkowanie inteligentna osoba, która prawie nic nie wie o systemie sądownictwa karnego, przeprowadzam wywiad z moim przyjacielem, który spędził całą swoją karierę na badaniu i pracy nad jego zreformowaniem. Pracuje bezpośrednio z gubernatorami kilku stanów USA w celu zmniejszenia liczby więźniów i recydywy po zwolnieniu z więzienia. To nie jest temat, który kiedykolwiek mnie interesował, ale mój współprowadzący urzeka mnie w każdym odcinku.

Drugi to spektakl czystej głupoty, zatytułowany Happy Hour z Dennisem i Erikiem, w którym ten sam przyjaciel i ja pijemy kilka wieczornych drinków, rozmawiamy o naszym życiu i wzajemnie się rozśmieszamy. Seek Justice jest na dojazdy do pracy o jasnych oczach, a Happy Hour na relaksującą jazdę do domu.

Aby przywrócić to programistom, moje starania dotyczące podcastów pomogły mi rozwiązać problem, na który nie mogłem znaleźć rozwiązania w branży: łatwy odtwarzacz MP3 z okładkami albumów, który działał również jako karta na Twitterze. Więc napisałem AudioCard.