Kiat Pengembang Tumpukan Penuh dari Pembuat Pustaka Formulir Redux

Pada bulan Februari 2019, tim komunitas Toptal meluncurkan inisiatif baru: kesempatan bulanan untuk berinteraksi dengan pakar jaringan Toptal secara real time. Sesi Ask Me Anything (AMA) terbuka untuk semua anggota tim inti dan jaringan bakat Toptal—siapa pun dapat mengajukan pertanyaan. Dalam bagian ini, kami telah mengumpulkan pertanyaan dan jawaban terpilih dari AMA dengan pakar JavaScript dan Redux, Erik Rasmussen. Erik membahas tantangan pengembangan perangkat lunak sumber terbuka, kiat pengembang, dan dunia JavaScript yang berfluktuasi, bagaimana ia menangani sindrom penipu dan kelelahan sebagai pengembang yang banyak diminati, dan rekomendasi podcast teratasnya.

Erik adalah ahli JavaScript full-stack dengan lebih dari 25 tahun pengalaman pengembangan, yang mengkhususkan diri dalam React, Redux, formulir di React, dan GraphQL. Di GitHub—layanan hosting berbasis web untuk kontrol versi dengan lebih dari 28 juta pengguna—dia mendapat tempat di 100 teratas dengan lebih dari 20.000 bintang. Dia juga penulis perpustakaan formulir paling populer pertama dan ketiga di React: Redux-Form dan React-Final-Form.

Formulir Redux dan Status Perangkat Lunak Sumber Terbuka

Mengapa Anda memutuskan untuk membuat pustaka formulir lain setelah kesuksesan luar biasa di balik Formulir Redux?

Saya belajar banyak pelajaran di sepanjang jalan dengan Redux Form dan memperoleh wawasan tentang kebutuhan pengembang React Form di seluruh dunia. Beberapa masalah dengan React Form tidak dapat diatasi tanpa melihat masalahnya. (Lebih detail di sini.)

Banyak pengembang bermimpi membuat proyek sumber terbuka yang sangat populer. Apa saja konsekuensi tak terduga (baik dan buruk) memiliki proyek sesukses Formulir Redux?

Ini sangat bermanfaat ketika Anda dapat memperbaiki bug yang telah menahan pengembang atau seluruh tim dari menyelesaikan sebuah proyek. Ini juga sangat luar biasa ketika orang menemukan dan memperbaiki bug sendiri. Sejauh ini, orang-orang sangat baik dan ramah ketika mereka meminta bantuan; Saya belum pernah berinteraksi dengan pengguna yang benar yang berpikir saya berutang perbaikan kepada mereka.

Di sisi yang menantang, burnout adalah hal yang nyata, dan kami belum menemukan cara untuk mengkompensasi pengembang OSS karena memberikan waktu dan energi mereka untuk proyek OSS. Formulir Redux digunakan oleh perusahaan bernilai miliaran dolar di seluruh dunia untuk bertransaksi bisnis, dan keberadaannya telah menghemat ribuan jam pengembangan untuk tim yang telah menginstalnya, tetapi tidak ada solusi yang baik untuk memberikan sedikit pun uang itu kepada penulis .

Apakah ada solusi yang menjanjikan dalam pekerjaan untuk mengkompensasi pengembang sumber terbuka seperti Anda?

Seorang teman saya memulai perusahaan ini bernama CodeFund. Dia punya ide, "Bagaimana jika kita bisa memasang iklan di dokumentasi perpustakaan kode?" Sebagai pengembang, kami menghabiskan sepanjang hari untuk melihat dokumentasi dan mencari tahu bagaimana menerapkan hal apa pun yang kami lakukan. Plus, pengembang menghasilkan lebih banyak uang daripada rata-rata peselancar web Anda, jadi kami adalah potensi produk mewah.

CodeFund datang dengan gagasan bahwa dokumentasi adalah tempat yang sangat bagus untuk beriklan. Saya adalah salah satu pilot asli. Ini bekerja cukup baik tetapi mereka mengalami masalah dengan GitHub. Awalnya, kami memasang iklan di repositori GitHub itu sendiri, tetapi GitHub dan pengacara masuk dan mengatakan tidak. Yang memalukan. CodeFund bernegosiasi dengan mereka untuk sementara waktu, tetapi pada akhirnya mereka mengatakan tidak.

