Kapan kode "legacy"? [Tutup]

Kita semua telah melakukannya, kami telah memberi label beberapa kode (sering kali barang yang kami warisi) sebagai "warisan"? Tetapi masih digunakan dalam sistem produksi - jadi apakah ini benar-benar warisan? Dan apa yang membuatnya menjadi warisan? Haruskah kita menghindar dari pelabelan kode berfungsi sempurna yang tidak beralasan ini; di mana pelabelan adalah kenyamanan murni yang memungkinkan kita untuk mendorong hal-hal baru dan menjaga manajemen tingkat atas baik dan bahagia?

Ringkasan jawaban

Melihat melalui jawaban saya melihat empat tema umum. Inilah yang saya lihat rinciannya:

1. Kode apa pun yang telah dikirimkan: 6
2. Sistem mati: 2.5
3. Tidak ada tes unit: 2
4. Pengembang tidak ada: 1.5

Saya sendiri agak menyukai ringkasan Wikipedia :

Sistem lama adalah metode lama, teknologi, sistem komputer, atau program aplikasi yang terus digunakan, biasanya karena masih berfungsi untuk kebutuhan pengguna, meskipun teknologi yang lebih baru atau metode yang lebih efisien dalam melakukan tugas kini tersedia.

Banyak hal yang dijelaskan orang lain dalam jawaban mereka adalah alasan mengapa kode menjadi "warisan". Tetapi pertanyaan penting itu sendiri adalah ini:

Tetapi masih digunakan dalam sistem produksi - jadi apakah ini benar-benar warisan? Dan apa yang membuatnya menjadi warisan?

Fakta bahwa ia masih digunakan dalam produksi justru itulah yang membuatnya menjadi warisan . Jika kode tidak berfungsi dengan benar, atau tidak lagi digunakan dalam produksi, maka kode itu "rusak" atau "pensiun", masing-masing. Legacy berarti masih digunakan dan berfungsi dengan baik, tetapi menggabungkan desain atau teknik yang tidak lagi umum digunakan.

Setiap kode atau sistem yang Anda (a) ingin tingkatkan / perbarui, tetapi tidak bisa, atau (b) masih di tengah-tengah peningkatan, adalah sistem warisan. Ini tidak berarti refactoring atau pembersihan kode umum, itu berarti perubahan signifikan pada desain, mungkin menggunakan kerangka kerja baru atau bahkan platform baru.

Ada sejumlah alasan mengapa sistem atau kode mungkin menjadi warisan:

• Kurangnya perawatan rutin atau pembusukan perangkat lunak . Jelas jika aplikasi tidak dikelola secara teratur, itu tidak akan mengimbangi perubahan besar di dunia perangkat lunak. Ini mungkin karena kelalaian sederhana atau mungkin pilihan yang disengaja berdasarkan prioritas bisnis atau kendala anggaran.

• Kurangnya pengujian. Jawaban lain merujuk pada klaim hiperbolik penulis populer atas kode apa pun yang tidak dicakup oleh tes sebagai kode warisan. Ini benar-benar bukan definisi yang akurat tetapi adalah akar penyebab yang mungkin; tanpa tes yang baik (otomatis atau manual), pengembang menjadi takut-takut dan takut untuk membuat perubahan besar karena mereka khawatir akan merusak sesuatu, sehingga memimpin "pembusukan perangkat lunak" di atas.

• Rev-locking, sebuah faktor yang sering diabaikan yang secara khusus berbahaya dalam proyek-proyek yang menggunakan pustaka atau kerangka kerja open-source yang besar (walaupun saya juga pernah melihatnya dengan alat-alat komersial). Seringkali akan ada penyesuaian besar yang dilakukan pada kerangka / pustaka, membuat upgrade menjadi sulit atau mahal. Dengan demikian sistem menjadi warisan karena berjalan pada platform yang lebih lama (dan mungkin tidak lagi didukung).

