㊗️ 🧑🏾 🤵🏿 Menjinakkan binatang buas: kode warisan, tes, dan Anda 🐴 📍 👰🏻

Kode lama adalah kode "lama", yang usianya bisa 2 bulan dan 10 tahun. Seringkali, pengembang menulis tentang hal itu, yang diingat perusahaan secara samar-samar. Mungkin mereka tidak ada sama sekali, dan kode warisan lahir dengan Semesta selama Big Bang. Sejak itu, persyaratan untuk itu telah berubah berkali-kali, kode diperbaiki dalam mode "itu diperlukan kemarin", dan tidak ada yang menulis dokumentasi, seperti tes. Kode Legacy membingungkan dan rapuh, tidak menunjukkan awal atau akhir. Bagaimana cara mendekatinya?

Selanjutnya gambar dari seri "Rick and Morty." Penulis Justin Royland dan Dan Harmon.

Anda perlu mendatanginya dengan tes, tetapi bersiap-siap untuk rasa sakit. Masalah akan mulai sudah dari saat Anda memutuskan untuk melakukan proyek seperti itu. Anda perlu memahami mengapa Anda ingin melakukannya, meyakinkan manajemen untuk menyetujui pengujian kode warisan, dan membantu kolega Anda. Setelah itu, muncul pertanyaan, di mana harus memulai studi, tes mana yang harus dijalankan terlebih dahulu dan bagaimana tidak merusak segalanya? Tetapi yang utama adalah bagaimana tidak jatuh dalam keputusasaan ketika Anda menyadari bahwa tidak ada akhir untuk bekerja.

Kirill Borisov 12 tahun di industri ini, selama bertahun-tahun ia telah menempuh perjalanan panjang dalam kruk, kode yang rusak dan kerangka yang membusuk dari sistem lama: dari sistem akuntansi monolitik hingga otorisasi layanan mikro. Perjalanan itu memberinya pengalaman dan cerita yang akan ia bagikan dalam bentuk nasihat yang berharga.

Saya punya mimpi - suatu hari nanti untuk mengerjakan proyek baru. Semuanya akan baik-baik saja di dalamnya dari awal dan segar seperti salju pertama: tes, arsitektur, dan makna. Tapi ini hanya mimpi, karena selama 10 tahun saya telah menjual bakat saya untuk uang dan pindah dari satu proyek warisan ke yang lain.

Selama waktu ini saya tidak punya saraf yang tersisa, tetapi saya bisa menyelamatkan Anda dengan berbagi pengalaman saya berinteraksi dengan warisan. Saya akan memberi tahu Anda cara menjinakkan binatang buas (kode warisan): bekerja dengan kode dan orang, melaksanakan pengujian, apakah perlu dilakukan dan bagaimana pengembang terkait dengan hal ini.

Apa yang tidak akan ada di sini:

Kiat untuk menulis ujian. Banyak buku, artikel, dan berbagai video membahas pertanyaan ini.
Metodologi diskusi. BDD, TDD, ATDD - semua atas kebijakan Anda.
Semua itu mungkin melanggar NDA. Orang-orang memiliki ingatan yang panjang, dan pengacara memiliki lengan yang panjang.

Apa itu kode lawas

Ada banyak definisi. Saya percaya bahwa ini adalah kode " cukup lama " dari 2 bulan hingga 10 tahun. Kode warisan itu membingungkan dan rapuh, tetapi seperti ular raksasa melahap ekornya.

Inilah yang tidak memungkinkan Anda untuk mulai mengujinya dengan tenang. Semua pengembang, dari pemula hingga yang berpengalaman, ketika mereka datang ke proyek warisan, ambil tombak tes dan bergegas untuk membunuh monster ini. Tombak pecah, dan dengan itu orang. Akibatnya, masih ada pengembang tanpa tanda-tanda kehidupan, yang telah mengerjakan proyek warisan selama beberapa dekade.

