Redux Form Kitaplığının Oluşturucusundan Tam Yığın Geliştirici İpuçları

Şubat 2019'da Toptal'ın topluluk ekibi yepyeni bir girişim başlattı: Toptal'ın ağ uzmanlarıyla gerçek zamanlı olarak etkileşim kurmak için aylık bir fırsat. Bana Her Şeyi Sor (AMA) oturumları, Toptal'ın çekirdek ekibinin ve yetenek ağının tüm üyelerine açıktır; herkes soru sorabilir. Bu parçada, JavaScript ve Redux uzmanı Erik Rasmussen ile bir AMA'dan seçilmiş soruları ve cevapları derledik. Erik, açık kaynaklı yazılım geliştirmenin zorluklarını, geliştirici ipuçlarını ve JavaScript'in dalgalanan dünyasını, rağbet gören bir geliştirici olarak imposter sendromu ve tükenmişlikle nasıl başa çıktığını ve en iyi podcast önerilerini tartışıyor.

Erik, React, Redux, React'te formlar ve GraphQL konusunda uzmanlaşmış, 25 yılı aşkın geliştirme deneyimine sahip tam kapsamlı bir JavaScript uzmanıdır. 28 milyondan fazla kullanıcıya sahip, sürüm kontrolü için web tabanlı bir barındırma hizmeti olan GitHub'da 20.000'den fazla yıldızla ilk 100'de yer aldı. Ayrıca React: Redux-Form ve React-Final-Form'daki birinci ve üçüncü en popüler form kitaplıklarının da yazarıdır.

Redux Formu ve Açık Kaynak Yazılımın Durumu

Redux Form'un ardındaki muazzam başarıdan sonra neden başka bir form kitaplığı oluşturmaya karar verdiniz?

Bu süreçte Redux Form ile birçok ders öğrendim ve dünyanın her yerindeki React Form geliştiricilerinin ihtiyaçları hakkında fikir edindim. React Form ile ilgili bazı problemler, probleme yeniden bakmadan çözülemezdi. (Daha fazla ayrıntı burada.)

Pek çok geliştirici, çok popüler bir açık kaynaklı proje yaratmanın hayalini kuruyor. Redux Form kadar başarılı bir projeye sahip olmanın beklenmedik sonuçlarından (iyi ve kötü) bazıları nelerdir?

Bir geliştiriciyi veya tüm ekibi bir projeyi tamamlamaktan alıkoyan bir hatayı düzeltebilmeniz son derece faydalıdır. İnsanların hataları kendileri bulup düzeltmeleri de gerçekten harika. Şimdiye kadar insanlar yardım istediklerinde çok kibar ve nazik davrandılar; Onlara bir düzeltme borçlu olduğumu düşünen doğru bir kullanıcıyla henüz bir etkileşimim olmadı.

Zorlu tarafında, tükenmişlik gerçek bir şeydir ve OSS geliştiricilerinin zamanlarını ve enerjilerini OSS projelerine harcadıkları için telafi etmenin bir yolunu henüz keşfetmedik. Redux Form, dünyanın her yerindeki milyar dolarlık şirketler tarafından iş yapmak için kullanılıyor ve varlığı, onu kuran ekipler için binlerce geliştirme saati kazandırdı, ancak yazarlara o paranın bir kıymığını bile vermenin iyi bir çözümü yok. .

Sizin gibi açık kaynak geliştiricileri telafi etmeye yönelik çalışmalarda umut verici çözümler var mı?

Bir arkadaşım CodeFund adında bir şirket kurdu. "Kod kitaplığı belgelerine reklam koyabilseydik ne olurdu?" gibi bir fikri vardı. Geliştiriciler olarak, tüm günümüzü belgelere bakarak ve yaptığımız şeyi nasıl uygulayacağımızı bulmaya harcıyoruz. Ayrıca geliştiriciler, ortalama bir web sörfçüsünden çok daha fazla para kazanıyor, bu nedenle biz lüks bir ürün potansiyeliyiz.

CodeFund, dokümantasyonun reklam yapmak için gerçekten harika bir yer olduğu fikrini ortaya attı. Ben orijinal pilotlardan biriydim. Oldukça iyi çalıştı ama GitHub ile ilgili bir sorunla karşılaştılar. Başlangıçta, GitHub deposunun kendisine reklamlar koyuyorduk, ancak GitHub ve avukatlar hızla araya girdi ve hayır dediler. Hangisi ayıp. CodeFund onlarla bir süre görüştü ama sonunda hayır dediler.

