17 November 2018 . Ada empat dari kita. Semua orang gembira - mereka melewati tahap pertama
ShRI , Sekolah Desain Antarmuka. Ini terdiri dari kuliah dan pekerjaan rumah: menguasai berbagai teknologi front-end dan dekat-tender, alat, Scrum. Mereka tahu bahwa semua ini harus digunakan dalam proyek pertempuran di tahap kedua. Tetapi itu adalah satu hal untuk diketahui, dan hal lain untuk benar-benar mengimplementasikan proyek ini dalam 5 minggu ke depan.
Kami tinggal, omong-omong, kami berempat di satu kamar di hostel Netizen. Yandex menempatkan kami di sini sebelum tahap pertama. Hostel bagus, trendi.
Presentasi proyek hari ini. Kami tidak menyajikan, tetapi untuk kami. Unit Yandex membawa tugas produksi untuk layanan eksternal dan internal, masing-masing hanya selama 5 minggu, jika Anda membuat sekelompok kecil orang. Sebagian besar tugasnya adalah front-end (kami berada di ShRI), tetapi ada beberapa nuansa: Anda perlu mengajukan backend dan desain kecil. Orang tua mengatakan itu berbeda pada tahun-tahun awal ShRI. Mereka melakukan tugas-tugas abstrak yang tidak terkait dengan produksi.
Kita akan pergi ke seluruh aliran SRI 2018 di aula, di sini semua orang yang masuk ke tahap kedua. Untuk pertama kalinya kami diminta masuk ke tim: sebelum semua orang melakukannya untuk dirinya sendiri. Kami berempat dengan cepat berkonsultasi bersama dan memutuskan - karena kami tinggal bersama, kami akan melakukan proyek bersama. Tim itu bernama Bundle. Kemudian kita diberitahu tentang proyek yang terjangkau, ada lebih banyak dari mereka daripada tim yang dibentuk. Ini berarti bahwa departemen tempat proyek berasal memiliki insentif untuk membuatnya lebih menarik bagi siswa, jika tidak Anda dapat dibiarkan tanpa pemain.
Mereka menjelaskan kepada kami bahwa setiap tim akan melakukan satu proyek, tetapi pertama-tama kita perlu memilih beberapa. Selanjutnya, sistemnya adalah sebagai berikut: jika satu proyek memilih beberapa tim, maka tim pelaksana ditentukan secara acak di antara mereka, dan seterusnya hingga semua siswa menerima tugas untuk tahap kedua. Kami pergi dengan kurator kami di ruang pertemuan, kami berunding, setiap tim, terlepas dari yang lain, memberikan suara untuk proyek yang mereka sukai. Dengan jumlah suara, kami menghitung mereka yang menarik bagi kami sebagai sebuah tim.
21 November, Rabu . Dua proyek yang tampaknya paling menarik bagi kami diambil oleh tim lain sesuai dengan sistem acak. Kami mendapatkan yang ketiga - alat untuk variabilitas wawancara front-end.
Pengembang antarmuka saat wawancara di Yandex sering diberi tugas untuk menemukan bug di tata letak hasil pencarian. Calon harus membuka tautan yang diusulkan, di sana ia akan melihat hasilnya, yang dikompilasi dengan kesalahan. Diperlukan untuk secara visual dan menggunakan konsol JavaScript di browser untuk menemukan kesalahan dan mengusulkan koreksi.
Kesulitannya adalah Anda ingin memberikan kandidat yang berbeda set bug yang berbeda, memvariasikan mereka tergantung pada harapan orang yang diwawancarai. Tetapi kemudian sebelum setiap wawancara Anda perlu duduk dan mengumpulkan hasilnya secara manual. Lebih baik untuk memiliki alat yang akan mengumpulkan sendiri, menempatkan bug di atasnya dan membentuk tautan ke sana. Pada saat yang sama, jenis tautan itu sendiri seharusnya tidak memberi petunjuk kepada kandidat bug apa yang perlu dia temukan. Ini adalah kompleksitas kecil tapi tambahan, karena cara termudah untuk secara otomatis memasukkan kesalahan adalah dengan mengirimkannya melalui parameter kueri dalam teks tautan. Berdasarkan konvensi, alamat yandex.ru/search/?text=cats&bug=object dapat menyebabkan masalah di mana blok respons objek dikompilasi dengan salah. Saya tidak ingin memberikan petunjuk seperti itu. Itu perlu untuk "proksi" halaman, menunjukkannya pada alamat yang tidak dapat ditafsirkan.
Proyek ini masuk dalam daftar tim kami karena ini serbaguna. Kami memahami bahwa menulis admin pekerjaan akan memerlukan backend dan beberapa keterampilan desain.
Kamis, 22 November . Bahkan, pada hari kerja, kuliah hanya berlanjut (sudah tanpa pekerjaan rumah, untuk pengembangan umum), dan Sabtu disediakan untuk pekerjaan pada proyek. Pada hari Sabtu di pagi hari, seluruh aliran berkumpul bersama lagi, memiliki sepanjang hari untuk merencanakan dan kode bersama dengan manajer (karyawan Yandex), dan sebagainya pada setiap Sabtu hingga akhir SRI. Ini disebut shrikaton, itu terjadi di kantor.
Tapi tim kami hidup bersama, jadi kami mulai lebih awal. :) Ini bukan cheat yang sangat besar - kita berempat memiliki rezim yang berbeda hari ini, bekerja di samping SRI. Namun kami juga memiliki kesempatan untuk maju dalam proyek dalam minggu ini.
Pilih database untuk backend. Salah satu dari kami, Vani, memiliki pengalaman dengan MongoDB, ini adalah basis sederhana dari sudut pandang integrasi, jadi kami memikirkannya. Yandex. Cloud akan memberi kami kluster MongoDB yang Dikelola sehingga kami tidak perlu memikirkan untuk melayani basis data. Untuk kenyamanan bekerja dengan database, kami akan menggunakan perpustakaan Mongoose - kami akan menggambarkan entitas utama sebagai skema dan model Mongoose (dengan tipifikasi, hubungan, validasi). Agar basis dapat dinaikkan secara lokal, kami menambahkan docker-compose.
24 November . Shrikaton pertama. Setiap tim duduk di meja besar masing-masing, masing-masing memiliki papan - Anda dapat menempel stiker, menonton status tugas, dan melakukan stand-up secara teratur. Anda terganggu hanya untuk makan siang. Para kurator membantu kami: memberi saran tentang komponen teknis, memberi tahu cara mengatur komunikasi, bagaimana dengan kami, empat orang yang berbeda, membuat tim, bekerja di Scrum, menggambar papan kanban, menetapkan tujuan, secara umum - mulai mengubah ide menjadi produk.
Kami mendistribusikan peran: kami berdua akan berada di frontend panel admin, dan dua lainnya akan berada di backend. Yandex menyebut backend ini untuk frontend - kami menggunakan layer dari server di Node.js. Kami memutuskan untuk menulis server dalam TypeScript - kami memilihnya untuk mematuhi pengetikan yang ketat dan sepenuhnya menerapkan konsep OOP. Untuk perutean di server, kami menggunakan kerangka kerja Express yang minimal, fleksibel, dan fungsional. Kami memahami bahwa bagian belakang dan depan harus dikembangkan secara independen, oleh karena itu, kami memperkenalkan "rintisan" sementara - data yang disiapkan secara manual untuk bagian depan, seolah-olah mereka dibentuk dan dikirim oleh yang sudah bekerja kembali. Kami menulis dokumentasi di layanan Swagger untuk setiap pegangan HTTP untuk menafsirkan bertopik dengan benar dan kemudian cukup untuk menghapus semuanya dan menutup bagian depan dan belakang. Untuk melakukan ini, kami sedang mempersiapkan untuk menulis API REST.
Kami menetapkan tujuan utama - untuk mengimplementasikan empat entitas:
- server admin
- bagian klien untuk panel admin,
- infrastruktur
- halaman dengan bug.
Pada akhir setiap shrikaton (ada empat dari mereka), salah satu tim harus berbicara dan menunjukkan demo dengan hasil sementara untuk proyek tersebut. Kami setuju bahwa masing-masing dari kami akan mengadakan satu demo secara keseluruhan. Pada demo pertama, kami terutama menunjukkan tata letak dengan bug - dalam bentuk di mana kandidat akan mempelajarinya saat wawancara. Kami juga memperlihatkan panel admin dasar - bagian-bagian yang berhasil kami lakukan di hari pertama.
Minggu dari 26 November hingga 2 Desember . Musim dingin dan proyek kami mendapatkan momentum. API dan kontrak yang didiskusikan dan didokumentasikan untuk pertukaran informasi antara klien dan server.
Kami setuju untuk membuat lebih banyak fungsi di panel admin daripada yang dinyatakan dalam Kerangka Acuan. Faktanya adalah bahwa kandidat yang kami tunjukkan tata letak dengan bug kemudian dapat membagikan tautan ke halaman ini dengan teman atau di komunitas front-end untuk menyederhanakan kehidupan kandidat lainnya. Ini berarti bahwa tautan tersebut harus "terbakar" setelah beberapa waktu, menjadi tidak beroperasi. Ini diketahui segera, ketika kami diberi proyek, tetapi untuk sekarang, untuk kenyamanan orang yang diwawancarai, kami ingin menampilkan di panel admin bidang yang dapat diedit dengan waktu yang tepat dari "kehidupan" dari tautan tersebut.
Selain itu, kami menambahkan cerita. Admin dalam bentuk aslinya hanya alat untuk menghasilkan tautan. Kami pikir, sejarah akan memungkinkan kami untuk melihat tautan mana yang telah dibuat dan untuk berapa lama mereka telah aktif. Kami juga menambahkan kemampuan orang yang diwawancarai untuk melampirkan komentar teks (dalam bentuk gratis) ke entri dalam sejarah.
Demo pada shrikaton kedua masih ditampilkan dengan colokan - backend masih digergaji. Dalam proses pengujian demo, kami menemukan sejumlah masalah dengan arsitektur, kami menambahkannya ke backlog dengan prioritas tinggi.
Minggu mulai 3 hingga 9 Desember . Sprint lain. Kami menentukan bahwa panjang sprint optimal bagi kami adalah 6 hari, mulai dari hari Senin dan berakhir dengan shrikaton pada hari Sabtu. Setelah shrikaton, pada hari Minggu, kami mengatur retro dan membuat jaminan untuk sprint berikutnya.
Kami berlatih ulasan kode. Setiap permintaan kumpulan ditinjau oleh setidaknya dua anggota tim (dengan pengecualian langka dalam bentuk permintaan kumpulan yang berisi koreksi kecil). Kami mencoba menggunakan praktik berikut:
- jangan tunda verifikasi permintaan kumpulan,
- tulis ulasan dalam bentuk permintaan diskusi, bukan tim,
- jelaskan dalam komentar tidak hanya perubahan yang diajukan, tetapi juga alasannya
- banyak menggunakan contoh kode dan tautan ke sumber daya yang bermanfaat.
Ada pertanyaan tentang desain ulang. Kami menerapkan desain yang Yandex berikan kepada kami dalam bentuk tata letak pada awalnya, tetapi jumlah fitur meningkat, panel admin perlu diubah, termasuk yang visual. Kami berkomunikasi dengan pelanggan, menyetujui sebagian desain ulang, dan mulai melakukannya.
Kami memperbaiki masalah dalam arsitektur, menyingkirkan bertopik antara frontend dan backend, sambungkan database. Dokumentasi yang kami kumpulkan membantu: ketika kami mematikan stub dan melakukan penyesuaian yang sangat kecil, data mulai dengan benar datang dari belakang ke depan. Demo pertunjukan pertama dalam mode pertempuran.
Dua minggu terakhir . Kami bertukar tempat: kami berdua yang bertanggung jawab untuk front sekarang bertanggung jawab untuk belakang - dan sebaliknya. Kami datang dengan skema seperti itu sehingga masing-masing dari kami mengetahui seluruh proyek. Sepanjang jalan, kami membahas dengan manajer dan pelanggan rincian proses memperkenalkan panel admin ke dalam produksi. Kepala grup pengujian antarmuka pencarian Olya Molchanova banyak membantu kami, kami menyetujui langkah-langkah implementasi spesifik.
Untuk menyusun laporan teknis tentang proyek (ini diperlukan dari semua tim), kami menulis mengapa kami memilih pendekatan atau alat ini atau itu:
Menerapkan UI sebagai Aplikasi Satu Halaman karena banyaknya keuntungan dibandingkan situs multi-halaman "klasik". Pertama, SPA menyerupai aplikasi asli yang sederhana, satu-satunya perbedaan adalah bahwa mereka dieksekusi di browser, dan bukan dalam proses sistem operasi itu sendiri. Kedua, aplikasi seperti itu selalu memiliki UX yang kaya. Karena kami hanya memiliki satu halaman web, membangun antarmuka pengguna yang kaya dan fungsional jauh lebih mudah. Pada saat yang sama, nyaman untuk menyimpan dan memperbarui status representasi, serta mengelolanya. Ketiga, SPA mengecualikan permintaan konstan untuk konten yang sama ketika bergerak di sekitar situs.
SPA juga memiliki kekurangan. Ketika pewawancara pertama kali membuka panel admin, ia perlu mengunduh sedikit lebih banyak data. Namun, dalam proyek kami, bundel rakitan dalam bentuk terkompresi (gzip) beratnya sedikit di atas 100 KB dan dibagi menjadi fragmen (potongan). Akibatnya, situs tersebut digambar sama cepatnya. Kekurangan SPA secara tradisional mencakup fakta bahwa hampir semua robot pencarian dan jejaring sosial tidak melihat konten situs-situs tersebut. Aplikasi kami dikembangkan untuk penggunaan internal, jadi kami tidak perlu menggunakan rendering sisi server atau umumnya peduli tentang SEO.
React dipilih sebagai perpustakaan untuk mengembangkan aplikasi SPA, seperti:
- banyak proyek baru di Yandex ditulis dalam React, dan yang lama ditulis,
- Anda dapat menggunakan perpustakaan komponen Lego,
- semua anggota tim akrab dengan Bereaksi,
- React memiliki 117.697 bintang di GitHub, sebuah komunitas jutaan pengembang.
Untuk pekerjaan mudah dengan tanggal (khususnya, untuk menampilkan periode waktu yang tersisa untuk tautan), perpustakaan Moment.js digunakan.
Dalam laporan teknis, perlu dicatat bahwa kita masing-masing telah mempelajari hal-hal baru. Total empat daftar:
1. Menghargai kekuatan penuh dari TypeScript. Bahasa ini memungkinkan Anda menangkap kesalahan saat menulis kode, membuat refactoring, dan menambahkan fitur lebih menyenangkan. Kami berkenalan dengan organisasi proyek berdasarkan beberapa file konfigurasi.
2. Bekerja dalam paradigma arsitektur layanan-mikro dan mono-repositori.
3. Belajar banyak tentang Bereaksi (termasuk dari satu sama lain). Pahami cara mengatur komponen agar lebih mudah dirawat dan digunakan kembali.
4. Beberapa dari kita telah menemukan untuk diri kita sendiri, sementara yang lain telah menguasai berbagai alat:
- Docker dan Docker Compose. Kami belajar cara memasang, mengonfigurasi, dan menjalankan wadah dengan cara dasar.
- Git. Praktek parsing, membuat, dan menyuntikkan permintaan kumpulan dikonsolidasikan. Mengakui pentingnya proses ini.
- Perpustakaan Moongose, panel admin mongo-express.
- Yandex.Cloud.
- Sombong.
- BitBucket.
5. Mendapat lompatan besar dalam pengembangan berkat pengembangan tim.
- Belajar bekerja di tim scrum.
- Kami bekerja di pelacak tugas, berkenalan dengan papan kanban, sprint. Dalam kondisi nyata, mereka menyadari betapa jauh lebih produktif melakukan pengembangan dalam siklus pendek dengan umpan balik yang konstan.
- Atur CI melalui TeamCity.
- Mereka melihat bahwa tinjauan kode berguna untuk semua peserta. Terkadang membaca kode orang lain lebih bermanfaat daripada menulis.
- Kami bekerja dengan manajer proyek, ini membawa pengembangan lebih dekat ke kondisi "lapangan".
- Karena demo reguler, kami mendapat keterampilan berbicara di depan umum.
Kami menyelesaikan layanan, melakukan pengujian komprehensif, dan menyusun dokumentasi. Secara paralel, Anda perlu mempersiapkan wawancara kami sendiri tentang Yandex - beberapa dari mereka akan diadakan pada hari berikutnya setelah selesainya proyek! Ini adalah berita buruk (karena persiapan sedikit mengganggu dari proyek) dan bagus (karena langkah-langkah selanjutnya tidak ditunda).
23 Desember . Hari terakhir SRI, kami datang dengan proyek selesai. Vanya mengatakan, tiga lainnya bergabung untuk menjawab pertanyaan. Ringkasan - kami membuat panel admin yang memungkinkan karyawan membuat URL hasil pencarian yang cocok dengan kesalahan sebelum wawancara front-end. Kesalahan ini diatur secara otomatis dalam beberapa detik - centang saja. Selain itu, orang yang diwawancarai dapat melihat riwayat tautan dan mengatur masa pakai URL Anda. Dan dalam wawancara itu sendiri, sebagaimana telah disebutkan, kandidat menerima tautan dan harus menemukan dan memperbaiki semua kesalahan. Kami menambahkan ke panel admin kemampuan untuk menyiapkan halaman dengan bug tidak hanya berdasarkan antarmuka pencarian, tetapi juga layanan lain, jika perlu untuk wawancara.
Di sisi server, NodeJS dan kerangka Express digunakan untuk meng-host antarmuka dan memproses permintaan REST API. Sisi klien adalah Bereaksi. Laporan teknis lengkap tentang proyek ini
diposting pada Disk .
Penulis posting ini :)
24 Desember . Kami tidak langsung tidak setuju - kami tinggal di asrama selama sekitar satu minggu dan melalui wawancara. Kami menulis hanya lebih dekat ke Tahun Baru.
21 Mei 2019 . Sekarang masing-masing dari kita berempat bekerja di Yandex, tidak lagi pada magang, tetapi pada kontrak abadi. Kami adalah pengembang antarmuka Evgeny Goncharenko, Ivan Kolobaev, Sergey Makhlonov dan Evgeny Starostin. Sistem yang kami buat sebagai proyek kelulusan di ShRI selalu digunakan dalam wawancara.
9 Juli . Publikasikan pos ini.