• Kode sumber tidak lagi tersedia, artinya sistem hanya dapat ditambahkan, tidak pernah diubah. Karena sistem ini harus ditulis ulang untuk meningkatkan - sebagai lawan revisi bertahap / iteratif - banyak perusahaan tidak akan repot.

Apa pun yang memperlambat atau menghentikan pembaruan pada basis kode dapat menyebabkan basis kode itu menjadi warisan.

Sekarang pertanyaan terpisah, tetapi tidak dinyatakan tetapi tersirat adalah, apa yang salah dengan kode warisan? Ini sering digunakan sebagai istilah merendahkan, maka pertanyaannya:

Haruskah kita menghindar dari pelabelan kode berfungsi sempurna yang tidak beralasan ini?

Dan jawabannya tidak, kita seharusnya tidak; label yang dibenarkan dan istilah itu sendiri jelas menyiratkan kode fungsi. Intinya bukan yang itu fungsi, tapi bagaimana itu berfungsi.

Dalam beberapa kasus tidak ada yang salah dengan kode warisan. Itu bukan kata yang buruk. Kode / sistem lama bukanlah Jahat. Mereka baru saja mengumpulkan debu - kadang-kadang sedikit, kadang-kadang banyak.

Legacy menjadi usang ketika sistem tidak dapat lagi melayani (semua) kebutuhan klien. Itu label adalah salah satu yang kita perlu berhati-hati dari. Kalau tidak, itu hanya persamaan biaya / manfaat; jika biaya peningkatan akan lebih rendah daripada biaya manfaatnya (termasuk biaya pemeliharaan yang lebih rendah di masa depan) maka tingkatkan, jika tidak, biarkan saja. Tidak perlu memuntahkan kata "lawas" dengan nada yang sama seperti yang biasanya Anda pesan untuk "pemeriksaan pajak". Ini situasi yang sangat OK untuk dilakukan.

Biasanya itu berarti itu ditulis dalam bahasa, atau berdasarkan pada sistem yang biasanya tidak Anda lakukan pengembangan baru.

Misalnya, sebagian besar tempat tidak menulis program baru di Cobol. Namun, sebagian besar bisnis mereka dapat berjalan di aplikasi yang ditulis dalam Cobol. Karenanya, aplikasi tersebut diberi label "Legacy".

Legacy berarti kode apapun Anda akan lebih mengganti dari pekerjaan dengan. Mengingat sikap sebagian besar programmer terhadap sebagian besar kode yang ada, itu biasanya mencakup hampir semua kecuali apa yang sedang Anda tulis secara aktif saat ini (dan pada proyek besar di mana Anda harus membuat kode ke desain yang beku, bahkan apa yang Anda tulis di momen dapat dimasukkan juga).

1. Penekanan "lebih" dimaksudkan untuk menyampaikan bahwa kode lama juga berarti Anda terjebak bekerja dengannya meskipun Anda lebih suka tidak melakukannya. Saya tidak yakin penekanannya cukup. Alasan untuk itu bisa beragam. Beberapa benar-benar terlalu besar dan rumit untuk diganti. Lainnya adalah antarmuka ke sistem lain. Yang lain lagi didorong oleh politik dan kepribadian (misalnya, kode itu mengerikan, tetapi stan bayi sangat mengagumkan).
2. Poin lain yang mungkin tidak saya tekankan secara cukup adalah bahwa walaupun kualitas kode bisa menjadi faktor, jarang (jika pernah) faktor tunggal - dan seringkali bahkan bukan yang terpenting.
3. Saya pikir orang-orang yang mendorong tes unit sebagai satu - satunya faktor penentu adalah seperti orang yang mencari di bawah lampu jalan untuk anting-anting istrinya yang jatuh satu blok jauhnya. Cahaya mungkin lebih baik, tetapi Anda masih mencari di tempat yang salah. Pikirkan sebelum Anda minum Kool-Aid .
4. (A akibat dari 3.) Menurut saya beberapa orang berbicara lebih banyak tentang bagaimana mereka berharap sesuatu daripada bagaimana mereka sebenarnya. Jika John Conway ' Game of Life untuk Apel IIc Ditambah tidak warisan, itu karena itu cukup kecil dan sederhana yang mudah untuk kembali melaksanakan dari bawah ke atas. Pengujian unit paling sempurna yang pernah ditulis tidak akan mengubah itu sedikitpun .