Ticareti iyi yapılmış kütüphane dokümantasyonu ile ayda belki 150 dolar kazanabilirsiniz, bu da değeri için ödeme yapmaz. Babble veya Webpack gibi bazı nadir kitaplıklar vardır; onlara, bu şeyi daha iyi hale getirmek için çalışan iki veya üç tam zamanlı geliştiriciyi gerçekten destekleyebilecekleri kadar para verilir. Babble ve Webpack—milyarlarca ve milyarlarca dolar değerindeki şirket altyapılarının üzerinde oturuyor ve kesinlikle Redux Form onları destekliyor.

Gittiğiniz hemen hemen her web sitesinde, kaynağa bakabilir ve düzgün bir şekilde tazmin edilmeyen belirli bir kişi tarafından yazılmış bazı kodları görebilirsiniz. İnsanları açık kaynağın ne olduğu ve bazılarımızın harcadığı saatler konusunda daha fazla takdir etmesini sağlamak için farkındalığın artırılması gerekiyor.

Neden açık kaynaklı ve ücretsiz bir şey yaratalım? Sizin gibi geliştiricileri teşvik eden nedir?

Onu yaratmanızın nedeni, şu anda üzerinde çalıştığınız şey ne olursa olsun ona ihtiyaç duymanızdır. Onu serbest bıraktığınızda, diğerleri gelir ve onu daha iyi hale getirir. Açık kaynak rüyası, "Taşlarımı buradan oraya taşımama yardımcı olan küçük bir el arabası yaptım" diyorsunuz ve sonra biri geliyor ve daha iyi hale getiriyor. Bir sonraki projenizde geri dönüyorsunuz ve aynı kütüphaneyi kullanıyorsunuz ve “Vay canına, bu şey çok daha hızlı hareket ediyor. Şimdi daha iyi."

Aynı zamanda çok ödüllendirici. İnsanlar, "Bu bizi üç haftadır oyalıyor ve üç saatinizi alan bu küçük düzeltme bize üç hafta zaman kazandırdı" dediğinde bir dopamin darbesi alıyorum. Bununla ilgili biraz bağımlılık döngüsü var, olumlu pekiştirme elde ediyorsunuz ve bu sadece iyi hissettiriyor.

İkinci form kitaplığımla, insanların “Hey, başka bir form kitaplığı istiyoruz” demesi o kadar fazla değildi, sadece onu daha iyi hale getirmenin bir yolunu düşündüm.

Bunu neden yaptığınızın bir nevi rüyası. Ama kesinlikle para için değil.

İdeal bir dünyada, açık kaynaklı yazılım oluşturmak için ne kadar ücret alırsınız? Sadece pastanın üzerine biraz krema mı?

Biri bana tüm gün boyunca açık kaynak üzerinde çalışmam için altı rakam ödese umurumda olmaz. Üretilen değere karşı maliyete bakarsanız, açık kaynak oranı çok yüksektir. Bir şeyi ve bir şeyi gerçekten çok iyi yapan küçük kütüphanelere inersiniz.

Dünyadaki her şirket bunu yapmak için kendi geliştirici ekibini atamak zorunda olsaydı, sonuçlar çok farklı olurdu. Açık kaynağa sahip olmamız ve bunun için tek bir çözüme sahip olmamız gerçeği – en üstte bir algoritma balonu en iyisi – dünyadaki herkesin bu verimliliğe sahip olduğu anlamına gelir.

Açık kaynaktan bir başka değer de, yazdığınız bir şeyi kullanıyorsanız ve yalnızca şirketinizin kullanmasıdır. . . Bunu 1000 şirketin kullandığı bir şeyle karşılaştırın. Potansiyel olarak bir sorun olabilecek böcek alanının her bir kuytu köşesini ve burcunu buldular ve bunu alıp şeyinize takıyorsunuz - altınsınız. Buna çok daha fazla güveneceksin.

JavaScript'in Dinamik Dünyası

