Biasanya, memulai dengan teknologi baru tidak sesederhana itu. Seorang pemula menemukan dirinya dalam lautan panduan pelatihan dan artikel yang tak ada habisnya. Selain itu, di balik masing-masing materi ini adalah pendapat pribadi penulisnya, dan masing-masing penulis mengklaim bahwa melalui mulutnya itulah kebenaran berbicara.
Dari sudut pandang akal sehat, jelas bahwa tidak semua artikel yang diterbitkan di Internet mampu memberikan manfaat nyata, sehingga mereka yang mencoba mempelajari sesuatu yang baru harus mengevaluasi publikasi dalam upaya menemukan jawaban atas pertanyaan apakah akan membelanjakannya. waktumu
Sebelum berangkat dengan kepala untuk belajar, programmer perlu memahami dasar-dasar teknologi yang menarik baginya. Maka Anda perlu membentuk visi Anda tentang teknologi ini, belajar untuk berpikir dalam hal itu. Akibatnya, jika seseorang mulai belajar Bereaksi, pertama-tama mereka harus belajar untuk "berpikir dalam Bereaksi." Dan setelah dia mengembangkan kualitas ini dalam dirinya sendiri, dia akan dapat berkenalan dengan pendapat orang lain dan, dengan memilih yang paling berharga, berkembang ke arah yang dipilih.
Penulis artikel, terjemahan yang kami terbitkan hari ini, ingin berbagi dengan semua orang yang ingin belajar tentang Bereaksi selama pembentukan visinya sendiri tentang teknologi ini, selama studi dan akumulasi pengalaman di bidang ini. Di sini dia akan berbicara tentang apa yang berhasil dia pahami dalam setahun, bekerja sebagai programmer-React, melakukan proyek sendiri di waktu luangnya dan berbagi ide-idenya dalam satu konferensi JavaScript.
Bereaksi adalah teknologi yang terus berkembang.
Karena React sedang dalam proses pengembangan konstan, siapa pun yang ingin menguasai teknologi ini harus siap untuk terus memperbarui pengetahuan dan keterampilan mereka. Jika Anda ingat pengumuman React 16.3.0, maka Anda tahu tentang antusiasme di komunitas programmer yang menghadirkan fitur-fitur baru. Di antara mereka adalah Konteks API resmi, API createRef dan forwardRef, mode ketat, dan perubahan dalam siklus hidup komponen. Tim inti pengembang Bereaksi dan semua orang yang telah membuat kontribusi yang layak untuk pengembangan proyek telah melakukan pekerjaan luar biasa, berusaha meningkatkan kerangka kerja favorit kami. Pekerjaan ini tidak berhenti. Jadi, misalnya, versi 16.4.0 memperkenalkan dukungan untuk
acara pointer .
Bereaksi terus berkembang, inovasi hanya masalah waktu. Di antara inovasi-inovasi ini adalah rendering asinkron, caching, banyak perubahan yang diharapkan dalam React 17.0.0, dan sesuatu yang tidak diketahui oleh siapa pun.
Mengingat hal di atas, jelas bahwa jika Anda ingin tetap berada di garis depan pengembangan Bereaksi, Anda perlu menyadari inovasi. Ini berarti bahwa Anda perlu tahu cara kerja mekanisme kerangka kerja baru, dan mengapa mekanisme itu dibuat. Anda perlu memahami masalah apa yang mereka pecahkan, dan bagaimana mereka menyederhanakan pengembangan.
Jangan takut untuk memecah kode Anda menjadi fragmen kecil
Bereaksi adalah berbasis komponen. Ini menunjukkan bahwa konsep ini harus digunakan dan dengan berani memecah potongan kode yang besar menjadi potongan yang lebih kecil. Terkadang komponen sederhana hanya terdiri dari 4-5 baris kode, dan, dalam beberapa kasus, ini benar-benar normal.
Anda harus mendekati fragmentasi kode sehingga jika pengembang baru terhubung ke proyek Anda, ia tidak perlu menghabiskan waktu berhari-hari untuk memahami cara kerja proyek ini dan cara kerjanya.
// , ? return ( [ <ChangeButton onClick={this.changeUserApprovalStatus} text="Let's switch it!" />, <UserInformation status={status}/> ] );
Anda tidak harus membuat komponen besar yang berisi semua logika yang diperlukan untuk pekerjaan mereka. Komponen, misalnya, hanya bisa menggambarkan representasi visual suatu entitas. Jika penggunaan komponen kecil akan meningkatkan keterbacaan kode, membuatnya lebih mudah untuk mengujinya dan memfasilitasi dukungan proyek di masa depan, maka aplikasi sistematis dari pendekatan ini adalah solusi luar biasa yang akan secara positif mempengaruhi pekerjaan masing-masing anggota tim.
import ErrorMessage from './ErrorMessage'; const NotFound = () => ( <ErrorMessage title="Oops! Page not found." message="The page you are looking for does not exist!" className="test_404-page" /> );
Contoh di atas menerapkan properti statis. Di depan kami adalah komponen bersih yang bertanggung jawab untuk menampilkan pesan kesalahan
Not Found dan tidak untuk yang lain.
Juga, jika Anda tidak ingin kelas CSS dan nama kelas muncul di mana-mana dalam kode Anda, saya akan merekomendasikan menggunakan komponen bergaya. Ini secara signifikan dapat meningkatkan keterbacaan kode.
const Number = styled.h1` font-size: 36px; line-height: 40px; margin-right: 5px; padding: 0px; `; //.. <Container> <Number>{skipRatePre}</Number> <InfoName>Skip Rate</InfoName> </Container>
Jika Anda takut membuat terlalu banyak komponen kecil karena Anda merasa bahwa file mereka menyumbat folder dengan material proyek, pikirkan tentang bagaimana menyusun kode Anda secara berbeda. Saya menggunakan
struktur fraktal proyek untuk mengatur materi, dan saya harus mengatakan bahwa ini luar biasa.
Jangan berpuas diri setelah memahami dasar-dasarnya.
Kadang-kadang Anda merasa bahwa Anda tidak cukup mengerti untuk melanjutkan studi dan menggunakan hal-hal yang lebih maju. Biasanya, sebagai suatu peraturan, Anda tidak perlu khawatir terutama tentang hal ini - mulailah untuk menguasai apa yang tampaknya terlalu rumit untuk Anda dan buktikan pada diri Anda bahwa Anda dapat mengetahuinya dan menggunakannya.
Misalnya, jika Anda berada di awal jalur pengembang Bereaksi, Anda mungkin menemukan banyak pola desain yang tampaknya rumit yang harus Anda jelajahi. Diantaranya adalah Komponen Kompon, Komponen Orde Tinggi, Alat Peraga Render, Komponen Cerdas, Komponen Bodoh dan banyak lagi (misalnya, disarankan untuk menguasai teknologi profiling kinerja komponen).
Kuasai semua teknologi ini, dan Anda akan mengerti - mengapa dan mengapa mereka digunakan. Sebagai hasil dari studi mereka, Anda akan menemukan bahwa sekarang lebih nyaman bagi Anda untuk mengembangkan proyek tentang Bereaksi.
// ? // , , . render() { const children = React.Children.map(this.props.children, (child, index) => { return React.cloneElement(child, { onSelect: () => this.props.onTabSelect(index) }); }); return children; }
Selain itu, jangan takut untuk menggunakan sesuatu yang baru dalam pekerjaan, secara alami, dalam batas yang wajar. Pada saat yang sama, jangan membatasi penggunaan pendekatan baru hanya untuk eksperimen dalam proyek yang Anda lakukan di waktu luang Anda.
Jika mereka yang bekerja dengan Anda memiliki pertanyaan tentang inovasi Anda, ketahuilah bahwa ini sepenuhnya normal. Bersiaplah untuk mempertahankan keputusan Anda dengan argumen kuat yang mendukung mereka.
Tujuan Anda haruslah untuk memecahkan masalah yang ada, menyederhanakan pengembangan lebih lanjut, atau hanya meningkatkan keterbacaan kode yang dulu terlihat tidak rapi. Bahkan jika proposal Anda, sebagai hasil diskusi dengan tim, ditolak, Anda setidaknya akan mempelajari sesuatu yang baru, dan ini jauh lebih baik daripada tidak menawarkan sesuatu yang baru dan tidak berkembang sebagai pengembang.
Jangan mencari proyek yang terlalu rumit
Mungkin rekomendasi ini bagi Anda tampaknya bertentangan dengan yang sebelumnya, yang ditujukan untuk eksperimen dengan teknologi baru, tetapi, pada kenyataannya, ini tidak demikian. Di mana-mana, dalam kehidupan, dalam pemrograman, kita membutuhkan keseimbangan. Jangan terlalu menyederhanakan sesuatu hanya untuk menunjukkan kepada orang lain kemajuan mereka sendiri. Yang terbaik adalah mendekati apa yang terjadi dalam hal kepraktisan. Tulis kode yang mudah dimengerti dan yang menyelesaikan tugas yang diberikan padanya.
Misalnya, jika Redux tidak diperlukan dalam proyek Anda, tetapi Anda ingin menggunakan perpustakaan ini hanya karena semua orang menggunakannya, dan Anda tidak benar-benar memikirkan tujuan menggunakan Redux, jangan lakukan ini. Lebih baik - berurusan dengan Redux, membangun pemahaman tentang teknologi ini, dan jika Anda melihat bahwa apa yang terjadi dalam proyek Anda bertentangan dengan apa yang Anda pahami, bersiaplah untuk mempertahankan sudut pandang Anda.
Kadang-kadang bagi Anda tampaknya bahwa dengan menggunakan teknologi terbaru dan membuat kode yang rumit, Anda memberi tahu seluruh dunia sesuatu seperti ini: “Saya bukan pengembang pemula, saya menjadi seorang profesional. Ini adalah kode yang saya tulis! "
Jujur, saya sendiri berada di awal karir seorang pengembang. Namun seiring berjalannya waktu, muncul kesadaran bahwa kode yang ditulis tanpa keinginan untuk membuktikan sesuatu kepada seseorang, kode di mana teknologi tidak digunakan hanya karena mereka dapat digunakan di dalamnya, tanpa alasan serius untuk menggunakan teknologi ini, membuatnya lebih mudah kehidupan pengembang mana pun. Inilah artinya:
- Tidak hanya orang yang mengerti desain proyek ini, tetapi juga anggota tim lain dapat mengerjakan proyek yang tidak rumit. Akibatnya, tugas pengembangan, perbaikan bug, pengujian, dan banyak lainnya, dapat diselesaikan tidak hanya oleh pencipta proyek ini.
- Pemrogram lain dapat memahami apa yang Anda lakukan tanpa menghabiskan terlalu banyak waktu mendengarkan penjelasan Anda. Anda dapat memperbaruinya dalam beberapa menit.
- Ketika pengembang utama, katakanlah, pergi liburan dua minggu, yang lain bebas untuk melakukan tugasnya, dan mereka tidak perlu menghabiskan seluruh hari kerja untuk apa yang dilakukan selama beberapa jam.
Orang baik kepada mereka yang tidak mempersulit hidup mereka. Jadi, jika Anda ingin dihormati oleh tim, dan bersikap baik dengan atasan Anda, cobalah menulis kode untuk tim, bukan untuk diri sendiri. Hasilnya, Anda akan menjadi orang yang mudah dan menyenangkan bekerja.
Refactoring tidak masalah
Anda, selama mengerjakan proyek tertentu, dapat mengubah sudut pandang Anda puluhan kali pada beberapa hal, dan manajer proyek bahkan dapat lebih sering merevisi pandangannya. Seseorang mengkritik apa yang Anda lakukan, dan Anda, jika kritik itu dibenarkan, mulailah mengubah sesuatu; Anda mengkritik karya orang lain, dan mereka, mendengarkan Anda, mengulang apa yang mereka tulis. Akibatnya, kode harus terus ditulis ulang.
Jangan menganggap ini sebagai sesuatu yang negatif. Mengingat bahwa pemrogram terus-menerus harus mempelajari sesuatu yang baru, refactoring sepenuhnya normal. Pengembangan biasanya merupakan jalur coba-coba. Dan semakin sering seseorang tersandung, bergerak di sepanjang jalan ini, semakin mudah baginya untuk mengatasi kesulitan dan melanjutkan.
Namun, untuk memastikan bahwa refactoring tidak berubah menjadi mimpi buruk, disarankan agar perhatian yang cukup diberikan pada tes. Jangan ragu untuk menguji semua yang bisa Anda capai. Mungkin setiap programmer telah mengalami, atau masih akan menghadapi situasi di mana tes yang baik akan membantunya menghemat banyak waktu. Dan jika Anda, seperti banyak orang lain, berpikir bahwa tes adalah buang-buang waktu, cobalah untuk mengambilnya berbeda dari sebelumnya. Yaitu, inilah manfaat yang diperoleh pengembang dan timnya dari pengujian yang baik:
- Anda tidak harus duduk bersama kolega untuk waktu yang lama, menjelaskan kepada mereka bagaimana semuanya bekerja.
- Anda tidak perlu menjelaskan alasan mengapa ada yang salah.
- Anda tidak harus memperbaiki kesalahan orang lain.
- Anda tidak perlu memperbaiki bug yang muncul beberapa minggu setelah rilis.
- Berkat organisasi pemeriksaan proyek yang tepat, Anda punya waktu untuk menyelesaikan berbagai masalah yang tidak terkait dengan kesalahan debug yang datang entah dari mana.
Bahkan, di sini hanya daftar kecil manfaat yang diterima seorang programmer dan rekan-rekannya dari sistem pengujian proyek yang terorganisir dengan baik.
Cinta untuk pekerjaan seseorang adalah dasar kesuksesan
Setahun yang lalu, saya memutuskan untuk menjadi pengembang Bereaksi yang lebih maju. Saya ingin, antara lain, berbicara di berbagai acara, untuk berbagi kegembiraan belajar hal-hal baru dengan orang lain.
Saya bisa duduk di depan komputer sepanjang malam, melakukan apa yang saya sukai dan menikmati setiap menit dari apa yang terjadi. Intinya di sini adalah bahwa jika seseorang benar-benar berjuang untuk sesuatu, maka, dengan satu atau lain cara, segala sesuatu di sekitarnya membantunya untuk mencapai tujuan. Sebagai contoh, baru-baru ini saya pertama kali berbicara di sebuah konferensi kecil di depan dua ratus penonton.
Selama waktu ini, saya tumbuh sebagai pengembang Bereaksi, belajar banyak. Secara khusus, ini berlaku untuk berbagai pola desain, prinsip pengembangan proyek, mekanisme kerangka kerja internal. Sekarang saya dapat berkomunikasi tentang topik-topik yang sebelumnya terasa tidak dapat diakses oleh saya, dan, lebih dari itu, saya dapat mengajar orang lain tentang apa yang tidak berani saya lihat sebelumnya. Pada saat yang sama, hari ini saya merasakan kesenangan dan kesenangan yang sama seperti setahun yang lalu.
Karena itu, saya akan merekomendasikan kepada semua orang untuk bertanya pada diri sendiri: "Apakah Anda suka apa yang Anda lakukan?" Jika jawaban untuk pertanyaan ini negatif, temukan apa yang benar-benar Anda sukai, sesuatu yang dapat Anda bicarakan berjam-jam, sesuatu yang dapat Anda lakukan siang dan malam, merasa benar-benar bahagia. Untuk tumbuh dan berkembang di bidang apa pun, semua orang perlu menemukan apa yang disukainya. Manusia tidak bisa dipaksa untuk berhasil dalam apa pun. Seseorang dapat berhasil hanya ketika dia secara sadar dan senang melakukan apa yang dia suka.
Jika saya bisa kembali setahun yang lalu dan bertemu diri saya di sana, saya akan mengatakan ini pada diri saya untuk mempersiapkan diri untuk jalan besar dan menarik yang menanti saya.
Pembaca yang budiman! Kiat apa, yang terinspirasi oleh pengalaman, yang bisa Anda bagikan dengan pengembang web pemula?