Apakah mungkin untuk mengatasi binatang buas ini? Ya, tetapi persiapan diperlukan.

Latihan

Melawan binatang buas tidak sepenting fase persiapan. Itu dimulai dengan tiga pertanyaan untuk diri sendiri.

"Mengapa aku melakukan ini?" Serius, mengapa? Lagi pula, hanya ada dua opsi.

, , , .
, .

Apakah Anda ingin bekerja untuk kenyamanan orang lain atau kemuliaan Anda sendiri? Jika untuk yang terakhir, maka dengan minat sukses pertama akan memudar, Anda akan memudar, semuanya akan memudar. Anda akan beralih ke hal lain, dan sisa-sisa usaha Anda yang membusuk akan menyumbat proyek untuk waktu yang lama.

"Apakah saya tahu apa yang saya lakukan?" Jika Anda menulis tes, Anda tahu. Jika tidak, maka sebelum Anda bergegas ke monster itu, kuasai dasar-dasarnya: tulis 3-4 tes, tutup sebagian kecil kode, isi tangan Anda dan rasakan kekuatannya.

"Apakah aku punya waktu untuk ini?" Sangat bagus untuk campur tangan dalam kode dengan impuls yang baik dan memperbaikinya, bekerja untuk masa depan. Tetapi mungkin tidak ada waktu untuk ini ketika masa kini terbakar. Jika demikian, maka proyek membutuhkan Anda, bukan citra masa depan yang cerah.

Saat Anda menjawab semua pertanyaan di afirmatif, lanjutkan ke langkah berikutnya.

Pengintaian

Periksa struktur proyek . Apakah Anda memiliki gagasan tentang struktur proyek, komponen dan prinsip kerja? Tentunya ya, tapi mungkin itu tidak sesuai dengan kenyataan. Penting untuk memahami apa yang harus Anda hadapi sebelum mulai bekerja. Luangkan waktu untuk menjalani proyek dan mempelajarinya secara menyeluruh.

Buat diagram ketergantungan . Tidak ada proyek yang hidup dalam ruang hampa. Basis data, layanan eksternal, perpustakaan - semua ini dapat digunakan dalam proyek.

Apa yang telah dilakukan padamu? Anda mungkin bukan yang pertama untuk melawan binatang itu. Periksa praktik "leluhur" yang membakar dan meninggalkan proyek.

Setelah pengintaian, kami beralih ke permusuhan.

Bertarunglah dengan organisasi

Babak pertama adalah pertarungan dengan organisasi Anda. Hal utama di dalamnya adalah manajer Anda, atasan langsung.

Manajer . Dia tidak seseram kelihatannya. Ini adalah orang biasa dengan kebutuhan biasa: untuk mengirimkan proyek tepat waktu dan tanpa masalah yang tidak perlu, dapatkan uang dan bonus untuknya dan hidup terus.

Pemimpin tidak menentang usaha Anda. Dia menentang Anda bergegas ke proyek dengan teriakan: "Tes! Tes! Tes! " Jika Anda melakukannya, dia akan melihat Anda sebagai orang yang menghabiskan waktunya dan memperlambat sisanya.

Tunjukkan manfaatnya. Manajer berbicara dalam bahasa baik, waktu dan uang. Memahami bahwa mereka didorong oleh keinginan untuk menutup proyek tepat waktu dan mendapatkan hasil lebih banyak untuk sumber daya yang lebih sedikit.

Tes tidak boleh diajukan seperti ini:

- Oh, itu akan keren!

Ide-ide kami harus dipromosikan sebagai berikut:

- Kuartal terakhir, kami memiliki 50 crash yang dapat diperbaiki pada tahap pengembangan produk. Anda dapat memperbaikinya menggunakan tes. Mereka akan mengonfirmasi bahwa perubahan tidak mengubah fungsionalitas, jika kami tidak mengharapkannya. Kami akan menghemat waktu yang dihabiskan untuk menyelesaikan masalah ini dan mengurangi jumlah penalti yang dibayarkan karena sistem yang rusak.