Dengan dokumentasi perpustakaan yang diperdagangkan dengan baik, Anda mungkin bisa mendapatkan $150 dolar sebulan, yang tidak sebanding dengan nilainya. Ada beberapa perpustakaan langka—seperti Babble atau Webpack—di mana ada cukup uang yang diberikan kepada mereka sehingga mereka benar-benar dapat mendukung dua atau tiga pengembang penuh waktu yang bekerja untuk membuat hal itu lebih baik. Babble dan Webpack—perusahaan bernilai miliaran dan miliaran dolar duduk di atas infrastruktur mereka dan yang pasti, Redux Form mendukung mereka.

Di hampir semua situs web yang Anda kunjungi, Anda dapat melihat di sumbernya dan Anda dapat melihat beberapa kode yang ditulis oleh satu orang tertentu yang tidak mendapatkan kompensasi yang semestinya. Kesadaran perlu ditingkatkan untuk membuat orang lebih menghargai apa itu open source dan jam-jam yang kita habiskan.

Mengapa membuat sesuatu yang open-source dan gratis? Apa insentif untuk pengembang seperti Anda?

Alasan Anda membuatnya adalah karena Anda membutuhkannya untuk apa pun yang sedang Anda kerjakan saat ini. Ketika Anda melepaskannya, orang lain datang dan membuatnya lebih baik. Impian sumber terbuka adalah Anda berkata, "Saya membangun gerobak dorong kecil yang membantu saya membawa batu saya dari sini ke sana," dan kemudian seseorang datang dan mereka membuatnya lebih baik. Pada proyek Anda berikutnya, Anda kembali dan Anda menggunakan perpustakaan yang sama dan Anda seperti, “Wah, benda ini bergerak jauh lebih cepat. Lebih baik sekarang.”

Ini juga sangat bermanfaat. Saya mendapat pukulan dopamin ketika orang berkata, "Ini telah menahan kami selama tiga minggu dan perbaikan kecil ini yang membutuhkan waktu tiga jam untuk Anda lakukan telah menyelamatkan kami dari waktu tiga minggu." Ada sedikit siklus kecanduan dengan itu, di mana Anda mendapatkan penguatan positif dan rasanya enak.

Dengan perpustakaan formulir kedua saya, bukan karena orang-orang berkata, "Hei, kami ingin perpustakaan formulir lain," hanya saja saya memikirkan cara untuk membuatnya lebih baik.

Itu semacam mimpi mengapa Anda melakukannya. Tapi itu pasti bukan untuk uang.

Di dunia yang ideal, berapa banyak kompensasi yang akan Anda terima untuk membuat perangkat lunak sumber terbuka? Hanya beberapa lapisan gula pada kue?

Saya tidak keberatan jika seseorang membayar saya enam digit hanya untuk bekerja di open source sepanjang hari. Jika Anda melihat nilai yang dihasilkan versus biaya, rasio untuk open-source sangat tinggi. Anda turun ke perpustakaan kecil kecil yang melakukan satu hal, dan satu hal dengan sangat, sangat baik.

Jika setiap perusahaan di dunia harus menugaskan tim pengembang mereka sendiri untuk melakukan itu, hasilnya akan sangat bervariasi. Fakta bahwa kami memiliki sumber terbuka dan kami dapat memiliki satu solusi untuk itu—satu gelembung algoritme di atas yang terbaik—berarti bahwa setiap orang di dunia memiliki efisiensi itu.

Nilai lain dari open source adalah jika Anda menggunakan sesuatu yang Anda tulis dan hanya perusahaan Anda yang menggunakannya . . . bandingkan dengan sesuatu yang digunakan 1.000 perusahaan. Mereka telah menemukan setiap sudut dan celah kecil dari ruang bug yang berpotensi menjadi masalah, dan Anda mengambil itu dan Anda memasukkannya ke dalam barang Anda—Anda adalah emas. Anda akan lebih percaya diri dalam hal itu.

Dunia Dinamis JavaScript

Setelah berada di ruang JavaScript begitu lama, Anda pasti telah melihat begitu banyak kerangka kerja baru [untuk membangun aplikasi JavaScript] yang datang dan pergi. Bagaimana Anda menjaga denyut nadi di industri sehingga Anda dapat memutuskan kerangka kerja apa yang harus dikomit?