JavaScript alanında bu kadar uzun süre bulunduktan sonra, [JavaScript uygulamaları oluşturmak için] pek çok sıcak yeni çerçevenin gelip gittiğini görmüş olmalısınız. Hangi çerçevelere bağlı kalacağınıza karar verebilmek için sektörün nabzını nasıl tutuyorsunuz?

Geliştirici topluluğunun rüzgarları için bir fikir edinmelisiniz. TypeScript ve Flow arasındaki mevcut savaş harika bir örnek. Facebook'un bir yazma çerçevesinin daha iyi bir koruyucusu olacağını varsayarak başlangıçta bu yarışta yanlış atı seçtim. Ama bence TS bu savaşı büyük ölçüde kazandı ve şimdi yavaş yavaş işleri o yöne kaydırıyorum.

Twitter'ın "geliştirici Twitter" diye bir köşesi var. Yeterince insanı takip ederseniz -belki yüz kadar bir örneklem büyüklüğüne ihtiyacınız vardır- rüzgarların nerede estiğine ve neyin popüler hale geldiğine dair bir fikir edinebilirsiniz. “Eskiden A kütüphanesini kullanırdım ama B kütüphanesini yeni öğrendim ve her şey çok daha kolay” gibi birçok gönderi alacaksınız. Bunlardan yeterince alıyorsunuz ve "Pekala, belki de şu diğer kütüphaneye bakmalıyım" diyorsunuz.

Eğilimler JavaScript alanında gelir ve gider. Her zaman hareket halinde mi olacak?

Bence (ve umuyorum) gelişmeye devam edecek. Durgunluk teknolojide ölümdür. Java bile şu anda önemli ölçüde yenilik yapıyor: Java 10'da yapabileceğiniz şeyler büyükannenizin Java 6'sına hiç benzemiyor.

Sonunda, tüm havalı çocukların Tech Y'yi kullandığını görmek için uygulamanızı Tech X ile oluşturmak çok yorucu olabilir. Ama içinde bulunduğumuz sektör bu.

Sizce, dile hakim olmak için gerçekten anlamak için hangi JavaScript kavramları özellikle önemlidir?

İşlevsel programlama ve işlevleri aktarma fikrinin oldukça önemli olduğunu söyleyebilirim. Özellikle Java veya C++ gibi bir dilden geliyorsanız.

React'in SPA'lar [tek sayfalı uygulamalar] oluşturmak için mi yoksa yalnızca normal bir sayfadaki bileşenler için mi kullanılması gerektiğini düşünüyorsunuz?

İşte React'in güzelliği: Çok yönlü. Günlük işimde eski bir Java/jQuery uygulamasındaki tüm yeni özellikler için yavaş yavaş React'i tanıtıyorum. React, üzerinde işlem yapılacak bir DOM düğümü verildiğinde gayet iyi çalışıyor. Tüm uygulamanın kontrolünde olması gerekmez.

Yeni bir React uygulaması başlatırken, sıfırdan düzenli olarak kullandığınız araçlar ve kitaplıklar nelerdir?

Bence create-react-app bu işte net kazanan. Dört yıl önce, böyle bir şey yokken çok daha zordu.

Tepki uygulamalarınızda uygulama durumunu nasıl ele alırsınız?

Redux çıktığında cevap açıkça buydu. Ancak, Redux “durumumun” çoğunun loading ve listOfObjects gibi şeyler olduğunu buldum ve son zamanlarda bu şeyler için Apollo GraphQL kullanıyorum. isSideNavOpen gibi diğer şeyler, bağlam tabanlı bileşenlerle oldukça kolay bir şekilde yönetilebilir. Bununla birlikte, Redux için hala bazı meşru kullanım durumları var, ancak hiçbiri basit React uygulamalarımda rastlamadım.

En sevdiğiniz editör/IDE hangisi?

Ah, o soru!

Java'dan geliyorum ve yıllardır JetBrains IntelliJ'den çok memnunum, ancak JS için biraz yavaş. Önce Atom'a gittim ama sonunda VS Koduna yerleştim. Jest ve Flow ve TypeScript için entegrasyonları rakipsizdir.

ruby JS'ye çeviren ve ardından Rubyst'lerin Pure Ruby'de (herhangi bir JS yazmadan) React/Flux yapılı uygulamalar yazma yolunu açan opal gibi izomorfik geliştirme hakkında ne düşünüyorsunuz?

