Saya ingin berbagi dengan Anda kisah kehidupan yang baik dan kematian yang panjang, lambat dan menyakitkan dari satu portal real estat yang dulu besar. Yang tidak siap untuk berubah dan membuat gerakan tiba-tiba untuk beradaptasi dengan pasar yang berubah. Produk yang dalam 10 tahun telah beralih dari TOP-10 ke bawah. Ini adalah cerita tentang pentingnya utas yang menghubungkan pengembang, dengan pemahaman dan pikiran yang manis, dan manajer / direktur / manajer dengan pendekatan mereka terhadap manajemen proyek.
Mulai
Saya datang ke pekerjaan ini pada tahun 2014, .net junior sederhana. PN (selanjutnya disebut portal real estat) adalah agregator real estat, di mana selain basis data pengumuman ada bagian berita tematik yang berkualitas. Berita, artikel, undang-undang, dan banyak materi berbeda tentang real estat. Departemen besar jurnalis keren menulis artikel yang sangat keren, yang minatnya sangat tinggi di kalangan pengguna.
Situs itu sendiri bebas memasang iklan, yang menarik pengguna (penjual pribadi, agen real estat). Semua pendapatan dihasilkan karena biasanya di daerah ini penempatan iklan blok teks-grafik (TGB) dari pengembang mempromosikan bangunan baru dan bangunan tempat tinggal mereka.
Di masa jayanya (2008 - 2012), situs ini memiliki lalu lintas lebih dari 1.000.000 pengunjung unik per bulan. Dan dia memberikan konversi yang bagus untuk pengiklan. Ini adalah indikator yang sangat baik, mengingat bahwa PN hanya bekerja untuk Moskow dan St. Petersburg. Staf terdiri dari 2 programmer dan banyak jurnalis dan editor. Bahkan, semua pemeliharaan, dukungan, dan penyempurnaan PN dilakukan oleh hanya 2 karyawan (Berapa banyak orang yang awalnya merancang dan mengembangkan sejarah PN diam-diam).
Di sinilah bagian positif dari cerita berakhir.Jatuh
Setelah gelombang pertama krisis, situs tersebut mulai memiliki masalah lalu lintas dan yang sangat serius. Dia baru saja mulai jatuh. Pasar mulai berubah dengan sangat cepat. Pesaing mulai naksir, karena sementara PN kami berpuas diri dan tidak berkembang di mana pun, yang lain membuat produk mereka lebih modern dan memenuhi harapan pengguna.
Selain itu, mesin pencari mulai semakin tidak menyukai situs kami, yang omong-omong praktis tanpa CEO. Ya, ada beberapa templat untuk h1, judul, deskripsi, sedikit penghubungan kembali, dan secara umum, itu saja (setelah awal musim gugur dan sampai akhir, kepala Biara memulai pertempuran CEO, yang telah kami lakukan selama hampir 5 tahun).
Dengan gelombang kedua krisis pada tahun 2014, kinerja turun di bawah 300.000 pengunjung unik per bulan. Sekitar waktu ini, saya mendapat pekerjaan.
Di sinilah bagian teknis saya dari cerita dimulai .
Pencelupan
2 tahun pertama saya bekerja sebagai pengembang junior. Dia melakukan semua yang mereka berikan padaku. Saya harus belajar banyak dari awal. Namun, saya beruntung dengan manajer pengembangan saya. Dia sedikit lebih dari 40 tahun, seorang programmer sekolah tua, yang tahu banyak dan tahu caranya. Mungkin kredo utamanya adalah - itu bekerja dan baik (saya sangat berterima kasih kepadanya, karena saya mengadopsi banyak pengetahuan dan berbagai pendekatan untuk pengembangan).
Tumpukan teknologi kami adalah sebagai berikut:
MS SQL Server 2012 + ASP.NET MVC 3 . Pangkalan itu menyimpan semuanya dengan sendirinya. Bahkan foto dalam bentuk biner, untuk 3 set ukuran (besar, besar, kecil).
Backend termasuk beberapa modul:
- Situs Senin
- Area admin umum
- Admin SEO
- Robot pengurai KLADR
- Robot impor XML feed
Selama ini saya hanya melakukan tugas-tugas agar kodenya bekerja dan tidak ada kesalahan. Terutama tanpa mempelajari atau memikirkan pengembangan lebih lanjut. Tetapi waktunya telah tiba dan sudah menjadi perlu.
Pada tahun kedua kerja, manajer saya meninggalkan proyek. Dan saya berhadapan muka dengan raksasa kuno ini, di mana 3% dari kode saya dengan paksa.
Itu adalah stres liar . CEO menanyakan segalanya kepada saya, dan kadang-kadang saya tidak tahu apa dan bagaimana cara kerjanya. Secara alami, kehidupan membuat saya dan secara bertahap saya menyelidiki semua proses dan menyadari bahwa pendekatan itu "bekerja - baik" bukan untuk saya. Pada saat ini, saya membaca banyak materi desain, dididik di bidang teknologi dan kerangka kerja populer. Saya sedang dalam perjalanan pulang dari kantor dan memikirkan apa dan bagaimana yang akan saya lakukan besok. Dan ketika saya sedang mengemudi untuk bekerja, saya memikirkan apakah apa yang saya putuskan kemarin benar. Saya ingin mengerti bagaimana melakukan semuanya dengan benar dan nyaman. Agar tidak harus membuat kruk, menduplikasi kode, menguji semuanya langsung, menyebarkan semuanya secara manual dan meninggalkan ide-ide bagus karena beberapa kesalahan desain di masa lalu.
Pada saat ini, kami telah melakukan banyak hal di SEO, meninggalkan tugas yang bertujuan untuk meningkatkan UI. Namun, lalu lintas turun semakin rendah. Dan pada titik tertentu proyek itu dibekukan. Saya mulai berurusan hanya dengan dukungan dan koreksi bug ... Jadi itu terdengar resmi.
Bahkan, saya mulai menulis ulang sistem sepenuhnya dari hampir 0. Saya harus melakukannya secara diam-diam dari manual. Lagi pula, mereka tidak pernah memberi kami waktu. Mereka selalu mengatakan bahwa kita perlu lebih cepat, lebih cepat. Bahwa kita berada di belakang semuanya. Dan Anda perlu membuat produk yang kompetitif di 4 tangan dan lebih baik daripada yang lain. Karena itu, jika saya mengatakan bahwa saya berencana untuk mengulang semuanya, maka Anda sendiri mengerti jawaban apa yang akan saya dengar.
Kenaikan imajiner
Jadi, sambil menggulung lengan bajuku, aku mulai hamil. Saya memilih arsitektur tiga tingkat klasik.
.Net Core + SQL + Mongo backend, frontend adalah Bootstrap + JQuery + KnockoutJS .
Mengatur lapisan data. Antarmuka, abstraksi, repositori baik-baik saja. Lapisan bekerja pada prosedur tersimpan (untungnya, saya mulai mengerti SQL dengan cukup baik). Untuk pemetaan saya memilih Dapper. Sederhana dan mudah. Menolak InMemoryCache yang mendukung Redis untuk membawa cache ke server terpisah. Selanjutnya adalah tingkat logika bisnis. Semua antarmuka, layanan, DI yang sama. Maka fondasi muncul dalam bentuk Data-Layer (Stored Procedures + Dapper + Redis) dan Logic-Layer. Butuh sekitar 3 bulan.
Dan di sini, setelah hampir setahun bekerja, saya berhasil mendapatkan asisten untuk saya sendiri, bersikeras bahwa ada banyak tugas (dan ada banyak dari mereka). Bersama-sama, semuanya berjalan lebih cepat dan lebih baik, dan yang paling penting bahkan lebih rasional.
- Pertama-tama, kami mengembangkan API untuk foto . Itu adalah WebApi sederhana, yang pada Get-request memberikan gambar kualitas dan ukuran yang diinginkan dari disk. Kami beralih ke SSD dan lupa tentang basis data gambar sebagai mimpi buruk. Sulit untuk menggambarkan seberapa cepat halaman rata-rata situs mulai memuat setelah mengalokasikan kumpulan terpisah untuk ini.
- Kami meninggalkan KLADRA demi FIAS . Mereka menulis layanan berkualitas tinggi untuk mem-parsing data dari FIAS ke database kami, dengan mempertimbangkan fitur-fitur kami. Mereka mengacaukannya layanan untuk geocoding rumah. Semuanya bekerja hampir seperti jam. Hanya kadang-kadang ada bug yang terkait dengan lokasi duplikat atau jalan di basis data FIASA.
- Kemudian mereka menulis akun pribadi baru untuk waktu yang lama, membagikannya dari situs. Ini dirancang dan direncanakan untuk waktu yang lama sehingga mudah digunakan. Serta cepat dan fungsional. Mereka mengacaukan pembayaran kepadanya, dan kemudian fiskalisasi cek (ya, kami tidak mampu menggunakan solusi terintegrasi yang sudah jadi). Secara keseluruhan membuat layanan pengguna yang baik. Dan mereka senang dengannya.
- Akhirnya, kami sampai di robot untuk mengimpor umpan XML . Membuat validator yang nyaman dan pencatatan yang baik untuk pelanggan. Layanan baru ternyata sangat dioptimalkan sehingga jika yang lama (menggunakan EF) bekerja sekitar 6-8 jam, maka yang baru memproses jumlah data yang sama dalam 2-3 jam.
- Lagi pula, mereka mengangkat domain dengan dokumentasi untuk semua yang ada. Mereka menjabarkan semua poin untuk pengguna dan pelanggan portal, dan juga menggambarkan bagian dari dokumentasi yang akan berguna bagi pengembang. Dan ini sangat penting!
- Langkah terakhir adalah mengoptimalkan basis . Kami benar-benar memperbaikinya. Kami membersihkan semua yang tidak perlu. Mereka mencapai percepatan kecepatan pencarian dari 4-5 detik hingga ~ 300 ms . Mereka membuat indeks, menulis kueri kompleks, menggunakan petunjuk, dan bahkan membuat partisi tabel statistik.
Sayangnya, tangan-tangan itu tidak berhasil masuk ke situs itu sendiri. Karena hampir semua tugas dengan situs terkait dengan SEO, yang membutuhkan waktu yang cukup lama. Halaman baru, koleksi baru, aturan baru. Lebih banyak, lebih banyak, lebih banyak halaman. Saya harus terus mengedit sesuatu di mesin situs, yang tidak memungkinkan saya untuk mentransfernya secara bersamaan ke basis yang dibuat.
Di sini kisah teknis berakhir dan epilog sedih dimulai.
Perlu dimulai dengan fakta bahwa CEO situs tidak terhubung dengan bidang TI. Karena itu, banyak keputusan yang dibuat oleh mereka secara tidak benar dan individual. Sangat sering diskusi terhenti, seperti ide-ide baru kami tidak diterima, karena
"Ini tidak perlu, aku memberitahumu sebagai ahli real estat"
atau
"Jadi tidak ada yang melihat, ini permintaan frekuensi rendah, aku yakin"
Dan setelah beberapa waktu, ketika dia sendiri datang ke sini, ide-ide kami ditawarkan kepada mereka dengan klaim, mengapa kami tidak mengatakan sebelumnya, atau dengan kejutan yang tulus
"Aku tidak bisa mengatakannya, ini tidak masuk akal"
Kami tidak dapat mencapai konsensus, akibatnya, kami (pengembang) lebih rendah. Dan mereka melakukan seperti yang diminta. Rasa sakit Programmer - untuk membuat "fitur" yang tidak berguna bagi siapa pun.
Saya ingin menyebutkan bahwa keuangan selalu memiliki masalah.
Tidak ada investasi, kecuali dalam SEO . Bahkan menjaga 2 programmer itu mahal. Jelas mustahil untuk bersaing dengan portal baru dari TOP-10 dengan tingkat keuangan dan manajemen yang sedemikian tinggi.
Sebagai hasilnya, kami memiliki platform untuk portal agregator real estat. Dapat diukur, diperluas, cepat, dan siap secara teknis untuk setiap bencana. Dengan potensi besar. Kode yang baik, kruk minimum dan beberapa kemacetan.
Namun, ini tidak memberikan hasil yang positif. Pada saat hari kerja terakhir saya, meskipun terdapat 4 juta halaman unik di mesin pencari, lalu lintas portal berfluktuasi sekitar 1.400 halaman unik per hari. Dan ini, menurut saya, menyatakan kematian.
PS: Dari keseluruhan cerita saya pribadi bisa saya buat satu kesimpulan utama. Anda dapat membuat produk yang bagus dari sudut pandang pengembang, tetapi itu sama sekali tidak diminati, karena tidak memiliki manajemen yang tepat. Jika jalinan antara karyawan yang membuat bisnis terapung sobek, maka produk Anda pasti akan turun ke bawah.