Secara agregat: bagaimana kita mempertahankan sistem warisan? [Tutup]

NEW YORK - Dengan ledakan yang membuat gedung pencakar langit bergetar, sebuah pipa uap berusia 83 tahun mengirim pesan kuat bahwa bermil-mil tabung, kabel, dan besi di bawah New York dan kota-kota AS lainnya semakin tua dan bisa menjadi sangat tidak stabil.

Juli 2007 Cerita Tentang Pipa Uap Burst di Manhattan

Kami telah mendengar tentang pembusukan perangkat lunak dan utang teknis .

Dan kami telah mendengar dari orang-orang seperti:

• "Paman Bob" Martin - Yang memperingatkan kita tentang " konsekuensi dari membuat berantakan ".
• Michael C. Feathers - Siapa yang memberi kami panduan untuk 'Bekerja Secara Efektif dengan Kode Warisan' .

Jadi tentu saja komunitas rekayasa perangkat lunak mengetahui masalah ini.

Tapi saya merasa masyarakat agregat kita tidak menghargai bagaimana masalah ini dapat mengganggu sistem dan aplikasi kerja.

Seperti yang dicatat Steve McConnell :

... Tidak seperti utang keuangan, utang teknis jauh lebih tidak terlihat, sehingga orang lebih mudah mengabaikannya.

Jika ini benar, dan saya percaya itu benar, maka saya khawatir bahwa pemerintah dan bisnis akan menunda pemeliharaan dan perlindungan reguler terhadap peretas sampai semuanya terlambat. [Sama seperti NYC dan pipa uap.]

Pertanyaan saya:

• Apakah ada cara agar kita dapat menghindari perangkat lunak yang setara dengan NYC dan pipa uap?

Masalah utama yang berkaitan dengan pemeliharaan sistem warisan adalah kurangnya orang yang a) mempercepat sistem tersebut dan b) bersedia untuk terus mempertahankannya.

Saya baru-baru ini mengajukan pertanyaan serupa tentang apakah programmer muda tertarik pada mainframe sama sekali. Konsensus condong ke arah no.

Mempertahankan sistem warisan dipandang sebagai karier bunuh diri. Di banyak perusahaan di mana aturan inersia, ada sedikit investasi dalam staf pelatihan untuk tetap di atas sistem itu, yang mengarah ke satu titik kegagalan di sisi personalia. Banyak orang yang saya kenal yang bekerja pada sistem yang sama mencari rute keluar karena mereka tidak melihat masa depan jangka panjang dalam sistem dan mereka hanya melihat kerugian karir.

Di beberapa industri, peraturan pemeliharaan data mungkin merupakan faktor kunci yang memastikan bahwa sistem warisan diawasi secara wajar. Ini khususnya masalah dalam industri keuangan yang saya pikir. Peraturan itu - sejauh yang saya ketahui - umumnya terbatas waktu.

Namun, saya pikir dalam praktiknya, yang akan terjadi adalah:

Akan ada titik pada grafik di mana biaya untuk beralih ke sistem yang lebih modern yang memungkinkan Anda untuk rute di sekitar kerugian dari sistem warisan akan jatuh ke bawah biaya pemeliharaan sistem warisan karena lebih murah.

IBM menjual banyak mainframe saat ini, dan mereka bekerja sangat keras untuk memastikan bahwa mesin besar mereka tidak menutup sejumlah profesional muda. Tapi saya pikir itu tidak cukup pada tahap ini. Mereka memiliki beberapa USP dalam hal jejak karbon dan kekuatan pemrosesan aktual.

Namun, untuk setiap orang yang akan membeli mainframe IBM karena Anda dapat menjalankan Linux di atasnya, biayanya lebih murah, dan sangat efisien, Anda akan memiliki beberapa lagi yang akan memilih server farm karena mereka lebih akrab dengan dunia itu. dan begitu banyak lagi programmer.