Poin terakhir memang mengarah pada dua poin lain yang saya pikir sering benar.

Pertama, kode sering dipertahankan sebagai warisan, meskipun sebenarnya tidak seharusnya demikian. Manajer tingkat yang lebih tinggi umumnya menganggap menerapkan kembali sistem akan menelan biaya sebanyak atau lebih dari implementasi awal, yang jarang benar.

Kedua, unit test adalah pedang bermata dua. Mereka membuatnya terlalu mudah untuk berpikir bahwa perubahan-perubahan yang terlokalisasi dalam implementasi adalah yang sebenarnya penting. Untuk membuat perbaikan signifikan dalam sistem yang lebih besar, Anda sering (biasanya?) Harus mengubah cukup keseluruhan desain sehingga banyak (jika tidak sebagian besar) tes unit menjadi tidak relevan. Sayangnya, kehadiran unit test dan sikap yang mereka hasilkan dapat membuat semuanya terlalu mudah untuk mengabaikan perubahan yang benar-benar diperlukan.

Mungkin contoh yang akan membantu: mari kita asumsikan sebuah program memiliki perpustakaan UI dengan pengujian unit yang hebat, dan beberapa program yang menggunakan perpustakaan itu. Seseorang di manajemen atas menjadi yakin bahwa "web diaktifkan" adalah penting (dan, hanya untuk argumen, mari kita asumsikan bahwa dalam kasus ini dia benar tentang itu). Setelah ditinjau dengan cermat, manajer menengah menemukan bahwa pengujian unit mereka saat ini cukup sehingga mereka dapat berubah dari antarmuka pengguna yang ditampilkan melalui kemampuan windowing sistem operasi lokal untuk ditampilkan dari jarak jauh melalui HTML / CSS / AJAX, sambil mempertahankan semua validasi input asli.

Itu bagus bukan? Ini menunjukkan betapa bermanfaatnya pengujian unit. Kami telah menukar seluruh implementasi dari keseluruhan UI, tetapi memastikan bahwa tampilan, rasa, dan fungsionalitas tetap konsisten, dan semua input pengguna divalidasi untuk memastikan integritas data. Pengujian unit telah menghemat hari!

Atau tidak! Pustaka UI yang hebat, sangat fleksibel, dan telah diuji dengan cermat ini telah membantu semua orang yang buta terlibat dengan fakta bahwa untuk program ini di pasaran dengan penggunanya, UI berbasis web sepenuhnya merupakan hal yang salah untuk dikerjakan. Yang benar-benar dibutuhkan adalah layanan web dengan antarmuka yang tenang , dan sama sekali tidak ada UI sendiri.

Sekarang, memang benar bahwa pengujian unit tidak, dengan sendirinya menghilangkan kemampuan orang untuk memahami pasar mereka atau menyadari bahwa itu benar-benar diperlukan. Pada saat yang sama, kalimat lama tentang palu dan kuku hampir terlintas dalam pikiran. Ini bisa menjadi lebih buruk ketika Anda tidak hanya memiliki palu, tetapi memiliki banyak pengalaman dengan palu ini, dan tahu itu adalah palu yang benar-benar berkualitas tinggi yang bekerja sangat baik dalam banyak situasi yang berbeda. Fakta bahwa ia sangat pandai dalam banyak hal dalam begitu banyak situasi membuatnya lebih sulit untuk dikenali ketika itu sepenuhnya alat yang salah untuk pekerjaan yang sedang dihadapi.

