Cara Mempekerjakan Pengembang Sudut: Keterampilan dan Pengetahuan Utama yang Harus Dicari

Dengan arsitektur yang sangat skalabel, banyak tim pengembangan web memilih Angular untuk membuat aplikasi satu halaman yang efisien dan canggih. Namun, mempekerjakan pengembang Angular lebih mudah diucapkan daripada dilakukan. Meskipun ada banyak kandidat di luar sana, kunci untuk pengalaman pengembangan yang mulus adalah menemukan pengembang Angular yang hebat , yang menerapkan praktik terbaik dan teknik lanjutan untuk memenuhi standar pengkodean berkualitas tinggi.

Memahami konsep kunci tentang kerangka kerja front-end populer Google akan mempersiapkan Anda untuk mewawancarai prospek dengan percaya diri dan merekrut pengembang berkaliber tertinggi—mereka yang berusaha membawa basis kode ke tingkat berikutnya. Artikel ini memaparkan keterampilan dan pengetahuan penting yang harus dimiliki oleh profesional Angular premium.

Catatan: Panduan ini berlaku untuk versi Angular terbaru, yang tidak lagi dikenal sebagai AngularJS—“Angular” telah diterapkan sejak Angular 2. Jika Anda menyewa untuk pemeliharaan atau peningkatan proyek aplikasi web AngularJS lawas (1.x cabang), lihat Cara Menyewa Pengembang AngularJS yang Hebat.

Ketahui Fungsi Inti Angular

Kerangka kerja Angular berjalan pada TypeScript , dan semua kode yang ditulis di dalam aplikasi ditranspilasikan ke JavaScript. TypeScript adalah superset dari JavaScript yang dikompilasi ke JavaScript biasa. Kode sudut diwakili oleh superset ini.

Banyak pengembang mempelajari Angular tetapi kurang memahami konsep inti yang dibutuhkan oleh JavaScript, TypeScript, HTML, atau CSS. Jika fondasi ini hilang, pengembang cenderung menggunakan solusi yang tidak tepat dan dengan demikian melipatgandakan utang teknis proyek.

Jadi, tanyakan kepada kandidat apakah mereka memiliki pengetahuan tentang HTML5 dan CSS3. Pengembang Angular yang baik tidak perlu menjadi ahli HTML atau CSS selama ada orang lain dalam tim, tetapi mereka harus memahami konsep-konsep kunci ini:

• kotak fleksibel
• variabel SCSS
• Perbedaan antara span dan div
• Kelas-kelas penting dalam CSS
• Atribut

Pengembang sudut harus memiliki pemahaman yang kuat tentang JavaScript dan TypeScript, serta beberapa keterampilan HTML dan CSS.

Menciak

Desain Sebelum Coding

Desain yang baik adalah kunci arsitektur aplikasi yang baik. Tanyakan kepada kandidat Anda bagaimana mereka membuat desain dan bandingkan pemikiran mereka dengan pertimbangan ideal berikut:

• Ke mana kode itu akan pergi? Apakah perlu perpustakaan atau modul baru?
• Apa input dan outputnya?
• Haruskah ada komponen atau arahan yang dapat digunakan kembali?
• Ke mana negara akan pergi? (Dibahas lebih lanjut di bawah Manajemen Negara di bawah.)
• Ke mana logika bisnis akan pergi—yaitu, di layanan mana?
• Bisakah komponen tertentu dibagikan di antara perpustakaan untuk membuat, pada dasarnya, sistem desain UI?

Spesifik penuh dari desain tertentu kurang penting daripada apakah kandidat memiliki kebiasaan membuat desain. Semua desain bersifat sementara sehingga, untuk sebagian besar aplikasi, dokumentasi dapat sesederhana foto sketsa di papan tulis kecuali jika diperlukan dokumentasi formal. Pada tahap selanjutnya, pengembang dapat menghasilkan desain teknis dari kode (dengan alat yang tepat) untuk memperjelas bagaimana semua bagian saling terkait.

Memahami Siklus Hidup Aplikasi Sudut