Pada akhirnya banyak tergantung pada industri yang terlibat. Saya bekerja di industri tertentu yang telah sangat bergantung pada mainframe selama bertahun-tahun dan mereka masih banyak digunakan. Tetapi solusi yang di-host menjadi lebih populer yang memungkinkan untuk konsolidasi keterampilan di perusahaan besar - ini menghilangkan beberapa masalah yang dihadapi oleh masing-masing perusahaan dalam hal titik kegagalan - dan selain itu, beberapa pemasok sangat melihat solusi berbasis non-mainframe untuk masalah yang melekat dalam industri itu.

Jadi saya kira secara ringkas apa yang saya katakan adalah bahwa pada umumnya, akan ada gerakan menuju migrasi dari sistem warisan segera setelah titik ekonomi pemeliharaan versus migrasi jatuh pada migrasi. Akan tetapi, sebagian besar tidak akan terlihat oleh banyak orang karena itu bukan hal baru dan funky dan tidak memiliki wajah yang sangat publik seperti halnya hal besar berikutnya. Migrasi itu mungkin ke penyedia layanan atau ke teknologi yang lebih baru (terutama di mana penyedia layanan yang terkena dampak langsung).

Pengalaman saya - khususnya di jaringan - adalah bahwa ada langkah untuk menghilangkan ketergantungan pada sistem legacy.

Sebagian besar bisnis sudah tidak tahu tentang utang teknis, dan bahkan tidak menyadari hal-hal buruk sampai benar-benar runtuh di sekitar mereka dan mengirim mereka ke kebangkrutan (jika sampai pada titik itu). Saya benar - benar melihatitu terjadi, dan itu tidak cantik; yang memperburuknya adalah kenyataan bahwa saya berulang kali mencoba membuat pemilik bisnis sadar akan meningkatnya utang teknis dan bahwa itu harus diperbaiki, dan setiap kali ditolak karena keengganan untuk menghabiskan waktu dan sumber daya yang diperlukan untuk memperbaiki Itu. Hasil akhirnya adalah setelah 10+ tahun sistem akhirnya gagal serempak (setelah saya pergi) dan mereka tidak dapat pulih, dan keluar dari bisnis, karena mereka terlalu bodoh untuk menyadari selama sepuluh tahun itu bahwa menghabiskan sedikit uang untuk memperbaiki masalah akan lebih baik daripada mengabaikannya sama sekali. Saya bisa berteriak-teriak selama berjam-jam tentang kebodohan yang absurd dari perusahaan itu, dan yang paling menyakitkan saya adalah hal itu bisa dihindari sepenuhnya jika pemiliknya tidak. hanya keluar untuk menghasilkan uang dengan memotong semuanya sepenuhnya.

Ini gila-gilaan sulit mencoba untuk memberitahu bisnis jika sistem mereka ditulis parah dan membutuhkan beberapa refactoring berat (jika tidak menulis ulang keseluruhan yang biasanya terjadi karena adalah yang buruk). Sebagian besar waktu mereka hanya akan menjatuhkan Anda bahkan jika Anda memperingatkan mereka bahwa sulit untuk membuat perubahan, atau menambahkan fitur baru (cara yang benar, maksud saya, tidak hanya menumpuk lebih banyak omong kosong ke tumpukan), atau bahkan menganggap Anda sebagai merugikan bisnis karena Anda melihat masalah dengan sistem dalam kondisi saat ini.

Jujur saya sampai pada kesimpulan itu adalah pertempuran yang kalah, dan yang tidak layak untuk diperjuangkan. Orang-orang yang cukup pintar untuk tahu tentang utang teknis tidak perlu diberitahu dua kali tentang hal itu dan menyadari bahaya sejak awal, dan semua orang tidak akan mendengarkan alasan atau peringatan apa pun sampai semuanya terlambat. Pilihan terbaik (dan tentu saja, paling tidak realistis) adalah membiarkan seleksi alam masuk dan membiarkan orang-orang bodoh punah, hanya menyisakan yang cerdas. Saya tidak tahu cara penanganan lain yang lebih sederhana, karena semua yang saya coba secara pribadi di masa lalu telah diabaikan sepenuhnya, mengurangi nilai saya di mata perusahaan (untuk "mengeluh") atau bahkan mengakibatkan penghentian saya karena saya "terlalu fokus" untuk memperbaiki "apa yang tidak rusak dan tidak ada orang lain yang memiliki kondisi pikiran yang tepat untuk melihat itu rusak.