Anda harus merasakan angin dari komunitas dev. Pertempuran saat ini antara TypeScript dan Flow adalah contoh yang bagus. Saya memilih kuda yang salah dalam balapan itu pada awalnya, dengan asumsi bahwa Facebook akan menjadi pelayan yang lebih baik dari kerangka kerja pengetikan. Tapi saya pikir TS telah cukup banyak memenangkan pertempuran itu, dan sekarang saya perlahan-lahan memindahkan hal-hal ke arah itu.

Ada sudut Twitter yang merupakan "Twitter pengembang." Jika Anda mengikuti cukup banyak orang—mungkin Anda memerlukan ukuran sampel sekitar seratus orang—Anda bisa merasakan ke mana angin bertiup dan apa yang menjadi populer. Anda akan mendapatkan banyak posting seperti, "Saya dulu menggunakan perpustakaan A, tetapi saya baru belajar tentang perpustakaan B dan semuanya jauh lebih mudah." Anda mendapatkan cukup dari itu dan Anda seperti, "Yah, mungkin saya harus memeriksa perpustakaan lain ini."

Tren datang dan pergi di ruang JavaScript. Apakah akan selalu bergerak?

Saya pikir (dan berharap) itu akan terus berkembang. Stagnasi adalah kematian dalam teknologi. Bahkan Java sedang berinovasi secara signifikan sekarang: Hal-hal yang dapat Anda lakukan di Java 10 tidak seperti Java 6 milik nenek Anda.

Mungkin melelahkan untuk akhirnya membuat aplikasi Anda dibuat dengan Tech X hanya untuk melihat bahwa semua anak keren sekarang menggunakan Tech Y. Tapi itulah industri tempat kita berada.

Menurut Anda, konsep JavaScript apa yang sangat penting untuk benar-benar dipahami untuk menguasai bahasa?

Saya akan mengatakan pemrograman fungsional dan gagasan untuk melewatkan fungsi cukup penting. Terutama jika Anda berasal dari bahasa seperti Java atau C++.

Apakah menurut Anda React harus digunakan untuk membangun SPA [aplikasi satu halaman] atau hanya untuk komponen di halaman biasa?

Itulah keindahan React: Sangat serbaguna. Saya perlahan-lahan memperkenalkan React untuk semua fitur baru di aplikasi Java/jQuery lama di pekerjaan saya. React berfungsi dengan baik jika diberikan node DOM untuk ditindaklanjuti. Itu tidak perlu mengendalikan seluruh aplikasi.

Saat memulai aplikasi React baru, alat dan pustaka apa yang biasa Anda gunakan dari awal?

Saya pikir create-react-app adalah pemenang yang jelas dalam hal ini sekarang. Empat tahun lalu, ketika tidak ada yang seperti itu, itu jauh lebih sulit.

Bagaimana Anda menangani status aplikasi di aplikasi reaksi Anda?

Ketika Redux keluar, itu jelas jawabannya. Namun, saya telah menemukan bahwa sebagian besar "status" Redux saya adalah hal-hal seperti loading dan listOfObjects , dan saya baru-baru ini menggunakan Apollo GraphQL untuk hal itu. Hal-hal lain seperti isSideNavOpen dapat dikelola dengan komponen berbasis konteks dengan cukup mudah. Yang mengatakan, masih ada beberapa kasus penggunaan yang sah untuk Redux, tetapi tidak ada yang saya temui di aplikasi React sederhana saya.

Apa editor/IDE favorit Anda?

Ah, pertanyaan itu !

Saya berasal dari Java, dan sangat senang dengan JetBrains IntelliJ selama bertahun-tahun, tetapi agak lambat untuk JS. Pertama saya pergi ke Atom, tetapi akhirnya menetap di VS Code. Integrasinya untuk Jest dan Flow dan TypeScript tidak terkalahkan.

Apa pendapat Anda tentang pengembangan isomorfik seperti opal yang menerjemahkan ruby ​​​​ke JS dan kemudian membuka jalur bagi Rubyst untuk menulis aplikasi terstruktur React/Flux di Pure Ruby (tanpa menulis JS apa pun)?