Mengatakan "optimisasi, uang, menghemat waktu", Anda berbicara dalam bahasa manajer. Ketika dia mendengar kata-kata ini, dia diilhami oleh gagasan itu. Dia melihat Anda bukan programmer fanatik berikutnya yang bersemangat tentang teknologi baru, tetapi orang yang tertarik untuk meningkatkan produk. Dia tidak akan menyetujui semua ide Anda sekaligus, tetapi ia sangat mungkin mengusulkan Konsep Bukti.

Bukti Konsep meningkatkan peluang.Memberi manajer sepotong kode terpisah yang terpisah, suatu subsistem yang dicakup oleh pengujian, mulai dan berjalan. Ini dapat dilakukan jika Anda mengambil salah satu bug sakit yang muncul pada frekuensi tertentu dan mencoba untuk menangkapnya dan memperbaikinya dengan tes. PoC akan mengkonfirmasi niat Anda, menunjukkan bahwa Anda memiliki rencana dan pekerjaan Anda membawa hasil.

Jangan banyak janji. Bagi manajer, angka-angka itu penting: apa hasil, waktu, dan kekuatan apa. Tetapi manajer adalah makhluk yang tamak akan hasil. Jangan terlalu banyak berjanji sejak awal. Jika Anda berjanji untuk menyelesaikan semua masalah sekaligus, manajer akan pergi ke pihak berwenang dengan ini. Pihak berwenang akan mengatakan: "Hebat!", Tetapi akan mengurangi dana dan memotong tenggat waktu dengan harapan bahwa kita akan menyerahkan sistem lebih awal.

Ketika kami setuju dengan manajer, kami beralih ke mereka yang harus bekerja dengan kami setiap hari.

Kolega

Mereka tidak suka perubahan. Seorang kolega pada proyek warisan biasanya adalah orang yang kehilangan kepercayaan pada kehidupan dan masa depan. Dia tidak cenderung berubah dan pasrah pada nasib: "Saya di sini selamanya, tidak ada jalan keluar dari rawa." Masalahnya adalah Anda mulai mengaduk air di rawa ini. Anda menuntut dia menulis dan menjalankan beberapa tes, tetapi dia ingin melakukan pekerjaannya, menutup tugas dan pulang.

Libatkan kolega Anda dengan manfaat - jelaskan mengapa mereka akan merasa lebih baik. Misalnya, mereka terus-menerus menghabiskan waktu dan usaha, tetap bekerja setelah selesai untuk menyembuhkan beberapa bug. Tekan itu: "Jika Anda tidak menggunakan kode yang rusak untuk produksi, Anda tidak perlu menghabiskan waktu untuk memperbaikinya. Kami akan menulis tes, kami akan menangkap kode seperti itu, itu akan lebih sedikit rusak. "

Tunjukkan kesabaran dan empati.Anda berkomunikasi dengan orang - tanyakan mengapa mereka khawatir dengan ide Anda? Sarankan mencari landasan bersama untuk saling memahami. Ini adalah taktik utama untuk bekerja dengan orang: jangan bertengkar, jangan bentrok dahi Anda, bersikap ramah.

Anda mungkin dilarang mempresentasikan ide tersebut sebelum pertemuan rekan kerja di tim selanjutnya. Mekanisme "pemikiran kelompok" bekerja dalam tim: tidak ada yang mau membuat keputusan, semua orang saling memandang dan melihat bahwa tidak ada yang bersemangat dengan antusiasme.

Ada satu trik kotor untuk menyelesaikan masalah ini. Sayangnya, dalam hidup saya, saya menggunakannya lebih dari sekali.

Membagi dan memerintah. Pergi ke salah satu kolega Anda saat makan siang atau di sudut dan katakan: "Seluruh tim telah mendaftar, Anda adalah satu-satunya yang memperlambat proses. Mungkin kita bisa menemukan bahasa yang sama? "