Bermil-mil tabung, kabel dan besi di bawah New York dan kota-kota AS lainnya semakin tua dan bisa menjadi tidak stabil.

Untuk anekdot, argumen yang sama dibuat di Paris pada abad ke 16-17. Begitu banyak lubang dan terowongan telah digali di bawahnya (selain lubang alami karena geologi daerah itu) sehingga bangunan sesekali akan runtuh.

Pada saat seluruh blok kota runtuh ke tanah, arahan telah diberikan untuk mengisi lubang dan terowongan yang tidak dibutuhkan dengan kerikil dan tulang (mereka juga memiliki masalah kuburan yang terlalu padat). Kota bertahan seperti itu sampai beton ditemukan.

Maksud saya di sini adalah bahwa banyak organisasi cenderung menunggu menit terakhir untuk melakukan pemeliharaan perangkat lunak, tetapi coders (seperti insinyur sipil) banyak menyelesaikan pekerjaan, cepat dan baik.

Kami selamat dari bug Y2k. Bug Y2036 akan memaksa banyak organisasi untuk memutakhirkan perangkat keras dan lunaknya. Dunia bisa berakhir pada 2012. Tetapi ilmuwan komputer bukanlah sosiolog atau kritik sastra .

Oh, dan seperti kata pepatah sementara itu: tulis kode seolah-olah pemelihara berikutnya adalah seorang psikopat ganas yang tahu di mana Anda tinggal.

Saya lupa, apa yang kita anggap kode warisan hari ini? Kode tahun lalu, kode dekade terakhir atau kode abad lalu?

Uang mendorong pembicaraan seputar pemeliharaan sistem warisan. Utang teknis berbentuk sebagai peningkatan biaya untuk mengubah sistem.

Saya telah bekerja dengan sistem yang dirancang dengan buruk dan dirancang dengan cerdas. Yang menarik adalah bahwa biaya untuk mempertahankannya tidak banyak berbeda. Masalah terbesar adalah arsitektur yang salah untuk penggunaan saat ini, yang biasanya muncul dalam masalah penskalaan atau ketika perubahan besar diinginkan. Anda tidak mudah mengkonversi area kode utama dari satu utas ke utas multi-utas.

Masalah paling signifikan yang saya alami adalah bahasa pengembangan yang digunakan. Sistem yang lebih lama ditulis dalam bahasa yang kurang populer saat ini sehingga Anda harus melatih lebih banyak atau menyewa lebih banyak sumber daya yang berpengalaman (mahal) dan langka. Dalam kedua kasus itu, karena kelompok yang lebih kecil, Anda juga kesulitan menemukan individu-individu yang terampil yang cenderung memimpin banyak masalah sebagai solusi.

Adapun penulisan ulang yang dijanjikan, sebagian besar sistem yang memiliki investasi besar tidak membenarkan penulisan ulang. Sungguh menakjubkan betapa lama perangkat lunak dapat tetap bekerja dan ditingkatkan. Perubahan perangkat keras (beberapa sistem yang didukung perusahaan saya menggunakan perangkat keras khusus) cenderung menjadi masalah terbesar kami. Kemampuan untuk meningkatkan seringkali hanya dibatasi oleh mekanisme untuk mengintegrasikan kode lama dengan fitur baru.

Ini sudah merupakan masalah besar. Dan itu tidak menunjukkan tanda-tanda perubahan.

Pada tahun 60an dan 70an lembaga besar dari semua jenis mulai dari melakukan akuntansi di atas kertas ke melakukan akuntansi pada sistem komputasi. Sangat banyak mereka memilih COBOL. Sebagian besar masih menggunakan versi terbaru dari sistem COBOL tersebut. Lihat http://cis.hfcc.edu/faq/cobol untuk beberapa statistik tentang ini