Tanyakan kepada kandidat Anda apa yang mereka ketahui tentang siklus hidup komponen Angular . Jawaban mereka harus mencakup tiga kait siklus hidup: ngOnInit , ngOnChanges , dan ngOnDestroy . Seperti namanya, ngOnInit dipanggil saat inisialisasi komponen, ngOnDestroy dipanggil saat komponen dihancurkan, dan ngOnChanges dipanggil saat atribut berubah. Yang terakhir dapat terjadi sebelum ngOnInit —ketika atribut sudah ditetapkan sebelum komponen sepenuhnya diinisialisasi, maka ngOnChanges dieksekusi sebelum ngOnInit .

Jika kandidat juga mengetahui tentang ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit , dan ngAfterViewChecked , mereka mengetahui semua kait deteksi perubahan untuk komponen dan selangkah lebih maju.

Pertanyaan tindak lanjut yang bagus untuk ditanyakan tentang salah satu kait: "Kapan deteksi perubahan ini terjadi?"

Siklus hidup yang kurang dikenal adalah siklus hidup penyedia , yang hanya memiliki satu kait: ngOnDestroy . Ini dipanggil hanya jika penyedia terpasang di tingkat komponen, dalam hal ini penyedia akan dihancurkan bersama dengan komponen. Jika disediakan di tingkat root atau modul, itu tidak akan pernah dihancurkan.

Konstruktor dari sebuah provider akan dieksekusi pertama kali provider tersebut digunakan, sehingga ada kemungkinan konstruktor tersebut tidak akan pernah dieksekusi. Kuis kandidat Anda tentang kemungkinan ini—dalam skenario dunia nyata, ini bisa menjadi sumber bug yang sering diabaikan!

Pengetahuan yang Kuat tentang Pemrograman Reaktif

Dalam aplikasi Angular, pemrograman reaktif seringkali merupakan bagian tersulit untuk dipahami. Banyak orang berpikir dengan cara prosedural ketika mereka mulai memprogram sepotong kode, dengan asumsi bahwa itu lebih mudah untuk dipahami dan dikerjakan, seperti langkah-langkah resep.

Pemrograman reaktif melibatkan reaksi terhadap hal-hal yang tidak dapat kita kendalikan, dan itu mungkin terjadi dalam urutan yang tidak terduga. Meskipun kita bereaksi terhadap hal-hal dengan cara ini setiap hari—misalnya, mengerem ketika mobil di depan kita tiba-tiba berhenti—banyak pengembang merasa sulit untuk mengambil pendekatan reaktif terhadap pemrograman.

Tapi, semua yang terjadi di dalam aplikasi Angular didasarkan pada pemrograman reaktif. Beberapa contoh reaktivitas di dalam aplikasi belanja Angular, misalnya, dapat mencakup:

• Saat pengguna masuk, nomor pada ikon keranjang belanja diperbarui, dan item menu berubah menjadi opsi yang lebih spesifik.
• Saat pengguna menavigasi ke suatu kategori, produk diperbarui tergantung pada kategori yang dipilih.
• Saat pengguna menambahkan produk ke keranjang mereka, ikon keranjang belanja diperbarui dengan jumlah produk.
• Saat item kehabisan stok (terdaftar melalui pendengar yang memantau jumlah stok saat ini dari bagian belakang), UI halaman diperbarui.

Perhatikan bahwa hal-hal ini terjadi secara otomatis, dan tidak perlu penyegaran halaman untuk muncul. Dalam sebuah wawancara, mintalah kandidat untuk menjelaskan bagaimana mereka menerapkan pemrograman reaktif dalam aplikasi yang mereka kembangkan. Jika kandidat menjelaskan solusi yang melibatkan penyegaran halaman atau secara manual memanggil ChangeDetectorRef.detectChanges() untuk menyegarkan komponen, anggap itu sebagai bendera kuning.

Jebakan Dengan Observables di Angular