Setelah melalui semua pada gilirannya, Anda mendaftar semua orang. Semua orang akan malu untuk mengakui bahwa mereka pikir semua orang sudah mendaftar. Tidak terhormat dan mengerikan, tetapi berhasil. Gunakan teknik ini secara bertanggung jawab dan sebagai upaya terakhir. Ingat - Anda masih harus bekerja dengan orang-orang ini.

Ketika kami beres dengan rekan kerja, kami sedang menunggu binatang rakus lainnya.

Berkelahi dengan mobil

Ini adalah trik kode yang disebut produk. Mari kita mulai dengan dasar-dasarnya.

Bongkar sampah. Hal ini diperlukan untuk menguji sehingga dengan dampak minimal pada sistem untuk mendapatkan hasil yang dapat diverifikasi. Tetapi setiap sistem warisan penuh dengan data: mereka telah ditambahkan selama bertahun-tahun sejak diluncurkan dan mempengaruhi perilaku sistem. Oleh karena itu, perlu untuk menguji "dari awal."

Siapkan "sistem bola dalam ruang hampa": kosongkan sumber data, buat konfigurasi minimum yang diluncurkan sistem, nonaktifkan semua "peretasan" dan "fitur" yang mungkin. Buat sistem start up. Jika dimulai, Anda memiliki set data minimum yang diperlukan untuk berfungsi. Ini sudah menjadi titik awal yang baik - "sabak bersih".

Menggunakan beberapa efek terukur, misalnya, menekan tombol tertentu, Anda akan mendapatkan hasil kerja yang terukur. Dengan ini, Anda dapat melanjutkan ke langkah berikutnya.

Mengurai data. Setiap proyek warisan bekerja dengan prinsip "harus disampaikan kemarin." Segala sesuatu yang Anda tuju ke universitas atau baca di buku tidak berfungsi di sini. Ketika Anda memulai pengujian, Anda akan menjumpai, misalnya, ketergantungan siklik, tidak mungkin dibuat ulang dalam program, tetapi diperlukan untuk berfungsi.

Mulai dengan "objek utama". Untuk berurusan dengan hutan ketergantungan, cobalah untuk memikirkan objek mana yang paling utama. Misalnya, untuk sistem akuntansi gudang, objek utamanya adalah "kotak". Objek "rak" dikaitkan dengan itu, dan objek "baris" dikaitkan dengan "rak".

Buat minimum yang diperlukan.Jika Anda melihat tautan antara objek dan masuk lebih jauh ke dalam pohon dependensi, Anda dapat menentukan data minimum yang diperlukan untuk objek dependen. Anda harus membuatnya ulang agar sistem berfungsi dan dapat berfungsi untuk menguji fungsionalitas Anda.

Jangan takut untuk mengubah tautan. Anda mungkin harus menyingsingkan lengan baju Anda dan menyelam jauh ke dalam kekacauan ini: hapus dan ubah tautan, ubah struktur database. Anda datang untuk memperbaiki sistem, jadi jangan takut untuk melakukan perubahan.

Kami lolos pengujian. Untuk produk lama yang membingungkan, strategi yang bagus adalah tes asap.

Tes asap

Konsep "pengujian asap" datang kepada kami dari dunia elektronik. Seorang insinyur membuat sirkuit raksasa dengan sekelompok bola lampu dan kabel. Tetapi sebelum saya mulai menguji coba, saya hanya menghubungkan listrik ke stopkontak. Jika asap mulai, maka ada yang tidak beres.

Dalam sistem informasi, konsep tes asap cukup sederhana. Bayangkan sebuah layanan web, ia memiliki titik akhir. Mari kita coba mengirimkan permintaan GET tanpa parameter. Jika karena alasan tertentu produk tiba-tiba rusak (kesalahan 500), maka ada yang tidak beres.

