Halo, Habr! Di Luxoft TechFest yang diadakan pada tanggal 28 Januari, Mikhail Zankovich, Pemimpin Tim Senior di Luxoft , berbicara tentang aplikasi dengan faktor keturunan yang parah. Hari ini dia membagikan pemikiran tambahan yang terkait dengan isi laporan ini, yang menyebabkan diskusi yang cukup panas selama pertemuan.
Emosi dan asosiasi apa yang dibangkitkan oleh frasa "We have a legacy project"? Paling sering - kurangnya struktur, kekacauan, banyak kode tidak berdokumen, horor, anarki arsitektur, rasa jijik, lautan kruk, Anda harus lari! Emosiku: “Oh! Akhirnya, sesuatu yang menarik. Mari kita lakukan! " Saya menduga ini adalah reaksi yang sangat tidak biasa.
Pada artikel ini saya akan mencoba mengungkap ideologi berbeda dari bekerja dengan warisan. Mari kita tentukan sebagai "pemulihan perangkat lunak". Saya tidak bermaksud untuk mengubah sikap Anda terhadap Legacy, tetapi jika Anda berhasil setidaknya menabur sedikit keraguan bahwa Legacy mungkin menarik, saya akan senang.
Warisan khas
Apa itu Legacy? Menurut pengalaman saya, Anda dapat membuat daftar periksa berikut untuk kepatuhan produk lama:
- .
.. , , .
- .
, black-box. . . - .
, . - .
. / ..
Semua ini mengarah pada fakta bahwa semakin sulit untuk mempertahankan proyek seperti itu dengan setiap rilis, seperti mengerjakan fungsionalitas baru / persyaratan baru. Setiap perubahan berubah menjadi rekayasa balik dengan pengujian regresi wajib, dll. Akibatnya, proyek menjadi mahal untuk dipelihara dan "dibekukan" dalam bentuknya saat ini dengan meminimalkan perubahan apa pun.
Tetapi mengapa produk lama muncul?
Jarang tim secara sadar dan sengaja menciptakan produk berkualitas rendah. Seringkali ini adalah hasil dari peluang yang dibatasi oleh situasi proyek saat ini.
Tidak ada persyaratan yang jelas - tidak ada kemungkinan desain yang seimbang dari fungsionalitas aplikasi.
Persyaratan yang terus berubah, formulasi yang tidak jelas, jadwal implementasi yang ketat, hutang teknis yang terus tumbuh adalah tanda-tanda yang jelas dari proses pengembangan yang gesit dalam tim yang belum dapat sepenuhnya beradaptasi dengan pendekatan "tangkas" ini. Dan dari "fleksibel" hanya "permintaan yang berubah dengan cepat dari bisnis" bekerja.
Hal ini sering kali menyebabkan peningkatan rotasi dalam tim, yang pada gilirannya tidak berdampak positif pada kualitas. Bayangkan seorang spesialis baru bergabung dengan tim, selama dua atau tiga bulan dia hanya mempelajari prosesnya, kemudian selama satu setengah atau dua bulan dia menerapkan beberapa jenis fungsi dan bersiap untuk keluar dari proyek. Dia tidak tertarik dengan produk yang berkualitas, dokumentasi lengkap dari bagiannya, transfer pengetahuan ke rekan kerja, dll. Keahlian kabur.
Pada titik tertentu, keputusan fatal dibuat: lebih mudah untuk mengganti / mematikan daripada menemani. Dan proyek memasuki fase "pemeliharaan rendah", ketika didukung dengan basis sisa, mencoba meminimalkan perubahan, membuat "kruk" tambahan yang menerapkan permintaan baru dengan cepat tetapi buruk. Mengapa berkualitas tinggi? Produk akan berubah. Dalam mode ini, produk dapat bertahan selama bertahun-tahun, ditumbuhi "kruk" dan menjadi lebih mengerikan.
Meringkas semua hal di atas, alasan utama kemunculan produk warisan berikut dapat diidentifikasi:
- tenggat waktu yang ketat untuk implementasi fungsi;
- kurangnya persyaratan yang jelas / persyaratan yang berubah secara intensif;
- peningkatan rotasi dalam tim;
- perencanaan siklus hidup yang tidak tepat.
Kami menambahkan di sini tingkat pengembangan profesional spesialis saat ini. Buka proyek Anda lima atau sepuluh tahun lalu. Saya yakin Anda dapat dengan mudah menemukan elemen yang akan Anda terapkan secara berbeda sekarang.
Jadi, kami mengambil aksioma: "kode tidak dibuat secara inheren buruk". Artinya, setiap produk memiliki semacam ide. Dan jika kode tersebut masuk ke produksi, maka kode tersebut berfungsi dan memenuhi kebutuhan bisnis pada saat itu.
Pendekatan pendamping
Tugas di pihak pelanggan cukup sederhana: untuk mempertahankan warisan dalam keadaan berfungsi tanpa mengganggu proses bisnis saat ini (beberapa di antaranya umumnya tidak diketahui siapa pun), sambil mengembangkan fungsionalitas sesuai dengan persyaratan baru sesuai dengan anggaran, yang mana kemungkinan besar terbatas.
Pendekatan khas tim yang memulai sebuah proyek adalah terus perlahan tapi pasti memperburuk keadaan. Jangan terlalu banyak menyentuh, ubah hanya apa yang diminta dan hanya ketika diminta. Jika modul berfungsi, tetapi membutuhkan modifikasi logika - biarkan dan jangan menyentuhnya - lebih baik membuat yang lain, tetapi dengan logika yang diperlukan. Kekacauan berkembang, aplikasi menjadi lebih rumit.
Pendekatan pemulih
Pendekatan dari pemulih perangkat lunak adalah untuk mengetahui jenis mekanisme yang ada di depannya. Apa ide utama di balik penciptanya. Cobalah untuk memotong semua yang tidak perlu dan pertahankan yang terbaik. Jika Anda mengubah struktur yang ada, maka sangat berhati-hati dan memperhatikan detailnya. Tidak ada satu pun detail yang memengaruhi sistem yang harus disembunyikan dari tampilan pemulih. Perubahan yang diperkenalkan pertama kali dikerjakan sesuai dengan logika pemeliharaan, dan kemudian analisis dilakukan untuk menentukan kemungkinan penerapan solusi lengkap.
Ini adalah pekerjaan yang sulit dan memakan waktu. Tidak semua developer mau, dan yang terpenting, benar-benar mampu melakukan restorasi. Persyaratan untuk tingkat pemulih adalah urutan besarnya lebih tinggi daripada untuk pengembang biasa. Tanpa pengalaman dalam proyek nyata, tanpa memahami bagaimana sistem dapat berkembang, tanpa benturan tidak hanya dengan pendekatan terbaik dalam praktik, tetapi juga dengan implementasi yang jelas tidak berhasil, tidak ada gunanya memulihkan.
Alih-alih dorongan pertama yang khas, “Ya, ini kruk! Semuanya perlu ditulis ulang di sini! " - pemulih sejati akan menanyakan pertanyaan “Mengapa dilakukan seperti ini? Bagaimana tepatnya itu direncanakan untuk menggunakannya? " Dan hanya setelah memastikan bahwa tidak ada prasyarat yang jelas untuk pembuatan kode seperti itu, pemulih dapat berseru: “Ya, ini kruk! Semuanya perlu ditulis ulang di sini! ”, Dan dengan rasa pencapaian, dia benar-benar dapat menghentikan pertumbuhan yang tidak perlu pada kerangka perangkat lunak yang sudah diperkuat, membuat objek restorasi lebih baik dan berkualitas lebih tinggi.
Namun hal ini jarang terjadi, meski memberikan kenikmatan yang tak terlukiskan kepada sang pemulih. Paling sering, Anda harus mengurai kusutnya dependensi antara modul yang berbeda. Tidak jarang utas meregang jauh melampaui area tanggung jawab komponen yang dibongkar (dan terkadang sistem). Dan semua seluk-beluk hubungan modul ini harus diperhitungkan saat memulihkan.
Dengan demikian, pemulih perangkat lunak bekerja di persimpangan antara pengembangan, arsitektur, analisis bisnis, pengujian, dan pengobatan. Dan sulit untuk mengatakan keterampilan mana dari bidang yang ditentukan yang merupakan prioritas tertinggi. Harus ada keseimbangan tertentu di antara mereka, dibumbui dengan keinginan yang jujur untuk terlibat dalam pemulihan. Apa hubungannya obat dengan itu? Jadi prinsip utama pemulih adalah "primum non nocere" - pertama-tama, jangan merugikan.
Sebenarnya, pendekatan ini akan dipertimbangkan lebih lanjut pada contoh spesifik, secara bertahap membongkar dan memulihkan warisan tipikal yang diwarisi dari pemilik teknis sistem sebelumnya. Dan dengan contoh spesifik, mari kita lihat mengapa semua keterampilan di atas penting.
Restorasi data warehouse
Apa yang disimpan sistem?
Mendarat di proyek baru, pemulih akan memperhatikan objek yang diproses oleh sistem. Untuk sepenuhnya membenamkan diri Anda dalam arus bisnis dan kode sumber, terutama jika tidak ada dokumentasi normal, diperlukan setidaknya beberapa bulan.
Salah satu tugas pertama pemulih adalah menilai keefektifan lemari besi. Bisakah Anda meningkatkan sesuatu tanpa mengandalkan pemahaman tentang proses bisnis? Titik sakit khas dari setiap gudang data terutama terkait dengan volume data ini. Semakin besar volumenya, semakin tinggi biaya kepemilikan sistem.
Titik sakit kedua adalah pertumbuhan volume ini, yang secara negatif mempengaruhi kinerja sistem. Kemungkinan besar, sudah ada beberapa praktik untuk menyimpan informasi dalam sistem, tetapi seberapa efektif praktik tersebut?
Semua praktik yang dipertimbangkan di sini lebih dapat diterapkan pada RDBMS klasik, tetapi pendekatannya tidak terlalu berbeda untuk solusi tanpa sql.
Salah satu taktik utama pemulih ke arah ini adalah pembuatan pemantauan objek penyimpanan informasi. Dalam kasus DBMS klasik, pemantauan tabel.
Diperlukan kerangka kerja yang memungkinkan metadata sistem mengumpulkan data secara berkala pada dua parameter sepele - jumlah data dan jumlah elemen di setiap tabel. Frekuensi harus dipilih secara manual (lebih lanjut di bawah ini), berdasarkan karakteristik sistem. Periode start-up yang khas selama 24 jam sudah cukup untuk analisis dasar.
Menganalisis data
Apa yang harus dilakukan dengan data? Apa yang dicari? Momen pertama adalah mengidentifikasi "benda berat" yang paling. Dalam praktiknya, aturan standar 20/80 berfungsi - tidak lebih dari 20 persen objek akan menggunakan lebih dari 80 persen ruang. Ini memungkinkan Anda mempersempit area analisis secara signifikan pada tahap pertama.
Semakin lama dan lebih rinci statistik tersebut diakumulasikan, semakin jelas perilaku sistem yang tercermin. Pengalaman menunjukkan bahwa periode yang disarankan adalah setidaknya dua minggu. Ide utamanya adalah untuk "mengaitkan" hari / periode non-kerja di mana mekanisme untuk pembersihan dan pengarsipan informasi paling sering diterapkan.
Jadi kerangka kerja ditulis, dan pemulih menunggu hasilnya selama dua minggu? Tentu saja tidak. Itu tidak melawan ideologi pemulih. Dengan potongan data pertama di tangan, Anda dapat melakukan beberapa analisis dasar. Yaitu - untuk melihat rasio ruang yang ditempati dengan jumlah objek yang disimpan (baris). Semakin besar nilai ini, semakin besar kemungkinan bidang BLOB disimpan di sini. Dan hanya tabel dan bidang ini yang menjadi objek penelitian dan analisis bagi pemulih.
Pertanyaan kunci: Seberapa sering proses bisnis sebenarnya mengakses objek-objek ini? Pemilik sistem, tim yang ada, dapat menjelaskan poin-poin tersebut. Dan tiba-tiba (dan dalam praktiknya sangat sering) ternyata bidang seperti itu menyimpan informasi yang tidak penting bagi bisnis: tumpukan objek / pesan untuk dianalisis oleh tim pengembangan, komentar pengguna hanya ditampilkan saat membuat pesanan, dll.
Langkah selanjutnya: Jika data tidak sering digunakan, atau tidak memiliki nilai bisnis yang jelas, mengapa tidak dipindahkan ke arsip? Pada saat yang sama, pendekatan utama dengan membagi tabel monolitik menjadi beberapa bagian, memindahkan blob ke media yang lebih murah / lebih lambat, tetapi pada saat yang sama mempertahankan antarmuka asli tabel (poin utamanya adalah bahwa tidak ada informasi yang dapat diandalkan tentang semua proses mengakses informasi ini, yang berarti bahwa perubahan tidak boleh merugikan mereka) - bisa menjadi masalah teknis yang cukup menarik dan kompleks.
Tugas yang kurang menarik tetapi sama-sama berguna adalah menggunakan sistem penyimpanan data bawaan untuk mengarsipkan nilai bidang tertentu. Misalnya, Sybase ASE memiliki fitur ASE_Compression, Mongo DB memungkinkan Anda mengatur opsi kompresi untuk koleksi, dll. Hampir semua sistem penyimpanan data memiliki opsi kompresi data tambahan "di bawah tenda". Fungsionalitas tersebut akan bekerja secara transparan untuk sistem eksternal dan tidak memerlukan perubahan drastis. Dalam praktiknya (terutama pada sistem lama) opsi kompresi data seperti itu tidak digunakan secara default.
Tentu saja, saat menerapkan kompresi, pemulih harus terlebih dahulu menilai dampak pendekatan terhadap kinerja, dan untuk ini, indikator kinerja utama sistem harus dikerjakan, atau, dalam kasus ekstrem, elemen pengujian regresi harus ada.
Secara umum, ada sesuatu yang harus dilakukan selama beberapa minggu sementara statistik lengkap tentang objek dikumpulkan.
Statistik besar: apa yang harus dicari
Setelah menerima statistik dalam jangka waktu yang lama, pemulih mencoba untuk mencari tahu apa yang terjadi dengan dinamika ruang yang digunakan. Semua nilai untuk satu tabel / objek dinormalisasi ke yang asli. Ini akan memungkinkan untuk memperkirakan dengan tepat peningkatan relatif dalam data dan untuk mengidentifikasi objek yang paling berubah secara intensif.
Profil yang dihasilkan kemungkinan besar akan sesuai dengan salah satu jenis berikut:
Profil 1 - nilai konstan. Kemungkinan besar, ini adalah direktori statis dan tidak begitu menarik untuk bekerja dengannya. Pendekatan pengarsipan yang dijelaskan di atas dapat diterapkan berdasarkan intensitas penggunaan direktori.
Fluktuasi kecil dalam volume - profil 2- mereka dapat berbicara tentang buku referensi dan tabel operasional, di mana membaca / menulis datanya intensif. Ini adalah objek yang paling sulit dari sudut pandang pemulih, karena penting untuk menganalisis perilaku mereka sedetail mungkin. Untuk objek-objek inilah masuk akal untuk meningkatkan frekuensi pengumpulan informasi: tidak sekali sehari, tetapi sekali satu jam, sekali satu menit. Tujuan utamanya adalah untuk melacak perubahan profil secara lebih rinci dan memahami ketergantungan perilaku.
Profil 3 dan 4 lebih menarik Profil 3(“Saw”) dengan jelas menyatakan bahwa tabel ini dibersihkan secara berkala. Tetapi tren yang berkembang - setiap kali setelah pembersihan, volume akhir sedikit lebih besar dari sebelumnya - berbicara tentang inefisiensi mekanisme pembersihan yang ada. Itu. selama periode waktu tertentu, lebih banyak data yang muncul di sistem daripada yang dihapus di akhir periode. Ini mungkin proses bisnis yang sepenuhnya normal, peningkatan klasik dalam beban pada sistem.
Tetapi bagi pemulih, ini, pertama-tama, adalah sinyal: apakah ada kondisi untuk menghapus informasi? Berdasarkan praktik, kemungkinan besar beberapa entitas, karena kondisi kompleks retensi data dalam sistem, secara tidak semestinya tetap berada di penyimpanan selamanya. Tujuan pemulih adalah untuk mengidentifikasi entitas tersebut dan juga memasukkannya dalam aktivitas berkala.
Jika profil 3 merosot menjadi pertumbuhan konstan, ini adalah pesaing pertama untuk kemacetan dalam sistem. Pertama, tidak ada petunjuk eksplisit untuk proses pengarsipan, dan kedua, penurunan kinerja diharapkan dengan pertumbuhan data.
Profil 4- contoh tipikal tabel arsip dengan pengisian data berkala. Perlu diketahui bahwa pertumbuhan tabel hanya terjadi pada hari-hari tertentu. Sangat mungkin bahwa korelasi dengan tabel dari profil ketiga akan terlihat. Untuk tabel arsip, penting juga untuk memahami prinsip penggunaannya - apakah ada panggilan dari pengguna? Atau apakah itu sebuah cerita untuk dianalisis? Atau apakah itu data untuk sistem pelaporan? Bergantung pada jawaban atas pertanyaan-pertanyaan ini, sangat mungkin bahwa keputusan akan dibuat untuk memisahkan tabel arsip menjadi sirkuit terpisah, basis terpisah, bagian terpisah. Dengan demikian, membebaskan ruang operasional.
Bagaimana cara kerjanya dalam praktik?
Di salah satu proyek, latihan serupa dilakukan pada satu setengah bulan pertama setelah bergabung dengan proyek. Itu adalah objek profil No. 3 yang menjadi target, dan mereka ditemukan. Menerapkan praktik yang dijelaskan (meningkatkan kondisi pembersihan), menghapus data yang tidak digunakan dalam sistem, dll. diizinkan untuk mengurangi volume ruang yang ditempati lebih dari 25%, serta menghentikan pertumbuhan penyimpanan yang intensif.
Hasilnya, kami dapat membuat perubahan teknis pertama pada proyek dan mengirimkan rencana untuk meningkatkan fungsionalitas. Pelanggan puas dengan hasil tim, dan itu berkembang dari 3 menjadi 9 pengembang. Sepanjang tahun kami melanjutkan penyelidikan, poin peningkatan fungsionalitas digunakan untuk mendukung sistem dan karakteristiknya.
Dua analis telah ditambahkan ke kami, sehingga tim mulai terlibat dalam pengembangannya sendiri - bukan dukungan, tetapi implementasi fungsi bisnis baru. Kami sekarang sedang mengembangkan sistem baru.
Untuk apa ini semua?
Jika Anda telah membaca sejauh ini, kemungkinan besar Anda sedang mencari jawaban untuk pertanyaan: "Mengapa semua ini?" Pertama-tama, restorasi adalah proses yang terpisah, tidak seperti pengembangan, bukan dukungan, tetapi menggabungkannya.
Ini adalah dorongan terpisah untuk spesialis teknis - untuk mempelajari logika orang yang membuat produk ini, untuk memahami artinya, untuk membersihkan produk dari hal-hal yang tidak perlu dan membuatnya lebih baik dari sebelumnya. Aplikasi ini terlihat seperti sebuah pencarian, dengan banyak misteri dan alur cerita yang tidak diketahui.
Tidak, Anda tidak membuat dari awal, Anda memulihkan produk yang sudah ada, tetapi mungkin hancur oleh waktu. Antara lain, pemulih memiliki kesempatan unik untuk memompa ke salah satu dari enam arah (lihat gambar di atas), sambil memiliki produk nyata di tangan sebagai basis pengujian. Perasaan pengendalian diri juga dipompa - tidak jatuh ke dalam kesempurnaan teknis, tetapi untuk memikirkan dan hanya membuat perubahan yang diperlukan untuk sistem dalam hal meningkatkan proses.
Semua ini membuat bekerja dengan sistem lama menjadi menarik dan tidak biasa. Tetapi pilihan terakhir untuk memulihkan atau memelihara ada di tangan Anda.
Laporan Mikhail Zankovich di Luxoft TechFest dapat dilihat di sini .
Penulis artikel tersebut adalah Mikhail ZankovichMikhailZankovich