🕛 🤰🏻 👀 Bagaimana proyek PHP Highload dibuat: transcript 🎒 👨‍🚀 💡

Pada tanggal 28 Juli, akun Instagram kami dan YouTube mengadakan siaran langsung dengan Alexander Vysotsky, pengembang PHP terkemuka di kantor Badoo London, yang bekerja di tim anti-spam. Sasha berbicara tentang bagaimana proyek Highload dibuat dengan PHP, kehidupannya di London dan, tentu saja, tentang Badoo.

Nama saya Alexander Vysotsky, saya bekerja sebagai pengembang PHP terkemuka di Badoo. Kami sedang mengembangkan aplikasi kencan Badoo and Bumble, yang memiliki lebih dari 500 juta pengguna di seluruh dunia.

Kami memiliki beberapa kantor di berbagai negara, tetapi sebagian besar pengembang berlokasi di Moskow dan London. Secara total, tim pengembang Badoo memiliki sekitar 300 orang. Kami memiliki 20 proyek sumber terbuka dan banyak alat internal yang sering kami bicarakan di blog kami di Habré.

Hari ini saya ingin memberi tahu Anda bagaimana rasanya bekerja sebagai pengembang backend di Badoo dalam kondisi dua rilis sehari, beban tinggi yang nyata dan sejuta baris kode, bagaimana beradaptasi dengan kehidupan dan bekerja di luar negeri dan menjaga keluarga Anda tetap bersama.

Bagaimana saya sampai di Badoo

Kampung halaman saya adalah Saratov, di mana saya juga menerima pendidikan khusus: Saya lulus dari studi khusus dan pascasarjana di Fakultas Ilmu Komputer dan Teknologi Informasi SSU. Saat lulus dari sekolah pascasarjana, ia telah bekerja sebagai backend developer di berbagai bidang: dari sektor pariwisata hingga permainan.

Pada pertengahan 2017, proyek utama di tempat kerja berakhir, dan muncul pertanyaan di depan saya, apa yang harus dilakukan selanjutnya: mencari sesuatu yang baru di Saratov, pindah ke Moskow atau St. Petersburg, atau pergi ke perusahaan asing? Pada titik ini, saya sudah mengetahui tentang Badoo dan melamar posisi terbuka di kantor London. Namun, saya tidak memiliki cukup pengalaman dan pengetahuan untuk mendapatkan tawaran. Tetapi pada saat yang sama saya menerima dua tawaran pekerjaan dari Jerman dan Belanda. Bersama istri saya, kami memutuskan untuk pindah dan bekerja di sebuah perusahaan Jerman. Selama satu setengah tahun kami tinggal di Leipzig - salah satu kota terbesar di Jerman - tempat saya mengerjakan solusi pariwisata.

Namun, keinginan untuk bekerja di Badoo tidak sirna, dan saya melamar posisi terbuka lagi, setahun kemudian. Setelah beberapa wawancara telepon dan satu wawancara tatap muka, saya mendapat tawaran. Jadi awal tahun 2019 saya pindah ke London.

Kedua kepindahan - ke Leipzig dan London - merupakan ujian yang serius. Saya menemukan diri saya berada di luar lingkungan biasa: tidak ada teman, kerabat, orang tua yang biasa saya ajak berkomunikasi setiap hari. Itu tidak mudah bagi saya, dan untuk istri saya, keluarga kami secara keseluruhan. Kami sedang mencari jalan keluar dari keadaan ini dan mencoba untuk berintegrasi ke dalam masyarakat baru secepat mungkin.

Di Jerman, penghalang yang jelas adalah bahasa: kami selalu belajar bahasa Inggris, tetapi di sini kami harus menguasai bahasa Jerman. Butuh banyak usaha, tapi setelah 1,5 tahun tinggal di Leipzig, kami belajar bahasa dengan baik, berlatih setiap hari. Di London masalah ini tidak muncul, selain itu kami sudah memiliki pengalaman hidup di negara asing. Badoo memberikan dukungan maksimal selama perjalanan mencari apartemen, dalam berurusan dengan otoritas pajak. Ini membantu untuk berintegrasi ke dalam kehidupan lokal.