Pengembang yang kurang berpengalaman terkadang menemukan bahwa kode yang mereka tulis di aplikasi Angular mereka tidak dieksekusi. Pengembang Angular berpengalaman dapat mengidentifikasi penyebab umum: Tidak ada langganan pada Observable , jenis objek andalan dalam pemrograman reaktif. Hanya dengan berlangganan panggilan back-end atau reaksi lainnya akan dieksekusi.

Ada dua cara untuk membuat langganan: Pengembang dapat menggunakan pipa async atau metode subscribe . Tetapi ada peringatan: Jika pengembang melakukan langganan manual (dengan metode subscribe ), Observable perlu dihancurkan secara manual (walaupun ada beberapa kasus tepi yang terjadi secara default). Pengembang dapat menghancurkan Observables dengan berbagai cara:

• Menggunakan pipa async , jika memungkinkan (ini menghancurkan Observable ketika komponen tidak lagi diperlukan).
• Berhenti berlangganan secara manual dengan menggunakan metode unsubscribe pada Observable di akhir masa pakai komponen ( ngOnDestroy ).
• Dengan cara yang lebih deklaratif dengan operator takeUntil di dalam operator pipe , dan menggunakan subjek (yaitu, sesuatu yang bernama seperti destroy$ ). Dalam hal ini, subjek memancarkan destroy$.next() di akhir masa pakai komponen ( ngOnDestroy ). Setelah menerima peristiwa penghancuran, operator takeUntil tidak akan lagi menerima peristiwa dari Observable yang terikat padanya sehingga logika pelanggannya tidak lagi terpicu. Sebagai contoh, lihat operator takeUntil di bagian 2. Fungsionalitas serupa dapat diekspos dengan operator take dan takeWhile .
• Karena aplikasi Angular beralih ke kompiler Ivy, kami juga dapat menggunakan anotasi. Pustaka until-destroy atau pustaka pihak ketiga lainnya seperti SubSink dapat digunakan untuk berhenti berlangganan dengan lancar dari yang dapat diamati setelah komponen dihancurkan.

Titik nyeri potensial lainnya dengan pemrograman reaktif berasal dari kebocoran memori dan beberapa panggilan ke bagian belakang. Tanyakan kepada kandidat apakah mereka mengetahui masalah ini, dan bagaimana mereka biasanya menyelesaikannya. Kebocoran memori dapat terjadi karena gagal berhenti berlangganan dari Observable s seperti yang dijelaskan di atas. Beberapa panggilan ke back-end karena beberapa langganan pada panggilan back-end dapat diselesaikan dengan membagikan Observable .

Ketahui Status dan Cara Menggunakannya

Semua aplikasi satu halaman memiliki status, dan status ini tersedia di suatu tempat di ujung depan. Tapi apa sebenarnya negara itu? Ini berisi semua variabel khusus untuk pengalaman pengguna saat ini. Misalnya, detail pengguna yang diautentikasi seperti nama dan URL gambar profil, item menu tertentu yang dipilih, atau daftar di layar seperti daftar item keranjang belanja.

Dalam aplikasi Angular, ada tiga jenis utama status front-end yang perlu dipertimbangkan:

Pemahaman yang baik tentang keadaan itu, dan kapan harus dimuat atau dimuat ulang, adalah salah satu keterampilan utama yang harus dicari saat mempekerjakan pengembang Angular. Ini adalah wilayah utama untuk dijelajahi jika tim Anda memiliki kesempatan untuk meninjau beberapa contoh kode yang ditulis oleh kandidat. Jika pemohon menggunakan perpustakaan untuk pengelolaan negara:

• Cari penggunaan NgRx, Akita, NgXs, atau library khusus manajemen negara yang serupa.
• Kemudian lihat untuk melihat apakah ada pemberitahuan untuk effects , action , reducer , store , dan selector dalam kode terkait.

Mari kita lihat alur umum status aplikasi di NgRx (yang mirip dengan Akita dan perpustakaan lainnya) sebagai contoh:

Jika pengembang membuat statusnya sendiri dengan layanan, kompetensi mereka dalam manajemen status bisa lebih sulit untuk diidentifikasi:

• Cari referensi untuk kata-kata state atau effect .
• Lihat apakah kode bereaksi terhadap beberapa tindakan, misalnya, jika pengguna menekan Tombol A, teks akan berubah di Layar B.

Pertanyaan untuk Pewawancara untuk Ditanyakan Tentang Negara

Anda tidak selalu dapat menemukan semua yang perlu Anda ketahui dengan menyelidiki kode pelamar. Tambahkan kueri ini ke daftar pertanyaan Anda untuk menyelidiki seberapa baik potensi pengembang Angular memahami status:

• Di mana Anda menggunakan state —dan bagaimana caranya? Ini adalah titik awal yang kuat untuk memahami pengalaman mereka dengan negara; jangan takut untuk menyelidiki secara spesifik.
• Bagaimana Anda membuat keputusan apakah akan menggunakan perpustakaan atau tidak? Ini pertanda baik jika mereka tahu tidak selalu berguna untuk menyertakan perpustakaan negara dalam aplikasi.
• Apa yang akan Anda masukkan ke dalam negara bagian, di mana Anda akan meletakkannya, dan bagaimana Anda menggunakan sistem manajemen negara bagian? Jika mereka mengatakan, "Saya memasukkan semuanya ke dalam status aplikasi global saya," ini adalah tanda pasti bahwa pengembang tidak menyadari efek samping negatif yang dapat diberikan sistem seperti itu pada aplikasi.

Pengembang yang memahami berbagai jenis status akan menghindari efek samping ini:

• Status yang hanya berlaku untuk satu komponen dapat dimodifikasi atau dirusak oleh komponen lain.
• Data bersarang di toko, sehingga menjadi sulit untuk melacak data, dan data menjadi tidak dapat dibaca manusia (untuk keperluan debugging, pertukaran data, dll.).
• Mengedit data di dalam formulir sudah memancarkannya ke seluruh aplikasi, padahal seharusnya hanya didorong ke penyimpanan saat menyimpan data—dengan kata lain, aplikasi lainnya mungkin menggunakan data yang tidak valid.

Tidak butuh waktu lama sebelum toko global menjadi berantakan, dan tidak jelas dari mana setiap bagian dari kekacauan itu berasal, sehingga lebih sulit untuk di-debug dan dirawat.

Memahami Pentingnya Pengujian Otomatis

Pengujian otomatis harus dianggap sama pentingnya dengan kualitas kode untuk aplikasi web Angular apa pun. Salah satu alasan utama programmer menulis tes adalah untuk mendokumentasikan kode mereka: Jika pengembang baru bergabung dengan perusahaan, logika bisnis dan alur UI tertentu harus jelas berdasarkan ekspektasi rangkaian pengujian. Selain itu, pengujian otomatis mengungkapkan bug di awal pengembangan.

Ajukan tiga pertanyaan pengujian kepada pengembang Angular potensial Anda:

• Apa pendapat Anda tentang pengujian? Setiap kandidat yang tidak peduli dengan pengujian otomatis harus berhenti dipertimbangkan. Bahkan jika mereka memilih untuk tidak menggunakan pengembangan berbasis pengujian (TDD), pengembang yang gagal melihat nilai pengujian otomatis akan menghabiskan waktu pengujian manual perusahaan Anda dan, lebih buruk lagi, waktu henti pengguna akhir saat regresi muncul saat perubahan dilakukan pada aplikasi lembur.
• Apa yang Anda fokuskan saat menguji? Daripada menguji pemberian dasar seperti dapat menetapkan nilai ke bidang atau berjuang untuk metrik cakupan pengujian tertentu (yaitu, cakupan 85%), pengembang Angular yang hebat harus fokus pada pengujian logika bisnis inti.
• Apakah biasanya ada lebih banyak tes E2E atau lebih banyak tes unit? Mengapa? Sebagai aplikasi front-end, aplikasi Angular dapat memanfaatkan dua jenis pengujian otomatis utama: pengujian unit dan pengujian ujung-ke-ujung (E2E). Biasanya, rangkaian pengujian akan memiliki banyak pengujian unit dan lebih sedikit pengujian E2E. Tes unit berukuran kecil, sehingga cepat untuk ditulis dan dijalankan. Tes E2E lebih besar dan lebih lambat. Peringatan yang adil: Tidak semua pengembang akan memiliki pendapat yang sama tentang rasio unit dan tes E2E yang benar untuk dipertahankan. Pada kenyataannya, itu tergantung pada kompleksitas aplikasi yang sedang diuji, dan meskipun demikian, jawabannya masih bisa diperdebatkan sampai batas tertentu.