Seringkali kita mendapatkan pengingat acak tentang hal ini, seperti ketika Arnold Schwarzenegger menemukan beberapa tahun yang lalu bahwa dia tidak bisa begitu saja memotong gaji 200.000 pekerja negara tanpa 6 bulan pengembangan terlebih dahulu (lihat http: //www.infoworld. com / d / developer-world / californias-cobol-conundrum-067 untuk verifikasi).

Mengingat risiko beralih, sangat sulit untuk membenarkan perubahan sistem ini. Pernah. Itu telah menjadi kenyataan seumur hidup saya. Tetapi saya tidak melihat alasan mengapa fakta itu berubah dalam kehidupan anak-anak saya. Atau seumur hidup anak-anak mereka.

Saya punya teman yang mempertahankan kode yang lebih lama dari mereka. Saya punya teman yang kembali ke perusahaan 30 tahun setelah dia bekerja di sana pertama kali, dan ternyata programnya masih berjalan, tidak berubah, dalam bahasa yang dia bahkan tidak ingat!

Biarkan saya selesai dengan kisah nyata tentang apa yang bisa terjadi keduanya.

Pada 1970-an, sebuah perusahaandidirikan untuk menyediakan pasar online bagi para pedagang. PDP-11 adalah harga / kinerja yang cocok untuk mereka, jadi mereka memilih itu. Mereka mendorong batas kinerja mesin, jadi mereka menulis sistem mereka dalam perakitan PDP-11 yang sangat optimal. Beberapa tahun kemudian PDP-11 berhenti dijual. Namun bisnis itu hebat, mesin-mesin itu bertahan, dan penggantian barang bekas mudah didapat. Mereka mempertahankan platform mereka. Beberapa tahun setelah itu penggantian menjadi lebih sulit didapat. Sebuah proyek besar dibuat untuk menggantikan platform perdagangan. Gagal. Mereka mencoba lagi. Dan gagal lagi. Penyebab utama kegagalan adalah bahwa tidak ada yang tahu bagaimana sistem perdagangan mereka bekerja, dan tidak ada yang bisa membaca perakitan PDP-11 lagi. Kemudian keselamatan melanda. Seseorang membuat assembler PDP-11 yang berjalan di Linux.

Demikianlah pada tahun 2000, perdagangan yang masuk ke bisnis bernilai miliaran dolar / tahun jatuh ke mesin Linux, melalui jembatan ethernet-decnet, untuk meniru mesin PDP-11 yang mengeksekusi perdagangan pada sistem perangkat lunak yang ditulis dalam PDP- yang sangat dioptimalkan. 11 perakitan. Untuk kecepatan.

Saya tidak memiliki koneksi dengan perusahaan tersebut dalam dekade terakhir. Jadi saya tidak bisa memberi tahu Anda apakah mereka masih menggunakan PDP-11 yang dicontoh. Saya tahu bahwa desimalisasi menekan margin mereka dengan menyakitkan, sehingga mereka memiliki upaya lain untuk bermigrasi. (Saya hanya mempelajari ceritanya karena saya mewawancarai beberapa orang yang diberhentikan dari sana, dan saya bertanya apa yang telah terjadi.) Namun dengan kegagalan sebelumnya, saya akan memberikan lebih baik daripada peluang bahkan bahwa mereka belum berhasil menggantikan sistem itu.

Kedengarannya seperti keprihatinan yang sangat tulus dari pandangan pengguna. Agar busuk tertunda, atau lebih baik, dihindari, perangkat lunak yang dipermasalahkan harus bebas dari belenggu. Penerbitnya harus membebaskan kode sumber, atau berada dalam bisnis memelihara dan meningkatkan sumber sampai pengguna terakhir berhenti menggunakannya. Kalau tidak, ada peluang yang sangat baik bahwa mereka dapat keluar dari bisnis karena membusuk serupa di dunia bisnis, sehingga meninggalkan perangkat lunak sepenuhnya terbuka untuk membusuk.

Dengan kata lain, jangka waktu hak cipta perangkat lunak dan pembatasan lisensi harus sangat singkat, pada akhirnya, perangkat lunak dan basis kodenya memasuki domain publik dan tetap di sana. Dengan demikian, memungkinkan pengguna untuk terus meningkatkan sumber, atau, merekrut seseorang untuk melakukannya, dengan demikian, menunda dan / atau menghindari pembusukan.

Atau, jika Anda sedikit terbuka dengan gagasan perangkat lunak bebas, Anda dapat menulis program Anda di bawah lisensi gratis seperti AGPL atau GPL atau lisensi perangkat lunak gratis lainnya. Dari apa yang saya lihat, ketika sumber perangkat lunak tidak menarik minat pengembang untuk memperbaikinya karena alasan apa pun, basis sumber akan dikanibalisasi dan menjalani kehidupan baru. Paket dalam sistem operasi Debian cenderung mengikuti siklus hidup ini, sejauh yang saya lihat.

Setelah mendukung berbagai aplikasi pemerintah dan industri swasta, saya akan mengatakan bahwa sebagian besar perusahaan dan setidaknya Pemerintah AS sangat menyadari bahaya membiarkan kode membusuk dan tidak bertahan di atas tren keamanan terbaru.

Kami secara teratur harus mendapatkan perangkat lunak kami yang disertifikasi untuk berbagai kerentanan dan sebagian besar sistem elektronik pemerintah, bahkan yang lama, mendapatkan pembaruan rutin untuk menjaga keamanannya.

Tentu saja ada pengecualian, dan peretas selalu bergerak, tetapi secara keseluruhan saya pikir orang-orang cukup sadar Anda tidak bisa begitu saja membuang sesuatu di luar sana dan tidak pernah menyentuhnya lagi.

Peringatan: Ini akan menjadi bentuk yang agak bebas ...

Saya pikir ada 2 cara untuk melihat kekhawatiran Anda.

Jika Anda memikirkannya, beberapa pesawat ulang-alik dan satelit telah menjalankan kode yang sama dengan yang awalnya diluncurkan. Di sisi lain, beberapa telah dirancang untuk diperbarui bahkan jika mereka sangat (sangat) jauh.

Yang penting adalah lingkungan. Jelas, selama Anda tidak mengubah lingkungan, kode Anda tidak akan usang. Dalam hal ini, kode membusuk tidak benar-benar ada: kode itu sendiri (atau biner yang dihasilkan) tidak dapat membusuk. Mungkin pecah jika Anda baru saja mulai menyerangnya dari sudut yang sama sekali berbeda. Bukannya busuk, tapi tidak beradaptasi dengan lingkungannya. Anggap saja sebagai masalah evolusi.

Tetapi lingkungan kita berubah. Dan entah bagaimana, apa kunci masalah Anda juga solusinya. Lingkungan kami berubah sangat cepat, sehingga saat ini kami tidak mengharapkan solusi perangkat lunak untuk tidak berkembang seiring waktu. Kami mengabaikan proyek perangkat lunak yang belum diperbarui dalam setahun terakhir, dan akan mengeluh tentang dukungan produk dan pelanggan yang tidak menghasilkan peta jalan yang jelas. Dan bahkan ketika ini berhasil dengan baik - Anda mendapatkan peta jalan yang jelas, dukungan yang baik, pembaruan rutin ... - selalu ada kesempatan sekarang bahwa penantang akan muncul, dengan pertumbuhan eksponensial. Kita sering membuat kesalahan dengan berpikir bahwa perusahaan besar yang mapan akan selalu mendominasi, justru karena mereka mendominasi. Namun, dengan cara yang sama, elemen dominan dalam kawanan bertambah tua, perangkat lunak / perangkat keras super / vendor apa pun semakin tua. Atau hanya sedikit malas. Dan seorang penantang datang dan membalikkan keadaan bahkan lebih cepat daripada yang dominan mungkin lakukan 5 atau 10 tahun sebelumnya. Atau yang dominan hanya akan melakukan pemukulan yang baik, nyaris tidak bisa bertahan hidup sementara kita melihat gangguan di pasar (secara ekonomi, dengan dampak pada bidang yang berbeda), dan kemudian segalanya akan berjalan. Mungkin itu terlihat tidak sempurna, tetapi itu sendiri merupakan proses organik.

Jadi, dari perspektif pengguna, saya kira masalahnya tidak sebesar itu. Busuk kode tidak akan terjadi dari sudut pandang pengguna, karena ia akan dapat menggunakan alternatif (mungkin dengan transisi / migrasi tanpa batas ... semoga).

Sekarang dengan asumsi kita tidak melihat hal-hal dari sudut pandang pengguna, atau bahwa kita berbicara tentang sistem yang kebal - untuk alasan yang tidak diketahui, pengembangan pemerintah, perjalanan ruang angkasa, dll ... - ke kompetisi dan benar-benar seharusnya untuk dibangun untuk hidup / bertahan untuk waktu yang sangat lama, kita perlu melihat teks yang Anda rujuk. Dan mungkin beberapa literatur tentang sistem yang dapat diandalkan dan sistem yang tahan terhadap kesalahan. Meskipun kami mungkin ingin mendorong lebih jauh. Kami tidak hanya menginginkan toleransi kesalahan, kami menginginkan sistem evolusi.

Masalah dengan evolusi, adalah bahwa ia memperkenalkan perubahan, dan perubahan memperkenalkan titik kegagalan. Mari kita lihat ini sekarang dan apa yang bisa kita lakukan untuk mengatasinya.

Kita masih bisa mengandalkan metafora infrastruktur / arsitektur / pengemasan sementara kita melakukannya (toh, kita semua adalah insinyur perangkat lunak, meskipun tidak ada yang namanya rekayasa perangkat lunak ... untuk saat ini). Ada alasan sementara sistem tabung masih aktif (dengan beberapa gangguan), sementara Big Ben masih bekerja (dengan beberapa gangguan) atau Menara Eiffel masih berdiri. Itu karena kita melakukan dengan elemen vital (atau tidak begitu vital) dari infrastruktur apa yang harus kita lakukan dengan perangkat lunak juga: inspeksi berkelanjutan. Entitas-entitas ini tidak perlu dirancang untuk bertahan selama ini, tetapi telah mendapat manfaat dari pengawasan permanen dan perbaikan dan perbaikan tepat waktu ketika diperlukan. Sebut itu perbaikan terbaru Anda jika Anda mau.

Di sisi lain, beberapa desain dimaksudkan untuk bertahan lama, dan berjalan tahan lama tanpa gangguan, bahkan mengetahui bahwa inspeksi berkelanjutan tidak akan mungkin. Dalam hal ini kita beralih ke desain yang bagus dan model formal. Elemen-elemen ketergantungan (Ketersediaan, Keandalan, Keselamatan, Integritas, Maintabilitas) dapat dikuantifikasi - untuk lingkungan tertentu. Statistik melakukan sisanya untuk merencanakan sisanya dan masa depan. Yang menimbulkan pertanyaan: apakah mungkin bagi kita untuk membangun sistem yang akan menjadi evolusi, dalam arti yang sebenarnya?

Jeff Langer dalam Clean Code mengajukan pertanyaan serupa ... tanpa referensi ke pipa uap :)