Salah satu momen tersulit bagi orang Rusia saat pindah adalah pajak. Di Inggris, skala progresif digunakan: tarif pajak naik tergantung pada tingkat pendapatan. Masalah bermasalah lainnya adalah obat-obatan. Seseorang mengatakan bahwa semuanya beres dengannya, seseorang tidak setuju. Saya memiliki pengalaman yang positif.

Cerita terpisah adalah dengan mencari tempat tinggal. Pilihan yang bagus akan dibongkar dengan sangat cepat. Selain itu, sebelum Anda mendapatkan apartemen untuk disewakan, Anda perlu melalui cek. Dalam kasus saya, bahkan ada panggilan ke Jerman ke tuan tanah kami sebelumnya: mereka ditanyai seberapa baik saya menjadi penyewa.

Juga penting bagi saya bahwa istri saya menyukai kehidupan di tempat baru. Dia selalu ingin mendapatkan profesi sebagai desainer dan sekarang sedang mempersiapkan diri untuk masuk. Menemukan kursus yang dia suka; pada saat yang sama, dia memperketat bahasanya dan lulus tes IELTS untuk masuk gelar Sarjana dalam desain interior. London memiliki institusi pendidikan yang sangat beragam, namun Anda perlu ingat bahwa bagi orang asing biaya pendidikan beberapa kali lebih tinggi daripada biaya pendidikan lokal.

Selanjutnya, saya akan menjawab beberapa pertanyaan dari obrolan tersebut.

Apa yang membantu beradaptasi setiap kali ke tempat baru?

Dukungan utama selalu ada di dalam keluarga. Dalam kasus kami, istri saya dan saya saling mendukung, dan ini membantu mengatasi semua kesulitan awal. Selain itu, setiap kali saya beruntung dengan tim: Saya memiliki rekan yang sangat keren, mereka selalu mendukung dalam perkataan dan perbuatan, berbagi pengalaman, awalnya mereka bisa pergi bersama Anda dan menyelesaikan masalah. Secara umum, keluarga yang baik dan kolega yang baik layak mendapatkan emas.

Apakah layak meninggalkan freelancing untuk bekerja di perusahaan besar dengan gaji lebih rendah jika Anda belum pernah memiliki pengalaman kerja seperti itu sebelumnya?

Pertanyaannya adalah, bukan dalam gaji, tetapi dalam proses yang terkait dengan transisi ke perusahaan besar. Saat Anda menjadi freelance, Anda menetapkan hari kerja untuk diri sendiri dan membangun alur kerja yang membantu Anda menyelesaikan berbagai hal. Di perusahaan besar, semuanya berbeda: tenggat waktu yang ketat, lebih banyak komunikasi - baik di antara rekan kerja dalam tim maupun antar tim. Anda perlu memikirkan apakah kecepatan dan format pekerjaan ini tepat untuk Anda, dan membuat keputusan berdasarkan ini.

Mengenai gaji, Anda harus melihat ke depan. Jika Anda sekarang meninggalkan gaji besar sebagai freelance dan pindah ke yang lebih kecil, ke sebuah perusahaan, maka nantinya gaji tersebut bisa tumbuh lebih kuat berkat pengalaman di industri tersebut.

Penafian kecil: Anda dapat mengunjungi situs web kami tech.badoo.comtempat kami memposting lowongan saat ini. Mungkin Anda akan menemukan sesuatu yang Anda sukai dan Anda akan meninggalkan permintaan.

Apa sajakah keunggulan Badoo dibandingkan dengan perusahaan kecil?

Lebih baik membaca tentang ini di situs web kami : ada lebih banyak yang tercantum di sana daripada yang dapat saya ingat. Poin utama yang tidak bisa tidak bersukacita adalah asuransi kesehatan sukarela, kompensasi kebugaran, sarapan, makan siang, makan malam di perusahaan, peralatan kerja berkualitas tinggi.

Benarkah Badoo tidak mempekerjakan orang untuk bekerja di Inggris? Saya tidak dapat menemukan jawaban eksplisit.

Sebelum pandemi, kami memiliki lowongan di Moskow dan London. Dalam lingkungan saat ini, tentu saja, relokasi dan perjalanan bisnis antar kantor untuk sementara dibekukan, meskipun perekrutan terus berlanjut. Lihat pembaruan di situs web: itu selalu menunjukkan di kantor mana ada lowongan terbuka. Perusahaan menganut transparansi maksimum dalam hal ini.