Kerangka Pengujian Sudut

Pengembang sudut memiliki pilihan dalam hal kerangka pengujian otomatis. Pengujian unit dapat dilakukan melalui Jest atau Jasmine dan Karma. Setiap pengembang Angular harus akrab dengan Jasmine dan Karma. Bercanda juga umum—umumnya lebih cepat dan menampilkan opsi pengujian yang lebih canggih.

Standar pengujian E2E untuk aplikasi Angular adalah Protractor, alat default yang dihasilkan oleh Angular CLI. Alternatifnya adalah Cypress, kerangka pengujian E2E yang menjanjikan dengan banyak opsi.

Pastikan kandidat memiliki pengetahuan mendalam tentang setidaknya satu kerangka kerja pengujian unit dan satu kerangka kerja pengujian E2E.

Tetap Terinformasi Tentang Rilis Angular Terbaru

Pengembang Angular yang hebat mungkin tidak selalu menggunakan versi terbaru dalam pengembangan karena berbagai alasan, tetapi mereka harus mengetahui jadwal rilis Angular sehingga mereka dapat tetap mengikuti perubahan dan bersiap untuk beralih. Salah satu cara untuk menilai ini adalah dengan menanyakan kandidat apakah mereka terbiasa dengan strategi rilis Angular. Angular bertujuan untuk rilis besar setiap enam bulan, biasanya sekitar Februari dan Mei. Rilis Angular berada di bawah "dukungan aktif" selama enam bulan pertama setelah tanggal rilisnya, dan berada di bawah "dukungan jangka panjang" selama 12 bulan setelah tanggal rilisnya. Ini adalah garis waktu yang cukup ketat dibandingkan dengan beberapa teknologi lain, sehingga sangat penting untuk tetap terkini.

Anda mungkin juga melakukan riset tentang versi Angular terbaru, dan bertanya kepada kandidat Anda tentang manfaat fitur baru ini. Misalnya, sekitar waktu Angular 14 dirilis, Anda mungkin bertanya kepada kandidat tentang:

• Komponen mandiri, yang mengurangi kebutuhan akan modul Angular. Komponen mandiri tidak dideklarasikan di NgModule yang ada, dan mereka secara langsung mengelola dependensinya sendiri. Akibatnya, mereka dapat diandalkan secara langsung tanpa memerlukan NgModule perantara.
• Formulir yang diketik, pembaruan besar lainnya di Angular 14, yang menetapkan pengetikan ketat sebagai default untuk Angular Reactive Forms. Formulir yang diketik memastikan bahwa nilai di dalam FormControls , FormGroups , dan FormArrays aman untuk tipe di seluruh permukaan API. Ini memungkinkan bentuk yang lebih aman, terutama untuk kasus kompleks yang sangat bersarang.

Pengembang Sudut Hebat Berikutnya untuk Tim Front-end Anda

Setiap proyek dan tim pengembangan web berbeda dan akan menempatkan kepentingan yang berbeda pada berbagai aspek keterampilan dan pengetahuan pengembang Angular. Tetapi memahami topik dasar yang kami sajikan di sini akan memungkinkan manajer perekrutan untuk berpartisipasi secara bermakna dalam perekrutan—bahkan dalam evaluasi yang lebih teknis.

Blog Toptal Engineering mengucapkan terima kasih kepada Ramazan Yildiz karena telah meninjau konsep dan diagram teknis yang disajikan dalam artikel ini.