Fakta bahwa JavaScript telah membuat lompatan ke server, saya pikir, adalah masalah besar. Mampu merender dengan kode yang sama pada klien dan server sangat besar , dan kemungkinan besar merupakan cara di masa depan.

Menurut Anda apa masalah terbesar dari kerangka kerja JS terpopuler kami saat ini?

Saya tidak sepenuhnya yakin, tetapi saya sangat menyukai arah css-in-js, tanpa server, dan SSR yang dikejar oleh perusahaan seperti Zeit dengan Next.js.

Sangat lucu bagi saya, sebagai seseorang yang membangun situs web di akhir tahun 90-an, bahwa kami akan kembali ke situs web statis. Kami akan kembali menghasilkan semuanya pada waktu pembuatan, dan kemudian Anda mendapatkan barang-barang statis Anda di server dan kemudian Anda dapat menambahkan barang-barang dinamis dengan apa yang mereka sebut re-hydrating. Setelah seluruh halaman dirender, Anda bisa mendapatkan JavaScript ekstra untuk benar-benar membuat hal-hal menjadi animasi dan memindahkan komponen.

Zeit, dengan kerangka Now mereka, juga mendukung pembuatan statis ke situs web Anda, karena tidak ada yang lebih cepat daripada mengunduh file HTML statis. Ini hanya file teks dan kemudian boom, Anda mengerti. Sedangkan jika Anda memukul server, itu harus memukul database mungkin empat atau seratus kali hanya untuk membangun apa pun itu adalah halaman yang perlu Anda tampilkan. Itu sangat lambat.

Ide statis semakin populer.

Apakah Anda merasa bahwa JavaScript dapat menggunakan bahasa "dewasa" (seperti Java dan C++) dan menjadi bahasa pilihan untuk perusahaan?

Pastinya. Hal-hal yang dilakukan orang sekarang dengan node "tanpa server" sangat skalabel dan saya pikir API perusahaan [antarmuka pemrograman aplikasi] dapat dan akan ditulis ulang dalam JavaScript, setidaknya oleh perusahaan yang lebih gesit dan berpikiran maju.

Apa yang harus dicari pengembang di klien?

Anda ingin tingkat kepercayaan dan otonomi diberikan kepada Anda, dengan asumsi Anda cukup senior untuk layak mendapatkannya. Saya tidak ingin mengambil pekerjaan di mana seseorang melihat dari balik bahu saya sepanjang waktu. Banyak waktu, dengan pekerjaan pengembangan, Anda dapat memiliki sesuatu yang membutuhkan waktu lima menit untuk diperbaiki, tetapi Anda menghabiskan empat jam untuk mengerjakan beberapa masalah kecil dengan build yang membuatnya sehingga Anda tidak dapat benar-benar mengujinya. Ada banyak waktu di mana saya akan menghabiskan delapan atau sepuluh jam untuk suatu masalah—di mana saya benar-benar bekerja, benar-benar fokus sepanjang waktu—dan solusi sebenarnya seperti dua baris kode. Anda menginginkan majikan yang memiliki tingkat pemahaman seperti apa pekerjaan Anda.

Tentang Sindrom Penipu, Kelelahan, dan Menghilangkan Stres

Sindrom penipu tampaknya menjadi fenomena yang tidak biasa di kalangan pengembang. Apakah Anda mengalaminya, dan jika ya, bagaimana Anda menghadapinya?

Sangat. Terutama ketika berbicara di sebuah konferensi. (Atau melakukan AMA?)

Dalam hal mengajar/mentoring, Anda perlu menyadari bahwa Anda tahu lebih banyak tentang apa yang Anda lakukan daripada Bulan lalu yang Anda lakukan. Ergo, selalu ada orang yang kembali ke tempat Anda dulu yang dapat mengambil manfaat dari pengetahuan Anda.

Penting juga untuk dapat mengatakan, “Saya tidak tahu, mari kita selidiki bersama” (juga tip pengasuhan yang baik).

Seperti apa hari dalam hidupmu? Bagaimana Anda menjadwalkan semuanya sehingga Anda tidak bekerja 100 jam seminggu dan kelelahan?

Ketika saya benar-benar mendalami open source, itu membutuhkan lebih banyak waktu saya; kadang-kadang, saya harus mundur selama satu bulan atau lebih. Saya mengantar anak-anak saya ke sekolah dan kemudian saya menghabiskan waktu untuk melihat masalah seperti apa yang dialami orang-orang. Jika mereka benar-benar serius, maka saya akan berusaha untuk memperbaikinya atau merespons dengan cara yang membantu.