Apakah Anda harus bekerja dari jarak jauh? Apakah ini menjadi lebih sulit? Bagaimana Anda berinteraksi?

Ya, kami masih bekerja dari jarak jauh. Pada awalnya sulit karena fakta bahwa saya dan kolega saya tidak selalu bersamaan: orang lain "tidak datang" untuk bekerja, seseorang telah "pergi". Diperlukan sinkronisasi antara tim yang berbeda. Masalah komunikasi menjadi lebih sulit untuk diselesaikan. Alih-alih mengajukan pertanyaan secara pribadi, saya harus menulis atau menelepon, yang memakan waktu lebih lama.

Untuk interaksi, kami memiliki banyak sekali obrolan, konferensi video yang kami gunakan. Sekarang menjadi lebih mudah - kita sudah terbiasa.

Bagaimana cara mengontrol usaha, ketekunan, motivasi diri, penundaan?

Bukan rahasia lagi bahwa karena pandemi, sebagian besar perusahaan IT beralih bekerja dari rumah. Sulit bagi saya untuk membangun kembali di rel lain, tetapi saya memilih beberapa poin untuk diri saya sendiri.

Pertama, diperlukan kontrol ketat terhadap jam kerja. Anda dapat memberi tahu semua kolega bahwa dari 9 hingga 18 Anda bekerja dan tersedia di semua messenger, dan di luar waktu ini tidak menanggapi permintaan. Semua orang memperlakukan ini dengan pengertian. Saat Anda bekerja dari rumah, sulit untuk memisahkan pekerjaan dan keluarga, tetapi sangat penting untuk menjaga suasana hati dan hubungan psikologis.

Kedua, motivasi diri dan penundaan itu penting. Banyak artikel di Habré mengatakan bahwa menunda-nunda adalah hal yang wajar, tetapi buruk jika ada banyak penundaan. Saya menggunakan teknik berikut: jika saya menemukan masalah besar, saya membaginya menjadi banyak masalah kecil. Dan kemudian fitur baru yang menakutkan tidak lagi tampak menakutkan, dan dapat dirilis tanpa masalah.

PHP dan beban tinggi di Badoo

Saya akan beralih ke pertanyaan tentang pekerjaan. Saya bekerja di tim anti-spam. Seperti namanya, sepertinya kita hanya berurusan dengan anti-spam, tetapi ini jauh dari kasusnya. Tujuan kami adalah memberikan pengalaman terbaik untuk menggunakan aplikasi kami. Tugas melindungi pengguna sangat penting bagi kami, banyak sumber daya dan upaya dialokasikan untuk ini.

Untuk meringkas, kami terlibat dalam perang melawan pengguna yang jahat: mereka yang mengirim spam, terlibat dalam penipuan, dan merusak pengalaman pengguna. Kami secara aktif menggunakan ML. Tentu saja, saya tidak bisa menjelaskan secara detail agar tidak membuat hidup lebih mudah bagi pengirim spam, tetapi berikut adalah beberapa contohnya.

Kami memiliki model deteksi spam / scam. Kami membuat alat untuk menganalisis lalu lintas seluler untuk tim paralel. Selain itu, perusahaan kami menggunakan jaringan saraf: untuk verifikasi foto isyarat dan saat mengirim foto cabul di messenger. Baru-baru ini, kolega kami meluncurkan apa yang disebut "detektor pic kontol" untuk melindungi dari konten yang tidak pantas dalam pesan pribadi: pengguna dapat memilih apakah dia ingin melihat konten semacam itu.

Bagaimana Badoo menangani spam? Simple apakah atau sudah ML?

Saya pernah melihat lelucon di suatu tempat bahwa ML hanyalah sekelompok besar if / else. Tetapi, tentu saja, ini tidak terjadi sama sekali di sini.

Badoo memiliki beberapa kegunaan ML, karena dapat sangat meningkatkan proyek. Misalnya, seperti yang sudah saya katakan, kami menggunakan verifikasi foto pengguna, dan ML membantu dalam hal ini: ini menentukan bahwa seseorang benar-benar mengambil foto sekarang dan dia melakukan apa yang diminta darinya. Neuron itu keren.