Tes asap adalah awal yang baik . Ini adalah tes yang menguji beberapa fungsi dan menjelaskan bahwa sistem berfungsi atau rusak. Bahkan permintaan sederhana ke titik akhir paling sederhana sudah mempengaruhi lebih dari 1% kode. Dengan tes kecil seperti itu, kami sedang mempersiapkan batu loncatan untuk pengujian lebih lanjut.

Tes asap mengungkapkan banyak masalah. Ada kemungkinan bahwa untuk seluruh periode fungsi layanan tidak ada yang menduga untuk mengirim permintaan tanpa parameter.

Gunakan taktik ini untuk mencakup beberapa titik masuk utama ke dalam program Anda: form input masuk / kata sandi, layanan web dasar, tombol. Ini adalah sesuatu yang sudah bisa Anda tunjukkan kepada manajer dan kolega.

Tes fungsi

Ini bukan tes kelas individu atau metode, tetapi tingkat tertinggi pengujian bagian fungsional.

Bayangkan fungsionalitas untuk "menghasilkan laporan dalam layanan". Alih-alih memeriksa setiap bagian, kami menguji situasi permintaan untuk membuat laporan dengan parameter tertentu dan mendapatkan file data. Tidak perlu mengetahui mekanisme untuk menghasilkan laporan, tetapi jika layanan memberikan data output tertentu dengan data input tertentu, maka kotak hitam ini dengan beberapa kemungkinan berfungsi sebagaimana mestinya.

Cakupan fungsi utama dengan tes semacam itu memungkinkan Anda untuk memulai dengan cepat dan langsung mencakup area yang luas. Anda akan yakin bahwa kode itu bekerja setidaknya kira-kira seperti yang Anda bayangkan, mendapatkan lebih banyak kepercayaan diri, mengisi tangan Anda dan mengungkapkan lebih banyak masalah.

Tes fungsional adalah sarana, bukan tujuan.

Sangat mudah untuk terhubung dengan jarum tes fungsional: "Saya menguji fungsionalitas nyata! Inilah yang dihadapi pengguna. ”

Tes fungsional melibatkan sejumlah besar kode yang dapat berinteraksi dengan jumlah data raksasa. Oleh karena itu, 3-4 tes fungsional baik, 10 lebih buruk, dan ribuan tes yang memakan waktu 9 jam terlalu banyak. Sayangnya, ini juga terjadi.

Setelah tes fungsional, ikuti tes unit. Tapi saya tidak akan membicarakannya - Anda sudah tahu segalanya.

Kami mempelajari dasar-dasar pengujian mesin dan kembali ke topik utama. Kolega dan manajer bukanlah musuh terburuk dalam pertempuran dengan warisan. Musuh terburuk adalah dirimu sendiri.

Berkelahi dengan diri sendiri

Bersiaplah untuk kenyataan bahwa jalan akan tampak tanpa akhir . Bekerja selama seminggu dalam rencana Anda akan memakan waktu enam bulan tanpa prospek untuk menyelesaikan proyek.

Perlawanan tidak bisa dihindari . Semua sekutu akhirnya akan mulai ragu, mencoba keluar jalur, membujuk mereka untuk keluar dari tes dan beralih ke fitur. Bersiaplah untuk ini. Ingatkan semua orang mengapa Anda terlibat dalam semua ini, berapa banyak usaha dan waktu yang diinvestasikan. Argumen yang lemah, tetapi mungkin berhasil.

Tidak ada yang menjamin kesuksesan . Bahkan jika Anda menunjukkan upaya heroik, menempatkan diri Anda dalam pekerjaan, proyek Anda masih bisa terbakar, dan perang dengan pengujian tidak akan berakhir.

Ini normal, ini bukan akhir dari kehidupan dan karier. Ini bahkan bukan konfirmasi bahwa Anda adalah profesional yang buruk. Satu-satunya kesimpulan di sini adalah bahwa proyek khusus ini gagal.