Kode lama biasanya yatim piatu dalam beberapa cara. Pengembang utama, satu-satunya orang yang memahaminya, tertabrak bus, dan catatannya ditulis dalam dialek asli Ukraina, yang sekarang menjadi bahasa mati. Atau, secara bergantian, apa pun yang ditulis dalam Visual Basic 6.0 .

Saya bekerja pada kode warisan sepanjang waktu. Saya akan mengatakan karakteristiknya adalah:

• Itu tidak dapat diperpanjang tanpa upaya besar-besaran
• Tidak dapat dengan mudah dipindahkan ke perangkat keras baru
• Terlalu penting untuk diganti dengan bisnis

Jika tidak memiliki karakteristik tersebut, maka itu mungkin bukan warisan. Jika Anda tidak menyukai skrip Perl pendahulu Anda , saya bersimpati, tapi saya pikir itu bukan warisan. Saya baru-baru ini memodernisasi beberapa skrip Perl yang berusia 15 tahun yang dihubungkan dengan database Sybase yang sudah usang . Itu kue dibandingkan dengan membuat bahkan perubahan terkecil untuk sistem akuntansi COBOL kami yang mengerikan .

Dalam bukunya, Bekerja Efektif dengan Legacy Code , Michael Feathers mendefinisikan kode legacy sebagai kode yang tidak tercakup dalam unit test. Itu satu definisi, yang saya setujui. Saya juga melihat kode lawas sudah tua, namun masih dapat digunakan.

Secara teknis, legacy adalah kode apa saja yang siap ditulis. Jadi segera setelah diproduksi, itu adalah warisan. Karena sudah ada nilai di sana, Anda tidak bisa begitu saja membuangnya ... Anda harus menghadapinya.

Ini "sebelum waktu Anda" tetapi "masih sakit kepala Anda" .

Kode lama adalah kode yang hanya tersisa di basis kode karena banyak hal akan berhenti berfungsi sebaliknya. Dengan kata lain: itu satu-satunya alasan untuk menjadi kompatibilitas mundur.

Anda lebih suka mengubahnya atau bahkan membuangnya, tetapi Anda tidak bisa karena Anda akan memecah semua kode yang bergantung padanya (yang mungkin merupakan kode yang tidak dapat Anda adaptasi). Oleh karena itu Anda harus menyimpannya (dan kadang-kadang bahkan mempertahankannya), tetapi Anda ingin semua kode baru tidak ditulis menentangnya.

Contohnya adalah metode API API yang sudah tidak digunakan lagi. Mereka masih di sana, sehingga jika siapa pun yang memperbarui perpustakaan masih dapat membangun proyeknya, tetapi mereka ditandai sebagai usang dan Anda kompiler harus memberi Anda peringatan.

Contoh lain adalah semua trik aneh yang dilakukan Microsoft untuk membuat program berjalan yang ditulis untuk versi OS mereka, mereka telah sepenuhnya ditinggalkan. Puncak dari makhluk ini adalah:

Saya pertama kali mendengar tentang ini dari salah satu pengembang game hit SimCity, yang mengatakan kepada saya bahwa ada bug penting dalam aplikasinya: ia menggunakan memori segera setelah membebaskannya, sebuah no-no besar yang kebetulan bekerja OK di DOS tetapi tidak akan berfungsi di Windows di mana memori yang dibebaskan kemungkinan akan diambil oleh aplikasi lain yang sedang berjalan segera. Para penguji di tim Windows akan melalui berbagai aplikasi populer, mengujinya untuk memastikan mereka bekerja dengan baik, tetapi SimCity terus mogok. Mereka melaporkan ini ke pengembang Windows, yang membongkar SimCity, melangkah melalui debugger, menemukan bug, dan menambahkan kode khusus yang memeriksa apakah SimCity sedang berjalan, dan jika itu terjadi, jalankan pengalokasi memori dalam mode khusus di mana Anda masih bisa menggunakan memori setelah membebaskannya.
- Joel pada Perangkat Lunak