Bagaimana Anda menerapkan ML? PHP, bahasa lain, semacam kerangka kerja, pengembangan sepenuhnya sendiri?

Kami memiliki orang-orang yang sangat keren di tim data. Blog tersebut memiliki laporan keren dari Alexander Krasheninnikov - sayangnya, dia sudah menjadi mantan kolega saya - yang memberi tahu tim seperti apa itu, masalah apa yang dipecahkan, bagaimana meningkatkan kerja Badoo dan membantu kita semua. Tim Data telah membuat kerangka kerja ML mereka sendiri, yang sangat mudah digunakan dan tersedia untuk semua tim lain di perusahaan: kami dapat mengatakan bahwa mereka telah melakukan semua pekerjaan untuk kami. Mereka memiliki implementasi yang sangat keren, dokumentasi yang sangat baik, pendekatan yang sangat mudah untuk bekerja dengan framework.

Apa tantangan terbesar yang kamu hadapi di Badoo?

Saya tidak dapat memilih tugas atau proyek tertentu yang akan menjadi yang paling sulit. Ada proyek yang menarik, dan ada yang sangat menarik. Dalam praktik saya, ini semua adalah proyek yang terkait dengan Pembelajaran Mesin. Ketika saya di sekolah pascasarjana, saya menyentuh topik ini, dan bidang ini membuat saya terkesan. Kami melakukan proyek untuk tim Pemasaran Kinerja yang terkait dengan analisis lalu lintas - sangat keren, kami menemukan banyak wawasan yang berguna.

Mengapa Anda menggunakan PHP?

PHP adalah alat yang hebat untuk memecahkan masalah pengembangan web dan dengan cepat mengembangkan proyek yang dapat diskalakan. Tetapi sikap terhadap bahasa ini di masyarakat ambigu, dan ini karena reputasinya. Sejak dimulainya PHP, ada kepercayaan bahwa sangat mudah untuk menulis kode yang buruk di dalamnya. Menurut saya, ambang masuk yang rendah bukanlah suatu kerugian. Sebaliknya, ini memungkinkan Anda untuk melibatkan banyak orang dalam pembangunan. Selain itu, ini benar-benar berfungsi dengan baik dalam mengembangkan aplikasi web, dan dengan setiap versi baru bahasanya meningkat.

PHP 7 telah mengambil langkah maju yang besar dalam hal produktivitas dan pengembangan. Kami memiliki artikel bagus di blog kami di Habré tentang bagaimana transisi ke versi ini memungkinkan kami untuk membebaskan sebagian besar sumber daya.

Popularitas PHP baru-baru ini telah jatuh, dan ini wajar - alat dan bahasa lain muncul yang bersaing dengan PHP, dan banyak pengembang beralih ke mereka. Tetapi biasanya bagi kami untuk memilih alat untuk tugas tertentu, dan PHP mengatasi tugas tersebut.

Apa pendapat Anda tentang PHP 8, apakah Anda berencana untuk bermigrasi?

Kami secara aktif memantau setiap rilis PHP baru. Tentunya kita akan menggunakan semua fitur yang ada pada versi baru - tentunya setelah kita memastikan bahwa kode kita kompatibel, dan transisi ke PHP 8 akan memberikan keuntungan lebih dari waktu yang akan kita habiskan untuk transisi itu sendiri. Kami akan memutuskan transisi ketika PHP 8 keluar.

Seperti yang saya katakan, ketika kami beralih ke PHP 7, kami membebaskan banyak server, yang kami kirim ke tugas lain. Artinya, transisi ke versi baru bisa membawa manfaat besar.

Apakah Badoo menggunakan kompilasi PHP?

Tidak.

Ceritakan lebih banyak tentang kerangka kerja yang ditulis sendiri di Badoo. Atas dasar apa itu diterapkan dan seperti apa itu?

Ini dilakukan oleh tim platform - orang-orang yang membuat "backend untuk backend" dan mendukung sebagian besar pengembang backend. Mereka memberi kami banyak hal keren. Saya sudah membicarakan sebagian tentang ini: misalnya, mereka menerapkan fungsi antrian yang sama yang banyak digunakan di perusahaan; mereka juga membuat layanan cloud untuk kebutuhan kita.