Tapi kemudian Anda memiliki pengalaman dan pengetahuan. Lain kali, ketika Anda mengambil tombak baru di tangan Anda dan kuda Anda berakselerasi ke kincir angin lain, Anda juga akan siap untuk mematahkan tombak ini, tetapi kemudian, dengan metode yang berbeda dan dengan lebih sedikit kerusakan.

Sekarang ofensif, pahit, dan abadi.

Kata perpisahan

Jangan takut dengan umpan balik. Saya harus masuk ke dalam perangkap ini dan melihat bagaimana orang lain jatuh ke dalamnya. Saya melakukan sesuatu dan membawa kolega untuk menyombongkan diri: "Saya melakukannya!" Tapi tiba-tiba ternyata mekanisme nyaman saya tidak nyaman bagi rekan kerja, dan saya tidak bertanya.

Tulis tes, coba apa yang Anda laksanakan . Seringkali pengenalan kerangka kerja tes baru menarik, tetapi Anda tidak menulis tes itu sendiri. Maka dapat terjadi bahwa begitu Anda menulisnya, Anda akan memahami bahwa Anda tidak dapat menggunakan tes. Mungkin kolega juga melihat ini, tetapi diam, atau hanya tidak menulis tes.

Bantu kolega dengan masalahbahkan jika mereka tidak memintanya. Bantuan tidak berarti mengambil semua pekerjaan untuk diri Anda sendiri - itu melemaskan rekan kerja dan membebaskan mereka dari tanggung jawab, dan angka "bus" turun menjadi satu. Kemudian Anda menjadi penguji manusia: sesuatu yang rusak, CI merah, panduan ujian. Bantuan dalam kerangka yang masuk akal.

Nomor "bus" bukan lelucon. Anda tidak dapat selalu menyeret proyek itu sendiri. Semua orang bisa kelelahan, pergi berlibur atau berhenti. Karena itu, sampaikan kepada rekan kerja pengetahuan dan tanggung jawab Anda, yang diperlukan untuk mengatasinya tanpa Anda. Ini akan membantu untuk menghindari panggilan yang tidak menyenangkan ketika Anda bersantai di pantai, dan CI berwarna merah lagi.

Tingkatkan Mekanisme Pengujian. Banyak masalah dapat dihindari hanya karena tes lambat tiba-tiba menjadi cepat. Sebelumnya, mereka menempati 20 baris kode, tetapi sekarang satu. Anda tidak memperhatikan ini, karena begitu Anda menulis sesuatu dan lupa: "Berhasil - jangan menyentuhnya!" Namun aturan ini tidak selalu berlaku.

Anda bukan pusat alam semesta. Sekali lagi, saya ulangi bahwa nomor "bus" bukan lelucon. Lebih dari sekali saya menemukan situasi ketika seseorang mulai menguji, dan kemudian menerima tawaran untuk proyek yang lebih segar: dia meninggalkan segalanya, melarikan diri, tetapi tidak meninggalkan komentar dan dokumentasi. Semuanya berfungsi sampai komit baru, tetapi tidak mungkin untuk memperbaikinya - tidak ada yang mengerti bagaimana semuanya bekerja.

Saya tidak ingin Anda menjadi orang ini. Jangan berubah menjadi faktor pembatas.

Tulis dokumentasinya.
Melakukan pelatihan.
Bagikan pengalaman Anda.

Ketika semua kolega berada pada level yang sama dengan Anda (plus atau minus), prosesnya akan berubah dari perlombaan satu orang menjadi perlombaan relai tim dengan melewati bendera. Hanya dengan dukungan kolega Anda, Anda akan berhasil. Jika Anda sendirian di proyek, pikirkan bahwa orang lain setelah Anda juga akan menderita sendirian. Beri temanmu pengikut dalam bentuk dokumentasi, jangan biarkan mati sendirian.

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

Menjinakkan binatang buas: kode warisan, tes, dan Anda