Warisan memerlukan warisan. Kode lama hanyalah kode yang Anda warisi dari masa lalu. Ini kode warisan bahkan jika Anda menulisnya sendiri sebelumnya!

Semua pertimbangan lain pada dasarnya berasal dari fakta bahwa Anda tidak menulisnya secara khusus untuk proyek Anda saat ini. Itu tidak selalu merupakan hal buruk per se.

Pendapat saya adalah apa yang dianggap sebagai kode warisan bergantung pada banyak hal, dan tag 'warisan' mungkin khusus untuk organisasi.

Jika perangkat keras / OS yang digunakannya sudah tua dan telah dihentikan oleh vendor - strike 1.

Jika lebih sulit untuk memperbaikinya, daripada menulis ulang, karena alasan apa pun

• pengembang asli hilang
• Program ini ditulis dengan buruk
• itu bisa dilakukan lebih baik pada platform yang lebih baru, dan masih layak untuk perusahaan

untuk melakukannya

• sumber asli tidak lagi tersedia dan / atau hilang

Strike 2.

Penggabungan beberapa organisasi menjadi satu - Strike 3 - satu sisi mungkin akan ditandai sebagai warisan.

Apakah ada alternatif yang lebih baik, lebih murah yang dijual sebagai aplikasi dan / atau layanan pihak ketiga - mogok 4.

Apakah organisasi itu seperti rumah sakit atau distrik sekolah di mana konsistensi dinilai di atas teknologi baru dalam hal operasi sehari-hari? Diperlukan waktu lebih lama untuk aplikasi untuk dianggap sebagai warisan dibandingkan dengan aplikasi yang sama dalam organisasi komersial / kompetitif.

Jika perusahaan adalah perusahaan pengembangan kecil yang terus meningkatkan / mendukung aplikasi untuk melakukan apa yang pelanggan butuhkan, apakah itu dianggap kode warisan, atau hanya kode 'lama'. Saya tahu sebuah perusahaan bernama Mc2Ok - mereka mengembangkan perangkat lunak pada apa yang tampaknya Windows 3.1, dan terus membawanya ke depan. Masih sangat banyak memiliki tampilan dan nuansa Windows 3.1, tetapi mereka menambahkan antarmuka web juga. Itu adalah perusahaan pengembang dua orang (tebakan saya), dan saya katakan ketika mereka berhenti mengerjakannya, maka itu akan dianggap sebagai warisan, dan waktu untuk bermigrasi satu atau dua tahun setelahnya jika menggunakannya. Tapi itu bisa 10 tahun atau lebih.

Kadang-kadang ketika manajemen berubah, itu dapat berubah dalam gelombang yang memiliki banyak efek menetes ... Tergantung pada pengaruh manajemen baru, itu dapat membuat banyak aplikasi warisan yang mungkin baik-baik saja.

Setiap organisasi, saya percaya, harus mendefinisikan apa arti 'kode warisan' bagi mereka. Saya biasa melihat-lihat iklan The Sunday Times setiap minggu untuk melihat apa yang dicari organisasi. Dulu itu barometer saya untuk apa yang tidak lagi relevan (yaitu, warisan). Nah, The Sunday Times tidak lagi :-) relevan Dan kita bisa menggeneralisasi bahwa COBOL adalah warisan, ASP klasik adalah warisan, dll ... Tapi saya percaya setiap organisasi harus memutuskan kapan aplikasi dianggap warisan untuk itu.

Kode adalah warisan ketika seseorang takut untuk mengubahnya, karena dia mungkin melanggarnya. Bahkan lebih menyakitkan ketika seluruh sistem mungkin tertekan oleh perubahan kode itu.

Inilah sebabnya saya juga setuju dengan definisi Michael Feathers. Kode yang memiliki unit test yang baik dapat diubah tanpa rasa takut.

Saya juga berpikir bahwa kode warisan tidak ada hubungannya dengan berapa umurnya. Seseorang dapat menulis kode warisan dari awal.