Saya tidak akan mengatakan bahwa kerangka tersebut mirip dengan sesuatu yang spesifik. Saya telah bekerja dengan Laravel dan Symfony - tentu saja, ada beberapa bagian, dan kami dapat menggunakan modul yang bersifat open source dalam proyek kami. Namun menurut saya repositori git kami tidak sangat berbeda dalam pendekatan dari kerangka kerja modern lainnya. Kami menggunakan manajer paket untuk menarik dependensi pihak ketiga, kami menggunakan autoloading, kami menggunakan modul untuk merangkum potongan kode.

Kenapa Badoo menggunakan monolit dan bukan layanan mikro?

Ini adalah pertanyaan yang agak suci, komunitas terpecah menjadi dua kubu tentang ini. Bukan rahasia lagi bahwa kami menggunakan arsitektur monolitik, dan selama keberadaan proyek kami telah belajar untuk mengatasi kerugian dari pendekatan ini dan menggunakan semua kelebihannya. Selain itu, kami memiliki serangkaian layanan (dalam Go, PHP, C ++) yang kami gunakan secara aktif dalam pekerjaan sehari-hari kami.

Jika kita memahami pertanyaan sebagai "haruskah kita menyerahkan segalanya dan menggunakan semua sumber daya yang tersedia untuk menulis ulang monolit yang ada untuk arsitektur layanan mikro", saya akan menjawab tidak. Kami memiliki tantangan bisnis yang berhasil ditangani oleh solusi yang ada. Jika perlu, kami siap untuk perubahan, tetapi, seperti yang saya katakan, kami memilih alat yang sesuai dengan tugas yang ada.

Bagaimana bagian berbeda dari skala monolit di bawah beban?

Pertanyaan bagus untuk ditindaklanjuti tentang monolit dan layanan mikro. Kami memiliki presentasi yang bagus di blog kami tentang kinerja dan bagaimana backend kami dibangun dari sudut pandang arsitektur - Saya akan memberi tahu Anda secara singkat. Kami memiliki sekitar 600 server yang menangani semua permintaan dari klien, dan mereka bertanggung jawab atas monorepositori kami. Dengan pendekatan ini, kami memiliki beberapa fleksibilitas dalam penskalaan, menambahkan mobil baru, memasukkan kode - dan siap digunakan.

Seberapa mulus penerapan dalam lingkungan monolitik?

Jawaban atas pertanyaan ini dapat dibagi menjadi dua bagian. Yang pertama adalah implementasi teknis pipeline CICD kami, yang dijelaskan dengan baik oleh mantan kolega saya Yuri Nasretdinov dalam ceramahnya di HighLoad (" 5 cara menerapkan kode PHP dalam kondisi beban tinggi "). Saya sarankan menonton. Singkatnya, kami memiliki beberapa ratus server yang melayani permintaan pengguna. Selama penerapan, kami hanya mendorong perubahan ke repositori dan secara atomik mengganti symlink.

Bagian kedua adalah memastikan bahwa penerapan tidak merusak produksi untuk kami. Sebelum rilis, kode apa pun diperiksa menggunakan unit, integrasi dan pengujian UI, serta penganalisis statis untuk masalah yang jelas. Kami memiliki departemen QA yang besar dan profesional, yang memungkinkan kami berhasil merilis dua kali sehari.

Dengan siklus rilis yang singkat, sangat penting bagi kami untuk menjaga kualitas produk kami pada tingkat yang tinggi: kami tidak ingin mengeluarkan bug / fatal ke dalam produksi. Oleh karena itu, pengujian fitur yang sedang diproduksi menjadi yang utama. Setiap pengembang back-end tertarik dengan fakta bahwa fitur-nya di back-end diluncurkan tanpa tindakan tambahan dari departemennya dan dari tim front-end dan tim lapangan. Mungkin ada situasi seperti itu ketika Anda memiliki tiket untuk pengembangan fitur backend, Anda merilisnya dalam produksi, tetapi pada kenyataannya mereka mulai menggunakannya setelah beberapa saat. Dan kemudian teknisi QA mendatangi Anda dan bertanya mengapa itu tidak berhasil. Oleh karena itu, di sisi backend, ketika kami merilis fungsionalitas, kami menutupinya dengan jumlah maksimum tes, tiruan dan QAP untuk 100% yakin bahwa semuanyaapa yang kami gulung 100% berfungsi.

