Mengambil Alih Sistem Lama: Stabilkan, Lalu Benahi

Sistem lama yang sering bermasalah perlu distabilkan sebelum diputuskan untuk ditulis ulang. Legacy system berarti sistem yang masih dipakai tetapi sulit diubah atau dirawat. Pastikan tim bisa menjalankannya, menguji pemulihan pencadangan, dan memahami alur bisnis utama. Setelah itu, bandingkan perbaikan bertahap dengan penggantian berdasarkan risiko dan biaya.

Dalam situasi ini, kebutuhan terdekat klien biasanya memulihkan operasi. Pembahasan utang teknis perlu dikaitkan dengan langkah yang membuat sistem kembali bekerja.

Pengambilalihan untuk memulihkan sistem memerlukan pendekatan khusus. Tim menghadapi program yang sudah dipakai bisnis, dengan perilaku dan ketergantungan yang belum sepenuhnya diketahui.

Menata ulang kode, memperbarui teknologi, atau membangun ulang dapat terlihat menarik. Tunda keputusan itu sampai tim memahami fungsi sistem. Tanpa pemahaman tersebut, perubahan yang tampak rapi justru dapat merusak alur yang masih dibutuhkan pengguna.

Langkah nol: jalankan dulu, nilai belakangan

Sebelum menyentuh satu berkas pun dengan niat mengubahnya, sistemnya harus jalan dulu di mesin yang saya kuasai penuh. "Di production aman kok" bukan bukti — itu cerita. Salin repositorinya, pasang dependensi di versi yang benar-benar dipakai, gunakan data uji yang mewakili kebutuhan dan sudah diizinkan, di lingkungan terpisah, lalu lihat sendiri apakah dia mau boot.

Menjalankan sistem di lingkungan terpisah menghasilkan inventaris awal: variabel konfigurasi, pekerjaan terjadwal, dan kunci API yang mungkin tertanam dalam kode. Peninjauan kode menemukan sebagian masalah; pengujian menunjukkan perilaku sebenarnya serta komponen yang gagal.

Lompati langkah ini, dan semua keputusan setelahnya jadi tebak-tebakan. Yang tidak bisa dijalankan, tidak bisa diubah dengan aman.

Pencadangan dan pemantauan, sebelum fitur

Begitu sistem jalan di lokal, langkah berikutnya bukan fitur. Langkah berikutnya memastikan produksi sanggup selamat dari kesalahan berikutnya — kesalahan saya, atau siapa pun. Sistem yang bertahun-tahun jalan tanpa pengawas dan tanpa pemilik yang jelas biasanya begini: backup-nya jalan atau tidak, tidak ada yang tahu. Bisa dipulihkan atau tidak, apalagi.

Dua hal ini masuk paling depan, sebelum perubahan fungsional apa pun:

• Backup yang terbukti bisa dipulihkan. Bukan cron job pg_dump ke folder yang tidak pernah dicek siapa pun, tetapi pemulihan yang benar-benar dicoba. Berkas dump perlu diuji pemulihannya sebelum diandalkan untuk pemulihan.
• Monitoring dan alerting. Uptime, tingkat kesalahan, sisa disk, panjang antrean — apa pun mode gagal nyata sistem itu. Sistem tumbang jam 2 pagi? Harus ada yang tahu sebelum klien menelepon sambil marah.

Perlindungan tersebut mengurangi dampak kesalahan selama pengambilalihan. Keterlambatan fitur masih dapat dijadwalkan ulang, sedangkan kehilangan data dapat mengganggu operasi serta merusak kepercayaan klien.

Pengujian karakterisasi untuk merekam perilaku saat ini

Sistem sudah jalan dan sudah terlindungi. Pertanyaan berikutnya: bagaimana mengubahnya tanpa merusak? Pengembangan berbasis pengujian biasa berangkat dari perilaku yang sudah diketahui benar. Di sistem warisan tanpa dokumentasi dan tanpa penulis aslinya, perilaku "yang benar" itu sering tidak ada yang tahu. Yang ada hanya perilaku sekarang — lengkap dengan segala keanehannya — dan pengguna sudah bertahun-tahun bergantung justru pada keanehan itu.

Michael Feathers menamai jawabannya pengujian karakterisasi: pengujian yang mendokumentasikan perilaku saat ini, bukan mencocokkan ke spesifikasi. Katanya: "instead of trying to figure out whether code is correct or not, we can try to characterize its behavior to understand what it actually does." Perilaku produksi menjadi acuan penting, tetapi dapat mencakup kesalahan yang perlu diputuskan terpisah untuk diperbaiki.