JavaScript'in sunucuya atlamış olması bence büyük bir olay. Hem istemcide hem de sunucuda aynı kodla işleyebilmek çok büyük ve muhtemelen geleceğin yolu.

Mevcut en popüler JS çerçevelerimizin en büyük sorunu nedir sizce?

Tam olarak emin değilim, ancak Zeit gibi şirketlerin Next.js ile takip ettiği css-in-js, sunucusuz ve SSR'nin yönünü gerçekten seviyorum.

90'ların sonlarında web siteleri inşa eden biri olarak, statik web sitelerine geri dönüyor olmamız benim için gerçekten komik. Her şeyi derleme zamanında oluşturmaya geri dönüyoruz ve sonra sunucuda statik öğeleriniz var ve ardından yeniden nemlendirme dedikleri şeyle dinamik şeyler ekleyebilirsiniz. Tüm sayfayı oluşturduktan sonra, işleri gerçekten canlandırmak ve bileşenleri hareket ettirmek için ekstra JavaScript'i alabilirsiniz.

Zeit, Now çerçevesi ile web sitenize statik oluşturmayı da destekler, çünkü hiçbir şey statik bir HTML dosyasını indirmekten daha hızlı değildir. Bu sadece bir metin dosyası ve sonra bom, anladınız. Oysa bir sunucuya çarpıyorsanız, görüntülemeniz gereken sayfa ne olursa olsun oluşturmak için bir veritabanına belki dört veya yüz kez vurması gerekir. Bu süper yavaş.

Statik fikir popülerlik kazanıyor.

JavaScript'in "olgun" dilleri (Java ve C++ gibi) üstlenebileceğini ve işletmeler için tercih edilen dil haline gelebileceğini düşünüyor musunuz?

Kesinlikle. İnsanların şu anda "sunucusuz" düğümle yaptığı şeyler son derece ölçeklenebilir ve kurumsal API'lerin [uygulama programlama arayüzleri] JavaScript'te, en azından daha çevik ve ileri görüşlü şirketler tarafından yeniden yazılabileceğini ve yazılacağını düşünüyorum.

Bir geliştirici bir istemcide nelere dikkat etmelidir?

Bunu hak edecek kadar kıdemli olduğunuzu varsayarsak, size verilen bir güven ve özerklik düzeyi istiyorsunuz. Sürekli omzumun üzerinden birinin baktığı bir işe girmek istemem. Geliştirme çalışmasıyla çok fazla zaman, düzeltmesi beş dakika süren bir şeye sahip olabilirsiniz, ancak derlemeyle ilgili küçük bir sorun üzerinde dört saat çalışarak onu gerçekten test edemezsiniz. Bir probleme sekiz ya da on saatimi harcayacağım birçok zaman var - gerçekten çalıştığım, tüm zamanımı gerçekten odakladığım - ve asıl çözüm iki satır kod gibi. İşinizin neye benzediği konusunda bu düzeyde anlayışa sahip bir işveren istiyorsunuz.

Imposter Sendromu, Tükenmişlik ve Stres Atma Üzerine

Imposter sendromu, geliştiriciler arasında nadir olmayan bir fenomen gibi görünüyor. Bunu yaşıyor musunuz ve eğer öyleyse, bununla nasıl başa çıkıyorsunuz?

Kesinlikle. Özellikle bir konferansta konuşurken. (Ya da AMA yapıyor musunuz?)

Konu öğretim/mentorluk olduğunda, yaptığınız şey hakkında Geçen Ay yaptığınızdan daha fazlasını bildiğinizi anlamanız gerekir. Dolayısıyla, eskiden olduğun yere geri dönen ve bilginden faydalanabilecek insanlar her zaman vardır.

“Bilmiyorum, birlikte araştıralım” diyebilmek de önemlidir (ayrıca iyi bir ebeveynlik tüyosu).

Hayatında bir gün nasıl geçiyor? Haftada 100 saat çalışıp tükenmemek için her şeyi nasıl planlıyorsunuz?