Satu lobak, semua orang mendorong ke satu tempat?

Ya, hanya ada satu lobak, dan semua teknisi bagian belakang mendorongnya. Kami memiliki aturan internal untuk menamai cabang yang entah bagaimana terkait dengan tugas yang ada. Tentu saja, Anda tidak dapat mendorong master secara langsung, cabang didorong ke sana setelah peninjauan kode yang berhasil, setelah semua pemeriksaan dan pengujian unit, dan setelah insinyur QA yang mengerjakan tugas dengan Anda mengatakan bahwa semuanya beres.

Apakah Anda menggunakan DDD atau pola arsitektur lainnya?

DDD adalah Desain Berdasarkan Domain. Ini bukan pola arsitektur, melainkan metodologi. Saya tidak akan mengatakan bahwa kami memiliki satu pendekatan khusus, kami menggunakan kombinasi beberapa.

Tentang pola: di backend, beberapa pola desain digunakan untuk menyelesaikan masalah, saya ingin menyoroti ini secara mendetail. Kami menggunakan implementasi bus acara, kami memiliki banyak antrian, kami mengirim jutaan acara yang diproses oleh konsumen yang sesuai. Juga di antara pola yang digunakan secara aktif adalah pola Modul: sebagian besar kode kami dibagi menjadi beberapa contoh yang terhubung dan terpisah yang berinteraksi melalui API terbuka terbatas.

Apakah Anda menggunakan pengecualian atau mencoba menghindar?

Kita gunakan. Dan kami mencoba menghindar.

Apakah API Anda monolit?

Iya.

Bagaimana Anda menguji API?

Kami memiliki pengujian unit dan keseluruhan kerangka kerja untuk menjalankan sejumlah besar pengujian secara paralel dengan jumlah waktu yang minimal. Anda dapat membaca lebih lanjut tentang ini di artikel oleh Vladimir Yants di blog kami , dia menjelaskan topik ini dengan baik dan rinci. Dalam hal pengujian UI, kami menggunakan Calabash dan Selenium untuk menguji apakah UI berfungsi dengan benar.

Pengembangan yang digerakkan oleh pengujian, saat menguji terlebih dahulu, lalu membuat kode - bukankah Anda berlatih?

Bersama kami, setiap tim dapat menggunakan pendekatan mereka sendiri saat mengembangkan, dan saya tahu bahwa beberapa rekan mempraktikkannya. Saya tahu itu berhasil, tetapi saya tidak mempraktikkannya sendiri.

Bagaimana perasaan Anda tentang DDD?

Seperti yang saya katakan, kami menyusun dari berbagai pendekatan. Jika kita berbicara tentang sikap pribadi saya, saya mendukung pendekatan apa pun yang memungkinkan Anda menyelesaikan masalah secara efektif. DDD layak untuk diinvestasikan: ini akan memungkinkan Anda membuat aplikasi pada tingkat kualitas yang baru.

Beritahu kami, apakah produksi tidak tahan dengan beban tinggi? Bagaimana Anda menangani ini?

Itu tidak ada dalam ingatanku. Kami memiliki insinyur berpengalaman, produk kami telah dikembangkan selama lebih dari 15 tahun, dan perusahaan memiliki pengalaman luas dalam pengembangan beban tinggi. Kami bertujuan untuk memaksimalkan kinerja aplikasi kami.

PHP dan MySQL - apa yang harus dilakukan untuk mengoptimalkan kinerja backend?

Ini menyentuh tumpukan yang digunakan di perusahaan dan kinerja, jadi saya akan membagi jawabannya menjadi dua bagian juga.

Tentang tumpukan: karena Badoo memiliki banyak departemen dan tim, kami menggunakan sekumpulan teknologi seluas mungkin - dari PHP, MySQL, Nginx, Go, C ++ hingga Tarantool, LUA, dan Scala. Setiap tim memilih alat untuk menyelesaikan tugas secara efektif. Karena kami bekerja dalam kondisi beban tinggi dan memproses puluhan ribu permintaan per detik, masalah kinerja backend kami menjadi kritis.

