Hai, saya ingin berbagi pengalaman dalam mengembangkan test case untuk Aviasales.
Baru-baru ini saya menemukan pekerjaan pengembang React di Aviasales. Saya mengirim aplikasi, setelah itu hari berikutnya HR menjawab saya dan memberi tahu saya bahwa saya harus melakukan tugas tes. Saya benar-benar tidak suka melakukan tugas tes, karena saya harus menghabiskan cukup banyak waktu untuk implementasi mereka, dan jika terjadi kegagalan ini akan sia-sia. Tapi saya setuju ...
Anda dapat menemukan tugas tes di sini di tautan .
Ini adalah tautan ke repositori saya tentang tugas yang diselesaikan.
Saya membatasi diri dalam menyelesaikan tugas dalam satu hari (walaupun saya memang membuat sedikit perbaikan setelah publikasi: saya selesai membuat sketsa, jadi untuk berbicara).
Apa yang saya pilih untuk pengembangan:
- Saya memilih NextJS sebagai dasar, karena saya tidak ingin mengotak-atik pengaturan lingkungan untuk Webpack, dan Anda dapat menggunakan proyek itu sendiri dengan beberapa klik.
- Saya ingin menulis cepat dan memilih paket React-IOC bersama dengan MobX, bukan Redux. Ini adalah paket yang memungkinkan Anda untuk menulis aplikasi melalui layanan yang menyerupai layanan sudut.
- Saya menggunakan Web Worker sehingga tidak ada jeda di antarmuka saat menyortir sejumlah besar data.
- Saya tidak menggunakan naskah untuk tujuan tidak menulis kode tambahan dengan membuang waktu yang tidak berguna pada tugas tes.
- Berdasarkan paragraf 4, saya juga tidak menulis tes.
- Saya menambahkan dua paket tambahan ke proyek: debounce, RxJS. Yang pertama diperlukan untuk membuat panggilan balik sederhana, misalnya, mengubah status unduhan sehingga pemintal tidak menampilkan beban jika unduhan hanya memakan sedikit waktu. Saya selalu menggunakan paket kedua untuk membuat skrip tindakan, misalnya, untuk memproses status jika terjadi kesalahan saat mengirim permintaan ke server.
Prosedur untuk tahap pertama pengembangan:
- Repositori diinisialisasi.
- Proyek NextJS yang diinisialisasi.
- Menambahkan halaman basis indeks dengan pesan Hello World.
- Membuat layanan tiket.penyedia yang berinteraksi dengan server api.
- Menciptakan layanan ticket.service, yang menyuntikkan ticket.provider dan mengisi pengamat dengan berbagai tiket yang ditampilkan
- Dibuat ticket.filter.service, yang menyimpan data yang difilter yang disuntikkan dari ticket.service melalui @computed
Tahap kedua pengembangan:
- Membuat komponen dan gaya melukis untuk mereka menggunakan tata letak yang disediakan dalam repositori tugas.
- Saya membuat spinner unduhan dan meletakkan nilainya dari layanan.
- Menghubungkan semua logika layanan dengan komponen.
- Utilitas yang ditambahkan dengan pemformatan data, seperti waktu dan uang.
Kemudian saya memutuskan untuk mencoba antarmuka "sentuh" dan menemukan kekurangan saat menggunakan aplikasi:
- Ada perlambatan antarmuka saat mengubah filter dan penyortiran, jadi saya mentransfer penyimpanan, pengambilan, dan penyaringan data ke Web Worker, setelah itu kelambanan benar-benar hilang.
- Spinner tidak memperbaiki animasi garis lompat, jadi saya menggantinya dengan tampilan garis visual dengan animasi yang berkedip-kedip.
- Untuk memudahkan rendering data, saya mentransfer panggilan pemformatan data ke Web Worker, ini mengurangi beban rendering komponen
Kemudian saya menyelesaikan pekerjaan saya dan pada akhirnya mengirim tugas untuk verifikasi.
Karena saya membatasi waktu, saya tidak mengoptimalkan aplikasi lebih lanjut, yaitu, saya tidak menggunakan React.memo (...). Saya juga tidak mulai mengganti jendela dan router dengan injector dalam layanan. Maafkan saya untuk ini, ini cacat.
Tetapi hari berikutnya saya menambahkan fungsi mengingat keadaan filter di baris url browser, setelah itu saya sudah puas dengan pekerjaan yang dilakukan.
Saya menunggu jawaban dari mereka selama 7 hari, mereka tidak membalas pesan saya. Untuk itu, itu adalah pengalaman yang tidak menyenangkan. Tetapi mereka tetap menjawab, dan jawabannya sangat sulit dibaca. Pesannya bisa dilihat di bawah.
Mari kita lihat poin-poinnya:
[1]. “Pekerjaan itu dilakukan dengan sangat hati-hati”
Saya tidak melihat di mana, bukan argumen, karena tidak ada contoh.
[2]. "Tampaknya pengembangan mengejar tujuan" itu bekerja, "dan mengabaikan" cara kerjanya. "
Bukan argumen, tidak ada contoh.
[3]. "Berdasarkan persyaratan kami untuk tingkat kandidat, tugas yang diselesaikan hampir tidak mencapai tengah."
Apa saja persyaratannya? Dimana mereka?
[4]. “Kami berharap bahwa filter tidak akan di-hardcode dan akan beradaptasi dengan data. Jika Anda pergi ke aviasales, Anda dapat melihat bahwa tiket ditampilkan segera saat angsuran pertama muncul, dan kami tidak menunggu semua orang memuatnya. "
Persyaratan ini tidak ada dalam tugas terlampir. Dan aplikasi Aviasales sendiri, menurut saya, tidak memiliki antarmuka referensi, dan melompat tiket bukan solusi terbaik.
[5]. “Mengapa filter.service tahu tentang router dan jendela? Dia seharusnya tidak mengontrol keadaan aplikasi dan memiliki ketergantungan seperti itu sama sekali. "
Karena layanan dibuat untuk mengontrol keadaan seluruh aplikasi, atau modul tempat mereka ada. Di sini penulis jelas menyarankan untuk menulis semua logika dalam komponen.
[6]. “Pekerja Web. Apa untungnya? Dalam hal ini, banyak waktu dihabiskan untuk operasi asinkron, dan beban yang disimpan di utas utama dihabiskan untuk membuat objek bersambung / deserialisasi (dan objek yang dapat diobservasi). Jika kita berbicara tentang optimalisasi, maka itu layak dimulai bukan dengan penghapusan pada pekerja web, tetapi memperbaiki masalah di utas utama. "
Bagaimana saya bisa menangani pemrosesan data dalam jumlah besar di utas utama dan pada saat yang sama tanpa kelambatan antarmuka? Akan sangat menarik bagi saya untuk mengetahui apakah ada yang punya contoh, lalu tulis di komentar. Rupanya saya kehilangan sesuatu.
[7]. "Tidak masuk akal untuk menambahkan rxjs ke proyek hanya untuk menerapkan coba lagi dan pemuatan berurutan."
Mengapa itu tidak masuk akal? Anda dapat mengimpor fungsi yang sangat diperlukan ke dalam RxJS, jika paket dan fungsi pengocokan pohon tidak berfungsi dengan baik, ini tidak akan menambah ukuran aplikasi.
[8]. “Proyek tidak dapat ditingkatkan dan dipertahankan. Konstruk seperti (ticket.segments || [{}, {}]).map((ticket) => ...) sangat rumit. "
Mari kita lihat kriteria penskalaan dan dukungan: aksesibilitas (layanan menyelesaikan masalah ini), risiko ( ticket.segments || [{}, {}] hanyalah contoh bagaimana menangani kasus jika input tidak mengandung data. Contohnya buruk, tetapi pendekatan struktur nullable setidaknya, tapi saya mencoba untuk mematuhi), kode bersih (well, setidaknya saya tahu apa itu :), walaupun saya mencoba untuk menulis semuanya sebagaimana mestinya). Tampaknya semuanya ditangkap, sekali lagi bukan argumen.
[9]. “Saya mendapat kesan bahwa sama sekali tidak ada pemahaman tentang bagaimana React bekerja di bawah tenda. Ada banyak kesalahan kritis dalam bekerja dengan alat peraga untuk komponen yang memiliki efek yang sangat buruk pada kinerja. Mekanisme optimisasi reaksi diabaikan. "
Saya tidak bisa mengerti di mana masalah yang dijelaskan ini. Mekanisme macam apa?
[10]. "Menciptakan fungsi handler di dalam render."
Saya tidak punya fungsi penangan dalam render sama sekali, apakah ada yang mengerti apa yang tertulis di sini? Saya bahkan mentransfer pemrosesan format ke Web Worker
[11] “Membuat objek kosong baru dan mentransfernya ke tiket. ticket-list-loading.jsx:10 atau Ticket.tsx:24 ”
Tidak ada yang penting di sini, kecuali kemalasan saya untuk mengambil secara terpisah komponen tiket pemuatan. Melewati objek kosong tidak melanggar prinsip pemrograman apa pun, kecuali bahwa di sini perlu untuk melakukan ini melalui ticket = ticket || {}; ticket = ticket || {}; tetapi ini murni karena fakta bahwa waktu pengembangan terbatas pada satu hari dan akan membutuhkan lebih banyak waktu untuk memperbaiki semua kekurangan kecil.
[12] “Array indeks sebagai kunci pada daftar tiket”
Ada lebih banyak pertanyaan mengapa api tidak mengembalikan elemen dengan id. Oleh karena itu, ketika menerima data dari server, saya perlu membuat kunci unik untuk setiap elemen, yang saya tidak lakukan sebagai bagian dari tugas pengujian, karena bahkan dalam proyek nyata ini adalah pendekatan yang meragukan.
Dan akhirnya, kesimpulannya: "Secara umum, Bereaksi tidak bekerja (
Total: untuk tingkat menengah, kami berharap tidak akan ada masalah kritis dengan reaksi, tetapi ada banyak dari mereka dalam pekerjaan yang dilakukan. "
Sudah tidak ada komentar ...
Terima kasih jika Anda membaca sampai akhir. Saya memiliki pendapat yang sangat negatif tentang Aviasales, jadi saya memposting semuanya di sini sehingga Anda dapat mengevaluasi diri Anda apakah Anda harus menghubungi mereka atau tidak.
Teks lengkap dari pesan:
Pekerjaan dilakukan dengan sangat hati-hati. Tampaknya selama pengembangan tujuan "berhasil", dan "cara kerjanya" diabaikan. Berdasarkan persyaratan kami untuk tingkat kandidat, tugas yang diselesaikan hampir tidak mencapai tengah.
Kinerja dan struktur:
Kami berharap bahwa filter tidak akan di-hardcode dan akan beradaptasi dengan data. Jika Anda pergi ke aviasales, Anda dapat melihat bahwa tiket ditampilkan segera saat angsuran pertama muncul, dan kami tidak menunggu semua orang memuat.
Selanjutnya, lebih banyak poin teknis.
- Mengapa
filter.service tahu tentang router dan jendela? Seharusnya tidak mengontrol keadaan aplikasi dan memiliki ketergantungan seperti itu sama sekali. - Pekerja Web. Apa untungnya? Dalam kasus ini, banyak waktu dihabiskan untuk operasi asinkron, dan beban yang disimpan di utas utama dihabiskan untuk membuat objek bersambung / deserialisasi (dan objek yang dapat diobservasi). Jika kita berbicara tentang pengoptimalan, maka itu layak dimulai bukan dengan penghapusan di pekerja web, tetapi memperbaiki masalah di utas utama.
- Tidak masuk akal untuk menambahkan rxjs ke proyek hanya untuk menerapkan coba lagi dan pemuatan berurutan.
- Proyek tidak dapat ditingkatkan dan dipertahankan. Konstruk seperti (
ticket.segments || [{}, {}]).map((ticket) => ticket ) sangat rumit.
Bereaksi:
Saya mendapat kesan bahwa sama sekali tidak ada pemahaman tentang bagaimana React bekerja di bawah tenda. Ada banyak kesalahan kritis dalam bekerja dengan alat peraga untuk komponen yang memiliki efek yang sangat buruk pada kinerja. Mekanisme optimisasi reaksi diabaikan. Secara singkat tentang masalah: - Membuat fungsi handler di dalam render.
- Buat objek kosong baru dan transfer ke tiket.
ticket-list-loading.jsx:10 atau Ticket.tsx:24 . - Array indeks sebagai kunci pada daftar tiket.
Secara umum, Bereaksi tidak bekerja :(
Total: untuk tingkat menengah, kami berharap bahwa dengan bereaksi tidak akan ada masalah kritis, tetapi ada banyak dari mereka dalam pekerjaan yang dilakukan.