Açık kaynağa gerçekten derinden girdiğimde, bu çok daha fazla zamanımı alıyor; bazen, bir seferde bir ay kadar geri çekilmem gerekiyor. Çocuklarımı okula götürüyorum ve sonra insanların ne tür sorunlar yaşadığına bakarak vakit geçiriyorum. Eğer gerçekten ciddilerse, onları düzeltmek veya yardımcı olacak şekilde yanıt vermek için biraz çaba harcarım.

Açık kaynakla hiç ilgisi olmayan, çok zamanımı alan bir günlük işim var. Gün boyunca, herhangi bir şeyle ilgili ciddi bir sorun olup olmadığını görebilmek için bildirimler ayarladım. Yeni bir özellik yayınlandıysa veya başka bir şey varsa, o zaman civarında hatalar olması daha olasıdır.

Bir proje için gereksinimleri yazan her kimse, "Bu dün yapılmalıydı, öyleyse neden hala yapılmadı?" diye kesin olduğunu öğrendim. İşimi hangi takım alırsa alsın, onu üretime geçirmenin üç hafta kadar sürdüğü pek çok kez yaşadım. Ve sen, "Peki, tüm bu stres ne içindi?"

Bir görevin Cuma gününe kadar yapılması gerekiyorsa ve bu, bir sonraki Cuma günü sona eriyorsa, başarısız olduğunuz için iş neredeyse hiç kapanmaz. Gençken ve daha iyisini bilmiyorken, "Aman Tanrım, bunu kapıdan çıkarmalıyız" gibi geliyor. Ama bunu yeterince kez yaptıktan sonra ve "Bir dakika, bize söyledikleri gerçekten doğru değildi" dedikten sonra, "Tamam, evet. Her neyse. Bittiğinde bitecek."

Geçen Ekim ayında React, React Hooks denen şeyi duyurduğunda biraz canım yanmıştı. Orada olsaydım, yeni bir şeyi alıp onunla koşmaya hazır olsaydım, React Hooks'a giren ilk insanlardan biri olmaktan çok yol kat edebilirdim. Bir sonraki büyük şey ne olabilir diye gözümü dört açıyorum.

Boş zamanlarında stresi azaltmak için ne yaparsın?

Yürüyüşlere çıkıyorum ve gelişimle ilgili olmayan podcast'leri dinliyorum.

tavsiye edebileceğiniz var mı?

Dinlediğim tek gerçek teknoloji podcast'leri, yalnızca teğetsel olarak teknoloji ve geliştirici ipuçlarıyla ilgili olan The Undefined Podcast'tir. Ayrıca yakında görüneceğim React Podcast'i de dinliyorum (umarım editörlerinin kalitesine bağlı olarak bir anlam ifade eder).

Pod alıcım olan Overcast'e bakıldığında, en öncelikli podcast'lerim arasında şunlar yer alıyor:

• Sıradaki Roderick
• anlamlandırmak
• Tesadüfi Teknoloji Podcast'i
• Yol çalışması
• üs
• Merhaba İnternet
• radyolab
• Hepsini cevapla

Son zamanlarda, aslında iki podcast'i kendim başlattım:

İlki, ceza adaleti sistemi hakkında neredeyse hiçbir şey bilmeyen orta düzeyde zeki bir kişi olarak, tüm kariyerini sistemi inceleyerek ve reform yapmak için çalışarak geçirmiş bir arkadaşımla röportaj yaptığım Adaleti Arayın. Hapishane nüfusunu ve tahliye sonrası tekrar suç işlemeyi azaltmak için birkaç ABD eyaletinin valileriyle doğrudan çalışıyor. Bu gerçekten ilgimi çeken bir konu değil ama yardımcı sunucum her bölümde beni büyülüyor.

İkincisi, Dennis ve Erik ile Happy Hour adlı, aynı arkadaşın ve benim akşamları birkaç içki içtiğimiz, hayatlarımız hakkında konuştuğumuz ve birbirimizi güldürdüğümüz saf bir aptallık gösterisi. Adaleti Arayın, parlak gözlü işe gidip gelmeniz içindir ve Happy Hour, eve gevşeme yolculuğunuz içindir.

Onu dev'e geri getirmek için, podcast çabalarım sektörde çözüm bulamadığım bir sorunu çözmeme yardımcı oldu: Twitter kartı olarak da çalışan albüm kapaklı kolay bir MP3 çalar. Bu yüzden AudioCard yazdım.