Sekarang ada baiknya menyebutkan alat yang dibuat di rumah dan dirilis dalam sumber terbuka. Alat pertama adalah Pinba (PHP Bukan Lagi Penghambat). Ini adalah alat untuk mengumpulkan statistik dan memantau kinerja aplikasi tanpa mempengaruhi kinerjanya dan untuk menyajikan data yang dikumpulkan dengan cara yang ramah manusia.

Yang berikutnya adalah Codeisok: alat untuk mengelola repositori git dan melakukan tinjauan kode. Kami secara aktif menggunakan pekerjaan internal kami, dan sebelum fitur menjadi master, kami menerapkan praktik peninjauan kode terbaik (Anda juga dapat membacanya di blog kami ) sehingga kode yang paling efisien mencapai produksi.

Alat lain yang memungkinkan kita melacak kinerja setiap bagian kode adalah LifeProf: ini memungkinkan kita untuk membuat profil semua permintaan secara otomatis. Semua alat ini (dan lainnya) dapat ditemukan di repositori Github kami.

Apakah Anda menggunakan ORM atau interaksi penyimpanan langsung? Mengapa?

Saya sudah menyebutkan bahwa kami memiliki kerangka kerja kami sendiri. Kami menggunakan implementasi ORM kami sendiri.

Bagaimana interaksi modul proyek diatur? Kelas ke kelas, atau sesuatu yang lebih rumit?

Pertanyaan bagus. Setiap modul memiliki satu titik masuk (Pengontrol depan), yang menyediakan API yang terpadu dan dapat dipahami - untuk modul lain atau untuk fitur lain. Kami tidak mengungkapkan seluruh implementasi internal untuk sisa proyek, kami hanya menyisakan apa yang ingin kami berikan di luar.

Roti khusus DB apa yang digunakan menggunakan ORM?

Saya tidak sepenuhnya memahami pertanyaan itu, tetapi saya akan mencoba menjawab.

Saya telah mengatakan bahwa database utama kami adalah MySQL, sebagian besar data disimpan di dalamnya. Kami juga menggunakan Exasol, Presto, Tarantool, dan Aerospike untuk tugas tertentu. Artinya, kami memiliki sejumlah besar penyimpanan untuk setiap tugas. Kami tidak membatasi diri dalam memilih alat: jika penggunaan teknologi menguntungkan, kami menggunakannya. MySQL adalah pusat aplikasi kami, dan kami menggunakan berbagai replikasi, sharding untuk menjaga beban secara efisien.

Bagaimana cara kerja pengujian pengembang? Untuk meningkatkan semuanya secara lokal di buruh pelabuhan, atau sesuatu yang lebih sulit, di server virtual?

Situasi lain di mana saya tidak bisa menjawab dengan tepat.

Kami tidak menggunakan Docker saat mengembangkan di PHP (tetapi admin menggunakannya), kami memiliki lingkungan dev yang sama. Tim platform kami terlibat dalam, antara lain, menjaga lingkungan pengembang agar berfungsi dengan baik untuk pengembangan, dan di sana kami menjalankan semua pengujian, menyusun fitur yang akan kami gulirkan ke produksi. Artinya, kami memiliki lingkungan yang telah dikonfigurasi sebelumnya.

Saya masih tidak mengerti apa itu ML: PHP, Python, sesuatu yang lain?

Kami dulu menggunakan Python untuk kerangka kerja ML, tetapi sekarang mereka beralih ke Spark: ini telah meningkatkan kinerja secara signifikan.

Bagaimana Anda menyeimbangkan beban pada 600 server? Apakah saya mengerti benar bahwa ini adalah monorepa di setiap server, di buruh pelabuhan?

Monorepa di setiap server, kami menyeimbangkannya dengan cara yang cukup standar - menggunakan Nginx.

Apakah Anda menggunakan generator kode? Untuk tugas apa?

Kami cukup sering menggunakannya. Saat mengembangkan, saat Anda perlu membuat model sesuai dengan beberapa deskripsi di konfigurasi, atau jika ada kelas yang harus mengimplementasikan fungsionalitas sesuai dengan template tertentu.

Bagaimana cara kerja replikasi database untuk MySQL?

Saya hanya bisa menjawab secara dangkal.