Bagaimana jika ada empat aturan sederhana yang bisa Anda ikuti yang akan membantu Anda membuat desain yang bagus saat bekerja? Bagaimana jika dengan mengikuti aturan-aturan ini Anda memperoleh wawasan tentang struktur dan desain kode Anda, membuatnya lebih mudah untuk menerapkan prinsip-prinsip seperti SRP dan DIP? Bagaimana jika keempat aturan ini memfasilitasi munculnya desain yang bagus?

Banyak di antara kita merasa bahwa empat aturan Desain Sederhana dari Kent Beck sangat membantu dalam menciptakan perangkat lunak yang dirancang dengan baik.

Menurut Kent (dalam Extreme Programming Explained), desain adalah "sederhana" jika mengikuti aturan berikut:

• Jalankan semua tes
• Tidak mengandung duplikasi
• Mengungkapkan maksud programmer
• Meminimalkan jumlah kelas dan metode

Untuk menjalankan semua tes ... kita perlu tes untuk menjalankan dan itu adalah salah satu indikator besar utang teknis. Misalnya, jika ada 10.000 uji kasus dalam sistem seperti Mercury Quality Center dan tidak ada tes yang diotomatisasi, itu adalah salah satu indikator yang jelas dari utang teknis yang telah dibangun.

Dan di situlah Feathers dan bukunya "Bekerja Efektif dengan Kode Legacy" masuk