Hai Nama saya Ivan Melnichuk, saya Kepala Departemen Pengembangan di sebuah perusahaan IT Ukraina. Dalam publikasi saya ingin berbagi pendekatan profesional pribadi saya mengenai penyelesaian masalah kode warisan dalam konteks perkembangan cepat proyek dan menceritakan tentang teknik yang digunakan oleh tim kami dalam kasus "ketika fitur perlu diserahkan" untuk kemarin ".
Kami berurusan dengan proyek
Untuk menyampaikan seberapa akurat, bijaksana dan susah payah bekerja dengan warisan, saya akan memberikan analogi dengan rumah kartu.
Ini adalah kode legacy. Jika kami memutuskan untuk melepas atau mengganti setidaknya satu kartu dari gedung ini, kami berisiko membanjiri seluruh rumah dan meratakan sisa-sisanya dengan tanah.
Warisan berperilaku kira-kira dengan cara yang sama. Oleh karena itu, pekerjaan seorang programmer yang mengambil tugas memodernisasi dan "bernafas kehidupan kedua" ke dalam proyek harus sampai batas tertentu perhiasan. Sebagian besar programmer mencoba untuk menghindari dan umumnya "melompat dari topik" hutang teknis. Bahkan menyusun parade hit dari kutipan paling umum yang harus didengar dari programmer yang tertangkap dalam kondisi lama:
- Kami membuat situs "sederhana", dan sekarang Anda ingin mendapatkan "roti" baru, dan kami perlu menulis ulang semua ini, karena kami memiliki warisan ...
- Tidak ada yang tahu bagaimana ini bekerja ..
- Untuk menambahkan modul, Anda perlu memeriksa seluruh situs - hanya dengan cara ini kami akan mengerti apa dan di mana itu bisa keluar ...
- Saya tidak akan pergi ke sana dalam hal apapun, semuanya sudah buruk di sana ...
Tetapi pengalaman dalam pemrograman menunjukkan bahwa kehidupan setelah warisan ada. Tidak ada masalah dengan pemrograman. Hanya ada tugas yang perlu ditangani. Dan sebelum menyusun rencana tindakan "untuk mengatasi kode warisan", Anda perlu memahami seberapa buruk hal-hal buruk pada proyek secara keseluruhan. Dalam praktiknya, ia mengidentifikasi 6 tahapan masalah proyek:
- Tidak ada dokumentasi teknis. Ambang masalah terendah, karena Anda dapat menguji dan sampai pada perkiraan awal tentang bagaimana ini seharusnya bekerja.
- Tidak ada dokumentasi bisnis. Jika semua dokumentasi (baik teknis dan bisnis) hilang, perasaan "sepertinya kita terjebak dalam sejarah" tanpa sadar datang. Memang, bahkan sebuah bisnis tidak ingat bagaimana ini harus bekerja, yang berarti bahwa tim, setidaknya, tidak memiliki pemahaman tentang hasil yang diharapkan.
- Tidak ada yang mendesain ini. Jika, selain kurangnya dokumentasi, juga tidak ada pengembang yang bisa menjelaskan bagaimana proyek seharusnya bekerja, maka itu sudah tercium.
- Kami tidak tahu apa yang harus didapatkan pengguna pada akhirnya. Ini adalah satu hal ketika pertanyaan muncul hanya di sekitar backend, tetapi jika kita masih sama sekali tidak tahu apa yang harus ditampilkan di depan, maka ini sudah dekat dengan keadaan "pasien lebih mungkin mati daripada hidup".
- 200+ penggunaan setiap fungsi dan mereka disebut getA . Tingkat kesulitan kelima: ketika Anda masuk ke Legacy, Anda melihat fungsi A dan 200 penggunaan, dan tidak ada yang tahu mengapa itu ...
- Tidak ada programmer yang ingin / bisa mengembangkan. Tidak ada komentar
Memahami bisnis
Bisnis menghitung uang. Bisnis tidak ingin menghabiskan sumber daya keuangan tambahan hanya untuk mengulangi apa yang sudah berfungsi. Sebuah bisnis tidak akan pernah membeli ide: "Saya akan melakukannya dengan cara baru karena saya tidak menyukainya." Karena itu, selalu menawarkan lebih banyak.
Seringkali, pengembang mendorong bisnis ke ide-ide yang tidak berguna. Pada kesempatan ini, ada "dana kutipan emas" yang terpisah.
- Kami sedang merekrut tim baru untuk “menggergaji” kode berkualitas tinggi. Artinya, kita membutuhkan tim spesialis yang akan melakukan proyek secara paralel dengan tim yang ada. Bukan fakta bahwa hasilnya akan berbeda, tetapi bisnis seharusnya sudah mengandung dua proyek.
- Kami berhenti menambahkan fitur, sekarang hanya refactoring! Secara resmi Anda mendeklarasikan ke bisnis: Benar-benar tabu pada fitur, hanya mungkin untuk "menertibkan" di bawah tenda. Secara tidak resmi, Anda mengatakan bahwa tidak akan ada peningkatan skala besar dan peningkatan proyek, hanya "memperbaikinya" secara lokal.
- Saya sudah memiliki semua yang saya butuhkan di WP, saya hanya perlu memigrasi basis data. Ini adalah "gejala" dari seorang pemula. Lagu favorit Juni: ini adalah situs yang sederhana, hanya bekerja selama satu atau dua jam ...
Untuk bernegosiasi dengan bisnis mengenai reinkarnasi kode usang, yang disajikan di bawah saus fitur menguntungkan baru, perlu dari posisi membuka cakrawala bisnis baru. Namun, sebelum negosiasi, pertanyaan-pertanyaan berikut harus dijawab:
- Apakah bisnis sudah siap untuk tumbuh? Anda perlu memahami: apakah bisnis memiliki permintaan untuk meningkatkan standar keuangan atau hanya perlu layanan untuk bekerja lebih kompeten.
- Tahap prototipe? Seringkali, suatu bisnis memesan prototipe sederhana, yang dengannya ia ingin “menyelidiki” pasar pada saat relevansi produk. Dan hanya jika ia mulai menghasilkan uang, bisnis siap untuk mengembangkan fitur menjadi proyek yang lebih maju dan lengkap.
- Pengembangan selesai dan sekarang hanya mendukung? Penting untuk memahami berbagai tugas.
- Apakah ada cukup api di mata kita dan tidak akan padam? Proyek ini harus menginspirasi, bukan mendemotivasi. Sangat penting bahwa tim Anda ingin terlibat dalam reinkarnasi Legacy, jika tidak orang akan secara bertahap menyebar ke proyek yang lebih menarik bagi mereka.
- Apakah ada arsitek? Ini adalah pertanyaan yang paling penting - apakah Anda memiliki orang yang dapat membuat arsitektur yang tepat dan mulai menulis kode yang baik. Tidak masuk akal untuk mencoba memulai jika tidak ada arsitek. Jika tidak, dalam seminggu Anda akan menjadi orang yang menciptakan masalah warisan.
Saat Anda menjual ide ke bisnis, fokus pada pesan "baru, buat, tambahkan" ... Bisnis merespons dengan sangat baik penawaran dari seri: "Kami akan membuat Anda fitur baru dan proyek X akan lebih cepat ..." dan "Untuk meningkatkan konversi, tambahkan yang baru ... ”
P - Perencanaan
Untuk bekerja dengan cepat dan efisien dengan utang teknis, Anda memerlukan rencana.
1.
Definisi tugas yang akan kita parasitisasi. Mengapa parasit Ini sering terjadi: kami menjual fitur, dan sebagian kami maksudkan refactoring.
2.
Definisi persyaratan tingkat tinggi. Penting untuk mendaftarkan permintaan bisnis yang jelas untuk "standar tinggi" untuk menyusun dokumentasi yang benar.
3.
Definisi modul utama sistem, pembebanan modul. Sebelum memulai refactoring, Anda perlu memahami modul utama sistem: di mana, bagaimana, apa, dan dengan apa yang dapat berinteraksi dan membatasi kode menjadi beberapa bagian.
4.
Definisi integrasi. Saat membuat modul tertentu, kita perlu memikirkan terlebih dahulu tentang kemampuan untuk memasangnya di warisan tetangga.
5.
Definisi tim. Satu di bidang refactoring bukanlah seorang pejuang. Tim adalah elemen yang sangat penting dari hasil yang sukses. Semangat, dorongan tim, dan interaksi yang sangat baik antara para peserta dalam harus memiliki proses.
6.
Bagaimana kita akan menguji? Jika Anda akan mengambil proyek berkualitas tinggi, maka Anda harus berpikir ke depan dan opsi pengujian produk.
Bersamaan dengan hal di atas, penting juga untuk menentukan seperti apa hasil akhir yang diinginkan, menyusun rencana penskalaan, dan mendaftarkan kemacetan proyek. Misalnya, dalam kasus penskalaan kode, penting untuk memahami di mana masalah berpotensi timbul dalam kondisi beban tinggi (dapat berupa database, atau kueri berat, atau kisi, atau tautan perantara lainnya yang dapat "jatuh").
Sama pentingnya untuk menentukan batas-batas proyek, di mana ada kode lama dan di mana akan ada tingkat baru "karya besar". Anda juga harus mempertimbangkan pendekatan untuk layanan-layanan microser, atau DDD, atau, mungkin, Anda memerlukan lebih banyak "nanomagy".
Teknik Warisan Ninja
Setelah "pekerjaan persiapan" kita sampai pada teknik yang memfasilitasi proses menabung utang teknis. Tidak ada resep dan obat mujarab universal untuk semua penyakit di Legacy, tetapi saat mengerjakan proyek highload saya membuat daftar bahan-bahan yang dengannya Anda dapat menyiapkan kode yang benar-benar “enak”.
1.
Jangan menemukan kembali roda. Bagi saya, ini adalah hack kehidupan utama untuk menulis kode. Semuanya telah ditemukan sebelum Anda, jangan resor untuk menari dengan rebana dan eksperimen lain untuk memecahkan masalah dengan kode warisan.
2.
Kode standar. Tanpa standar tunggal, setiap pengembang akan menulis dengan caranya sendiri. "Gaya penulis" akan berkontribusi pada kekacauan dan meningkatkan lebih banyak lagi kode sampah.
3. Ulasan
kode. Tidak hanya satu keberadaan standar kode. Tim juga bertanggung jawab untuk memeriksanya. Kalau tidak, semuanya akan kembali normal, yaitu ke level kode lama.
4.
Analisis Kode Statis, detektor kekacauan PHP dll (bukan seribu buku) . Ini dan teknik otomatis lainnya akan diperlukan untuk mempercepat proses, khususnya dengan kode ulasan yang sama.
5.
Kami mencoba layanan microser. Secara terpisah, mungkin ada modul atau perpustakaan. Mengapa layanan microser? Keuntungan mereka adalah mengisolasi logika sebanyak mungkin dan membatasinya pada API tertentu. Keuntungan dari yang terakhir adalah bahwa API adalah entitas yang lebih monolitik dibandingkan dengan "adaptor dalam kode yang dapat diperbaiki". Namun, API memiliki satu kelemahan dalam bentuk biaya jaringan tambahan.
6.
Arsitektur basis data, sumber data. Ini adalah basis data yang saya anggap sebagai bottleneck pertama dari Legacy apa pun. Tetapi semua orang mendesain sesuai keinginannya, dan bahkan dalam SQL, Anda dapat menemukan kekurangan yang tidak fokus. Berikut ini beberapa kiat untuk bekerja dengan database baru:
- Sekrup tidak apa-apa, haus untuk segalanya. Jika Anda ingin mengubah struktur data yang salah menjadi format data baru, lebih cepat dan lebih produktif, Anda bisa menggunakan dua cara. Yang pertama adalah menempatkan di basis baru, benar-benar menghapus yang lama, dan apa pun yang terjadi. Yang kedua - dalam kasus warisan keras, memperkenalkan format baru secara paralel. Secara kiasan, untuk menanam yang baru di dekat pohon tua. Mengapa cara kedua dibenarkan dan lebih menjanjikan? Karena semua yang baru akan bekerja secara efisien, dan jika masalah muncul selama tahap penerapan atau integrasi, Anda dapat memutar kembali kode, dan tidak perlu memutar kembali semua migrasi basis data yang kompleks.
- Database baru dibuat dalam struktur yang benar. Saat membuat sumber daya baru, penting untuk mengontrol tempat kita menulis struktur baru. Secara paralel, perlu untuk membuat dukungan untuk struktur lama, karena tidak praktis untuk menyingkirkannya sepenuhnya. Artinya, kami terus menulis materi baru, dan pada saat yang sama kami mendukung templat lama, di mana kami menerjemahkan semua yang baru, dan dengan demikian memungkinkan yang lama untuk bekerja juga - seolah-olah dengan cara lama, tetapi mendukung struktur baru.
- Kami mengontrol seluruh rekaman. Kami tidak ketinggalan detail dari bidang perhatian untuk menjamin dukungan database.
7.
Tapi SQL? Jika dari sudut pandang arsitektur Anda dapat beroperasi dengan entitas - beroperasi. Konsep sesuatu yang pasti dan terbatas akan membantu Anda untuk tidak menciptakan hubungan duplikat yang tidak perlu.
8.
Dekorator, adapter, picks ... Pola-pola ini adalah salah satu yang utama untuk mengintegrasikan kode baru ke dalam warisan lama.
9.
Rencana B, atau rencana rollback untuk integrasi. Banyak yang membuat kesalahan dengan melupakannya. Sangat penting dalam situasi "ketika terjadi kesalahan" ketika menuangkan materi baru. Yaitu, segera setelah kita mulai membangun arsitektur, sudah pada tahap ini kita harus memahami bagaimana kita akan mengembalikannya jika ada bug.
10.
Kode baru tanpa tes (dok) menjadi warisan dalam seminggu. Tidak peduli betapa cantiknya kode Anda, tanpa dokumentasi dalam satu minggu kode itu akan berada dalam status "warisan" - karena tidak dapat dipahami.
11.
Pengujian. Jika tes unit terlalu mahal, maka kami menggunakan tes asap, fungsional, dan integrasi. Seberapa realistis untuk menjual unit test ke bisnis dengan saus "untuk membuat pekerjaan menjadi indah?" Dalam realitas kita, ini lebih jarang daripada sebuah pola. Jika karena alasan tertentu itu tidak berhasil dengan "unit", maka kami beralih ke smok, tes fungsional atau integrasi, dan juga jangan lupa bahwa kami dapat mendelegasikan tugas, misalnya, ke penguji manual.
Alih-alih sebuah epilog
Hal yang paling penting dalam cerita ini adalah melakukan pekerjaan dan tidak meninggalkan warisan 6 tahap bermasalah (tercantum dalam urutan dari yang sederhana hingga yang lebih kompleks):
- Tidak ada dokumentasi teknis
- Tidak ada dokumentasi bisnis
- Tidak ada yang mengembangkan ini
- Kami tidak tahu apa yang harus diterima pengguna.
- 200+ penggunaan setiap fungsi dan mereka disebut getA ()
- Tidak ada orang yang mau / bisa mengembangkan ini.