Pilih dua atau tiga alur bisnis paling penting, seperti pembayaran, pembuatan tagihan, dan rekonsiliasi malam. Tulis pengujian yang merekam hasilnya saat ini. Bagi Feathers, kode lama yang berisiko adalah kode tanpa pengujian. Pengujian karakterisasi memberi dasar untuk menilai dampak perubahan pada kode tersebut.

Penggantian bertahap dengan pola strangler fig

Setelah pencadangan, pemantauan, dan pengujian karakterisasi berjalan, mulai penggantian bertahap. Pada pola strangler fig application dari Martin Fowler, fungsi baru dibangun berdampingan dengan sistem lama. Lapisan perantara mengarahkan permintaan ke keduanya. Jalur baru mengambil porsi lebih besar setelah terbukti bekerja, lalu bagian lama dihentikan.

Argumen Fowler untuk pola ini dibanding pembangunan ulang ada di risikonya: "the reduced risk and earlier value from the gradual approach outweigh its costs." Padahal lapisan perantaranya sendiri hanya lapisan sementara yang ujung-ujungnya dibuang. Di atas kertas, total jam rekayasanya memang lebih banyak daripada pembangunan ulang bersih. Tetap sepadan — karena sepanjang pembangunan ulang, sistemnya tetap jalan dan bisnisnya tetap jualan.

Mulai dari subsistem yang paling sering menimbulkan insiden, lalu ganti bertahap setelah perilakunya dipahami. Yang sudah jalan baik, jangan diganggu.

Risiko dan biaya pembangunan ulang dari awal

Cepat atau lambat, setiap pengambilalihan untuk pemulihan memunculkan klien yang bertanya: kenapa tidak mulai dari nol saja, sekalian gunakan arsitektur yang bersih? Jawaban jujurnya: pembangunan ulang total hampir selalu jadi opsi termahal di atas meja, dan makin tua sistemnya, makin besar risikonya.

Studi kasus klasiknya cerita Joel Spolsky soal Netscape yang membangun ulang Navigator dari nol. Ia menyebut keputusan itu "the single worst strategic mistake that any software company can make." Pembangunan ulangnya memerlukan waktu sekitar tiga tahun — dan selama itu kompetitor menggerogoti pangsa pasar browser mereka.

Inti argumennya yang paling kena di sini: "when you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work." Kode legacy yang buruk sering kali buruk justru karena ia menyimpan tambalan atas insiden nyata yang sudah tidak diingat siapa pun. Pembangunan ulang membuang tambalan itu sekaligus ingatannya — dan menghadiahkan ke kompetitor, meminjam kata Spolsky, "a gift of two or three years."

Kapan pembangunan ulang menyeluruh layak dipilih?

Pembangunan ulang menyeluruh dapat tepat jika platform tidak lagi dapat dirawat dengan aman, misalnya lingkungan eksekusi tidak menerima perbaikan keamanan dan tidak ada jalur peningkatan yang memadai. Pilihan ini juga dapat masuk akal untuk sistem kecil yang perilakunya sudah dipahami. Nilai risiko serta biayanya sebelum menyamakan semua sistem lama dengan kasus tersebut.

Tampilan kode yang kurang rapi atau ketidaksukaan tim terhadap teknologi lama belum cukup untuk membenarkan pembangunan ulang. Bandingkan alasan tersebut dengan risiko kehilangan perilaku bisnis yang belum terdokumentasi.

Menjelaskan urutan stabilisasi dan pembangunan ulang

Jelaskan kepada klien bahwa stabilisasi mendukung tujuan pembangunan ulang. Setelah operasi terlindungi dan perilaku utama diuji, fungsi dapat diganti bertahap. Urutan ini membatasi risiko tanpa harus membekukan seluruh pengembangan fitur selama bertahun-tahun.

Soal pengembang lama yang pergi, bicarakan apa adanya. Satu orang memegang seluruh pengetahuan yang tidak tertulis — itu sudah titik kegagalan tunggal jauh sebelum ada yang datang menolong. Pembangunan ulang oleh tim baru tanpa jaring pengujian karakterisasi hanya melahirkan kerapuhan yang sama dengan nama baru.

Pencadangan, pemantauan, dan pengujian karakterisasi memberi dasar untuk bergerak lebih cepat dengan risiko terkendali. Tim akhirnya dapat memeriksa apakah setiap perubahan memperbaiki sistem atau menimbulkan masalah baru.