Bukan rahasia lagi bahwa kami memiliki pusat data di Eropa dan Amerika Serikat, dan perlu untuk menjaga konsistensi data di antara mereka. Kami menggunakan replikasi antara repositori inti untuk menjaga informasi tetap mutakhir di setiap lokasi. Karena fakta bahwa mungkin ada replikasi lag yang besar antar pusat data, kami menggunakan berbagai jenis cache untuk tugas-tugas yang tidak membutuhkan relevansi data.

Bagaimana insinyur Badoo mendukung komunitas PHP berbahasa Rusia? Konferensi, pertemuan, blog, pertemuan informal?

Badoo secara aktif menjadi tuan rumah dan berpartisipasi dalam banyak acara khusus. Ini tertanam dalam budaya perusahaan dan budaya teknisi kami. Pengembang terus berbagi praktik dan pengetahuan terbaik di pertemuan, rapat, dan konferensi internal dan eksternal.

Kami memiliki Pertemuan PHP Badoo: dua kali setahun, di kantor Moskow. Pertemuan terakhir dihadiri sekitar 250 peserta. Rekan saya Vladimir Yants, yang telah saya sebutkan, sedang mengembangkan pertemuan informal di Moskow - BeerPHP Moskow. Dia sudah memiliki pengikut di St. Petersburg, Saratov, dan kota-kota lain. Formatnya, tentu saja, dipinjam dari pertemuan BeerJS yang serupa, tetapi masih sangat keren: dalam suasana informal, berkomunikasi dengan orang-orang yang berpikiran sama, kolega, dan hanya pria dari industri.

Insinyur Badoo secara teratur melayani di komite pemrograman satu-satunya konferensi PHP di Rusia, PHP Rusia. Tahun ini bagian online-nya menjadi internasional dan gratis untuk semua peserta berkat perusahaan kami.

Kami juga memiliki blog di Habré dan Medium , tempat kami membagikan semua perkembangan (tidak hanya di PHP).

Apakah Anda mengambil Juns atau minimal menengah?

Seperti yang saya katakan, Anda harus meninggalkan permintaan. Selama wawancara, akan menjadi jelas apakah Anda sekarang memiliki pengetahuan dan pengalaman yang cukup untuk mulai bekerja di perusahaan, atau Anda harus mendapatkan pengalaman dan pengetahuan yang relevan di tempat lain dan kemudian kembali, seperti yang saya lakukan.

Apakah Anda merencanakan kantor di Amerika?

Kami memiliki kantor di AS, tempat Bumble dihosting - di Austin, Texas. Tetapi tidak ada tim teknik di sana, dan belum diketahui apakah kami akan berkembang.

, soft/hard- ?

Saya sudah mengatakan bahwa semua lowongan terbuka ada di situs web kami tech.badoo.com . Saya menyarankan siapa pun untuk tidak malu, tidak takut, perhatikan persyaratannya dan tinggalkan aplikasi.

Sulit untuk mengatakan ekspektasi spesifik apa yang mungkin dimiliki perusahaan dari seorang kandidat. Saya akan mengatakan: jika, membaca deskripsi, Anda merasa bahwa Anda tidak cocok untuk lowongan ini, Anda perlu melamar 100%. Pengalaman atau pengetahuan yang relevan dapat dipelajari dari orang tersebut melalui beberapa putaran wawancara. Menurut pendapat saya, Anda perlu membuat aplikasi dalam hal apa pun.

Dari hardskills - tentu saja, Anda perlu memiliki pengalaman dan pemahaman tentang cara kerja PHP dan MySQL: ini adalah teknologi utama yang kami gunakan, tumpukan kami dalam hal pengembangan back-end. Departemen lain memiliki tumpukannya sendiri.

Softskills adalah topik yang luas. Menurut saya, banyak pengembangan bukanlah tentang menulis kode, tetapi tentang komunikasi dengan orang. Sangatlah penting untuk menanyakan pertanyaan yang tepat. Jika Anda tahu bagaimana melakukan ini, masalahnya 50% terpecahkan. Selalu ada masalah kesalahpahaman, tetapi semakin sedikit, semakin baik untuk Anda, untuk perusahaan dan produk. Artinya, kemampuan berkomunikasi dengan baik, Anda pasti perlu bekerja dalam tim. Penting juga bagi orang untuk mengetahui bagaimana mengambil tanggung jawab untuk menyelesaikan proyek (fitur, bagian dari fungsionalitas).

Bagaimana proyek PHP Highload dibuat: transcript