Saya memiliki pekerjaan harian yang tidak berhubungan sama sekali dengan open source, yang menghabiskan banyak waktu saya. Sepanjang hari, saya telah menyiapkan notifikasi sehingga saya dapat melihat apakah ada masalah serius dengan apa pun. Jika fitur baru telah dirilis atau semacamnya, kemungkinan besar ada bug di sekitar waktu itu.

Saya telah belajar bahwa siapa pun yang menulis persyaratan untuk sebuah proyek yakin bahwa, "Ini seharusnya sudah dilakukan kemarin, jadi mengapa belum selesai?" Saya telah mengalami begitu banyak waktu di mana tim mana pun yang menerima pekerjaan saya membutuhkan waktu tiga minggu untuk benar-benar memasukkannya ke dalam produksi. Dan Anda seperti, "Yah, tentang apa semua stres itu?"

Jika tugas harus diselesaikan pada hari Jumat, dan akhirnya selesai pada hari Jumat berikutnya, hampir tidak pernah bisnis ditutup karena Anda gagal. Ketika Anda masih muda dan tidak tahu apa-apa, rasanya seperti, "Ya Tuhan, kita harus mengeluarkan ini dari pintu." Tetapi setelah Anda melakukannya cukup lama, dan Anda melihat, "Tunggu sebentar, apa yang mereka katakan kepada kita tidak sepenuhnya benar," Anda bisa seperti, "Oke, ya. Apa pun. Itu akan selesai ketika selesai.”

Saya sedikit lelah Oktober lalu ketika React mengumumkan hal yang disebut React Hooks. Jika saya ada di sana, siap untuk mengambil hal baru apa pun dan menjalankannya, saya bisa mendapatkan banyak jarak dengan menjadi salah satu orang pertama yang masuk ke React Hooks. Saya agak mengawasi apa yang bisa menjadi hal besar berikutnya.

Apa yang Anda lakukan di waktu luang Anda untuk mengurangi stres?

Saya berjalan-jalan dan mendengarkan podcast yang bukan tentang pembangunan.

Adakah yang bisa Anda rekomendasikan?

Satu-satunya podcast teknologi nyata yang saya dengarkan adalah The Undefined Podcast, yang hanya membahas tentang tip teknologi dan pengembang. Saya juga mendengarkan React Podcast—di mana saya akan segera muncul (semoga masuk akal, tergantung pada kualitas editor mereka).

Melihat pod-catcher pilihan saya, Overcast, podcast prioritas utama saya meliputi:

• Roderick di Jalur
• Masuk akal
• Podcast Teknologi yang Tidak Disengaja
• Pekerjaan Jalan
• Eksponen
• Halo Internet
• laboratorium radio
• Membalas semua

Baru-baru ini, saya sebenarnya memulai dua podcast sendiri:

Yang pertama disebut Seek Justice, di mana saya, orang yang cukup cerdas yang hampir tidak tahu apa-apa tentang sistem peradilan pidana, mewawancarai seorang teman saya yang telah menghabiskan seluruh karirnya untuk memeriksa dan bekerja untuk mereformasinya. Dia bekerja secara langsung dengan gubernur beberapa negara bagian AS untuk mengurangi populasi penjara dan residivisme pasca-pembebasan. Ini bukan topik yang pernah benar-benar saya minati, tetapi rekan pembawa acara saya memikat saya setiap episode.

Yang kedua adalah pertunjukan kekonyolan murni, yang disebut Happy Hour dengan Dennis dan Erik, di mana teman yang sama dan saya mengambil beberapa minuman malam, berbicara tentang kehidupan kami, dan membuat satu sama lain tertawa. Seek Justice adalah untuk perjalanan Anda yang cerah ke tempat kerja, dan Happy Hour adalah untuk perjalanan pulang Anda yang santai.

Untuk mengembalikannya ke dev, upaya podcast saya telah membantu saya memecahkan masalah yang tidak dapat saya temukan solusinya di industri: pemutar MP3 yang mudah, dengan sampul album, yang juga berfungsi sebagai kartu Twitter. Jadi saya menulis AudioCard.