Pernahkah Anda terlibat dalam BIG Rewrite? [Tutup]

Joel Spolsky mengatakan dalam salah satu posting terkenalnya:

Kesalahan strategis tunggal terburuk yang dapat dilakukan oleh perusahaan perangkat lunak: menulis ulang kode dari awal.

Chad Fowler menulis:

Anda telah melihat video, posting weblog, dan hype, dan Anda telah memutuskan untuk mengimplementasikan kembali produk Anda di Rails (atau Java, atau .NET, atau Erlang, dll.).

Waspadalah. Ini adalah jalan yang lebih panjang, lebih keras, lebih rawan kegagalan daripada yang Anda harapkan.

Pernahkah Anda terlibat dalam BIG Rewrite?
Saya tertarik pada pengalaman Anda tentang topik tragis ini, dan khususnya, dalam penulisan ulang besar apa pun yang berhasil diselesaikan (jika ada).

Saya telah terlibat dalam beberapa penulisan ulang sepanjang karier saya dan semuanya adalah bencana. Saya pikir mereka semua gagal karena alasan yang sama

• Diperlukan upaya yang terlalu rendah: Setiap kali seseorang ingin menulis ulang, itu karena sistem yang lama menggunakan teknologi lama dan sulit untuk dipelihara. Apa yang mereka gagal pertimbangkan adalah karena usianya, mungkin diperlukan 30-40 tahun upaya pengembangan manusia ke dalamnya. Mengira Anda kemudian dapat menulis ulang semuanya dalam 6 bulan dengan tim 5 yang konyol.
• Kehilangan pengetahuan: Sistem lama telah ada begitu lama, ia melakukan banyak hal, dan terhubung ke segala sesuatu. Tidak ada dokumentasi terbaru, dan tidak ada satu titik wewenang yang benar-benar mengetahui semua hal yang dilakukan sistem. Akan ada potongan pengetahuan dengan pengguna tertentu di departemen tertentu, dan menemukan mereka semua sulit atau tidak mungkin.
• Keputusan Manajemen yang Buruk: Penulisan ulang yang saya ikuti memiliki harapan yang sama dari manajemen: Sistem baru harus 'selesai', dan sistem lama hanya bisa dimatikan pada tanggal, periode tertentu. Tidak ada pilihan lain yang bisa diterima. Saya pikir mereka memahami hal ini, karena mereka menghabiskan semua uang ini untuk merekrut orang baru untuk proyek besar ini. Pada kenyataannya, strategi mitigasi risiko yang lebih baik adalah menulis ulang fungsi utama dari sistem lama, katakanlah menangani 50-75% dari sistem lama untuk rilis pertama, dan kemudian lihat cara kerjanya! Karena # 1 dan # 2 di atas, ini mungkin akan bekerja jauh lebih baik, karena kami menemukan beberapa fitur yang terlewatkan, dan apa yang diperlukan untuk benar-benar mematikan sistem yang lama.

Penulisan ulang bisa sangat sukses jika Anda mengaturnya dengan benar. Saya tidak tahu apakah ini memenuhi ambang proyek "BIG" (TM) Anda, tetapi izinkan saya menjelaskan kepada Anda beberapa penulisan ulang yang lebih berhasil.

Proyek 1

Perusahaan tempat saya bekerja memiliki sistem pencetakan strip rak yang digunakan untuk membuat label yang Anda lihat di rak ritel dari sesuatu yang disebut planogram . Planogram dibuat dalam perangkat lunak standar industri dan alat kami membaca dokumen itu untuk membuat strip rak menggunakan templat untuk toko target. Perangkat lunak templating itu berantakan dengan mesin negara terbatas bersarang yang membentang beberapa kelas dan 3 DLL. Ketika saatnya tiba untuk menerapkan pendekatan pending paten (saat itu) untuk melakukan pasak papan, jelas kode saat ini tidak dapat mendukung apa yang ingin kita lakukan.

Solusi: Kami telah mengubah penulisan ulang menjadi hanya mesin template. Kami menggunakan desain OO yang tepat untuk memenuhi persyaratan saat ini, serta memenuhi persyaratan pasak papan baru. Waktu penulisan ulang adalah 1 bulan. Jika kami melakukan penulisan ulang seluruh skala rantai alat secara keseluruhan, itu akan memakan waktu lebih dari setahun - tetapi kami tidak perlu melakukan itu.

Proyek 2

Aplikasi web yang dibangun oleh tim kami dari bawah ke atas mulai melampaui desain aslinya. Klien kami juga memiliki serangkaian persyaratan baru yang akan membuat situs ini jauh lebih baik bagi pengguna kami, lebih sesuai dengan "Web 2.0" jika Anda mau. Sementara kami bisa memasukkan desain yang ada ke dalam kerangka kami saat ini, pemeliharaan adalah mimpi buruk. Kami tahu aplikasi itu secara intim, dan kami tahu bagian mana yang harus kami bawa dan bagian mana yang akan pergi sebagai bagian dari versi baru.

Solusi: Butuh waktu 3 bulan untuk menyelesaikan tim kami - itu tidak sepele. Produk akhir lebih cepat, lebih terukur, dan lebih menyenangkan bagi pengguna akhir. Kami melampaui harapan klien kami. Yang mengatakan, kami harus membagi tim kami sehingga perbaikan bug lebih cepat dan patch bantuan band akan dilakukan pada sistem yang ada sementara setengah lainnya bekerja pada sistem baru. Kami memiliki pengujian ekstensif di tempat, dan dimasukkan di awal proses. Alasan ini bekerja dengan sangat baik adalah karena kami sangat mengetahui aplikasi ini dan klien kami.

Proyek 3

Saya harus memasukkan kegagalan di sini. Kami mendukung klien yang membutuhkan alat manajemen informasi untuk digunakan dalam situasi bencana / krisis. Kami mewarisi aplikasi Java Swing yang dibuat oleh pengembang asli tanpa benar-benar memahami Swing. Maksud saya, mereka tidak mengikuti rekomendasi Sun untuk berurusan dengan Swing dan mengelola UI dengan benar, sebagai hasilnya Anda akan masuk ke loop acara tanpa batas dan masalah aneh dan sulit lainnya untuk dilacak. Akibatnya dipenuhi dengan bug, masalah antarmuka pengguna, dll. Ini adalah aplikasi yang sangat rumit. Untuk menjaga kewarasan kami, kami berusaha untuk menulis ulang aplikasi Swing yang ditulis dengan buruk menjadi aplikasi Swing yang ditulis dengan baik.

Solusi: Kami menyelesaikan penulisan ulang dalam waktu sekitar 4,5 bulan ketika kami memperkirakan 3 bulan. Aplikasi ini berkinerja lebih baik, baik di UI dan dalam berapa banyak data yang bisa ditangani. Kemudian tsunami pada tahun 2004 terjadi. Besarnya jumlah orang yang harus mereka lacak menunjukkan bahwa Swing adalah teknologi yang salah untuk apa yang benar-benar mereka butuhkan. Kami tidak bisa mengikuti penyempurnaan kinerja kami, dan mereka akhirnya meninggalkan alat demi aplikasi web berbatu yang dibuat oleh tim Oracle yang mereka miliki. Tentu kami dapat membenarkan apa yang kami lakukan berdasarkan pengetahuan yang kami miliki saat itu, tetapi penulisan ulang itu tidak cukup agresif, dan kami gagal memberi tahu klien kami bahwa persyaratan mereka untuk jumlah orang yang mungkin perlu dilacak terlalu rendah.

Kesimpulan

Penulisan ulang kadang - kadang diperlukan, dan dapat diselesaikan dengan sukses jika Anda merencanakannya dengan benar. Anda bisa mendapatkan lebih jauh dengan penulisan ulang yang ditargetkan untuk bagian-bagian suatu sistem daripada yang Anda bisa untuk penulisan ulang seluruh penjualan. Akhirnya, apa yang menyebabkan sebuah proyek gagal belum tentu menulis ulang itu sendiri. Meskipun kita tidak pernah bisa waskita, kita bisa membuat beberapa skenario terburuk. Saya telah belajar merancang sistem saya untuk mendukung dua kali skenario terburuk yang dapat saya pikirkan. Dalam kasus dengan sistem manajemen krisis, itu tidak cukup - angka sebenarnya adalah 20 kali skenario terburuk yang diberikan kepada kita. Tapi itu bukan skenario terburuk yang bisa kami pikirkan.

• Menulis ulang demi penulisan ulang bukanlah teman Anda. Selalu ada banyak kerumitan yang tidak Anda lihat, dan Anda akan menemukan bahwa hal-hal buruk yang Anda lihat adalah alat pelatihan untuk klien Anda. Selalu tunjukkan kemajuan Anda saat ini kepada klien Anda secara berkala sehingga mereka dapat membantu Anda menangkap pelanggaran terburuk.
• Penulisan ulang yang ditargetkan bermanfaat untuk menangani pelanggaran terburuk dalam basis kode Anda. Jangan menulis ulang keseluruhan jika Anda dapat membatasi ruang lingkup dan mengatasi sebagian besar masalah Anda.

Saya telah terlibat dengan beberapa penulisan ulang yang dari VB6 ke .NET. Dalam 2 kasus penulisan ulang berjalan dengan lancar dan kami benar-benar selesai lebih awal dari jadwal. Penulisan ulang lainnya memang membutuhkan waktu lebih lama dari yang diharapkan tetapi diselesaikan tanpa masalah besar.

Dalam kasus khusus kami, penulisan ulang BUKAN keputusan terburuk yang dapat diambil oleh perusahaan kami. Hasil akhirnya sebenarnya jauh lebih stabil daripada aslinya dan menempatkan kami di tempat yang jauh lebih baik.

Salah satu perangkap terbesar ketika melakukan penulisan ulang lengkap dari sistem yang ada adalah berpikir "Kita tidak perlu menentukan apa yang harus dilakukan sistem baru - itu sangat sederhana, hanya harus melakukan persis apa yang dilakukan sistem lama!" .

Masalahnya adalah kemungkinan besar tidak ada yang tahu persis apa yang dilakukan sistem lama, dan Anda akan menghabiskan waktu berjam-jam untuk membuat sistem baru Anda bekerja sesuai dengan cara yang dilakukan oleh pengguna yang berbeda dari sistem lama itu. Persyaratan asli dari sistem lama juga kemungkinan besar tidak tersedia.

Milik saya adalah kisah "sukses". Proyek saya melibatkan situs utama dengan 4 situs satelit yang dikelola / ditulis secara independen (subdomain dengan aplikasi berbeda pada mereka). Kami memiliki 4 basis pengguna utama (semua dalam direktori aktif yang terpisah) dan tidak ada yang memiliki sistem otentikasi umum. 3 adalah aplikasi mapan dan silo'd dan satelit ke-4 adalah merek baru dan telah menyalin banyak basis kode dari situs kami yang paling mapan.

Sasaran: Menerapkan sistem identitas perusahaan yang dapat mengotentikasi akun di 4 domain dan mengelola penuh (dengan swalayan) akun di 1 domain. Karena .Net sudah diterapkan pada satelit, situs asp klasik yang berfungsi sebagai "pemimpin" perlu ditulis ulang, manajemen identitas ditambahkan, dan semua situs akan memerlukan pengujian regresi untuk memastikan tidak ada layanan yang terpengaruh.

Sumber: 3 arsitek utama - programmer, manajemen identitas, manajer proyek. Sekitar 20 pengembang, 10 analis, 10 penguji.

Waktu sampai selesai (mulai dari selesai): 1,5 tahun

Peluncuran Sukses: Near Failure

Keberhasilan Umur Panjang: Hebat

Saya adalah arsitek manajemen identitas, jadi saya merancang basis data, subsistem, dan antarmuka logis tempat semua satelit akan berinteraksi. Arsitek "programmer" adalah pengembang utama dengan pengetahuan bisnis yang luas dari semua satelit dan pengalaman dengan aplikasi dan pengembangannya hingga saat itu.

Setelah beberapa bulan persyaratan berkumpul dengan 50 orang atau lebih yang berbeda dari berbagai departemen di perusahaan kami, kami berhasil membuat arsitektur logis terselesaikan dan mulai mengeluarkan kode. Karena sifat perubahannya, kami harus menulis ulang situs web kami sendiri dan semua fungsi yang terkandung di dalamnya. Net. Dalam beberapa kasus itu hanya masalah refactoring. Dalam banyak kasus itu melibatkan penulisan ulang lengkap dari proses di sekitarnya. Dalam 2 kasus kami hanya mengabaikan fitur asli karena tidak penting. Kami melewatkan 2 tenggat waktu dalam proses (tetapi akhirnya mencapai batas waktu asli yang saya usulkan - hampir tidak). Pada hari peluncuran tidak ada yang berhasil. Kami meluncurkan pada hari Sabtu sehingga dampaknya sangat minim, tetapi saya menghabiskan sepanjang hari menyisir log, menulis ulang, dan mengevaluasi beban server. Lebih banyak pengujian mungkin membantu.

Pada akhir hari pertama, semua situs sudah berjalan dan semuanya berjalan dengan baik (saya katakan sukses nominal). Selama 2,5 tahun terakhir semuanya telah sukses luar biasa. Memiliki semua situs kami pada arsitektur umum dengan basis kerangka kerja yang sama telah membuat pengembangan dan kerja lintas-pengembang menjadi lebih mudah. Fitur yang saya tulis di situs kami 2,5 tahun yang lalu (selama penulisan ulang kami) sejak itu telah dilihat / diadopsi oleh beberapa silo satelit.

Kami telah meningkatkan pencatatan, pelacakan pengguna, peningkatan waktu, aplikasi tunggal yang bertanggung jawab untuk otentikasi / otorisasi / identifikasi. Silo satelit dapat fokus sepenuhnya pada aplikasi mereka dan dapat mempercayai bahwa ada masalah otentikasi / otorisasi dengan aplikasi manajemen identitas.

Proyek kami banyak frustrasi, sakit hati dan bencana. Pada akhirnya itu terbayar dan kemudian beberapa. Saya 100% setuju dengan penilaian Joel Spolsky tentang penulisan ulang sebagai aturan umum, tetapi selalu ada pengecualian. Jika Anda mempertimbangkan untuk menulis ulang, Anda hanya perlu memastikan itu benar-benar yang Anda butuhkan. Jika ya, maka bersiaplah untuk semua rasa sakit yang menyertainya.

Saya terlibat dalam penulisan ulang kode besar sekarang ... satu-satunya masalah adalah saya satu-satunya yang mengerjakannya! Biaya pemeliharaan perangkat lunak kami saat ini keterlaluan, memiliki banyak bug, dan kami memiliki 1 karyawan FT yang memeliharanya sehingga kami memutuskan untuk membangunnya sendiri.

Jauh lebih lambat daripada yang saya harapkan, tetapi pada akhirnya saya pikir itu akan jauh lebih baik karena kita akan memiliki basis kode kita sendiri sehingga setiap perubahan yang mereka inginkan di masa depan dapat dengan mudah diimplementasikan (perangkat lunak perlu sering berubah untuk mengimbangi waktu saat ini). Kami juga membuat beberapa perubahan besar pada desain sementara kami menulis ulang.

Saya mengambil bagian dalam penulisan ulang lengkap di pekerjaan saya sebelumnya. Dan kami sangat senang melakukannya. Katakan saja bahwa kadang-kadang basis kode begitu busuk sehingga lebih baik untuk memulai lagi.

Itu adalah aplikasi internal - aplikasi bisnis utama, sebenarnya.

Kami mempertahankan sistem lama ketika kami menulis versi 2. Jika saya ingat dengan benar, kami butuh sekitar satu tahun (dua programmer, dan kemudian yang ketiga). Kami tidak perlu menyentuh basis data, jadi setidaknya migrasi data tidak menjadi masalah.

Semuanya tergantung. Dalam kasus saya, saya mengikuti saran Joel Spolsky dan saya salah . Itu tentang Situs Web Asuransi. Situs itu mengerikan dan inilah yang saya lakukan, lalu apa yang seharusnya saya lakukan:

Strategi buruk : Saya mengawasi sekelompok 4 siswa untuk:

• Siswa # 1 - menulis ulang akses basis data / kueri untuk membuatnya aman
• Siswa # 2 - memindahkan semua css "ke atas"
• Siswa # 3 - membuat semua halaman w3c kompatibel
• Siswa # 4 - menyelesaikan semua bug yang tertunda
• Saya sendiri: menghapus semua peringatan php dan hal-hal buruk (kode duplikat dan sebagainya)

Butuh 2 bulan. Lalu kami mendesain ulang situs tersebut. Lalu kami melakukannya dalam berbagai bahasa. Semua dalam semua, kami harus menjaga sebagian besar kode jelek dan struktur database tetap sama. Jadi saya masih mengerjakan hal-hal jelek selama satu tahun sekarang dan itu tidak akan pernah selesai sampai kita memutuskan penulisan ulang lengkap, yang tidak akan pernah terjadi sebenarnya.

Strategi yang baik :

• Pelajari seluruh situs, buat "Dokumen persyaratan produk" yang bagus.
• Desain ulang database dengan benar
• Mulai dari awal dengan kerangka kerja saya sendiri (yang sudah berfungsi)
• Mendesain ulang situs.
• Lakukan multi bahasa.

Waktu yang diperlukan: dua bulan ( mungkin kurang ).

• Kode yang baik
• Perawatan yang bagus.
• Produktifitas.
• Tidak ada jawaban seperti "kami tidak bisa melakukan ini, Situs web tidak dapat menangani produk seperti itu".

Jadi, kata-kata terakhir saya: semuanya tergantung pada kerumitan hal-hal yang harus Anda tulis ulang .

Jangan ragu untuk memperbaiki posting saya untuk menjadikannya bahasa Inggris yang baik, terima kasih banyak

Olivier Pons

Sebuah perusahaan tempat saya bekerja memulai refactor utama basis kode.

Setengah tim ditetapkan untuk mengerjakan refactor, dan separuh lainnya terus mempertahankan dan meningkatkan produk yang ada.

Seperti yang dapat Anda bayangkan, refactor tidak pernah benar-benar sampai pada titik di mana sesuatu bekerja - itu hanyalah proses yang terus menerus yang tidak benar-benar memiliki apa pun untuk ditampilkan sendiri.

Idenya adalah bahwa basis kode refactored akan lebih baik untuk bekerja dengan dan kita hanya bisa "mampir" dalam fitur-fitur baru yang ditambahkan tim ke produk yang sudah ada setelah selesai, dan "mengejar ketinggalan".

Tetapi akhirnya menjadi kejatuhan perusahaan.

Saya telah menulis ulang besar selama 3 tahun terakhir. Asli, kami memperkirakan proyek akan memakan waktu 2 tahun. Ide dasarnya adalah mengganti perangkat keras, menggunakan OS yang ada, menulis ulang logika bisnis (dari c ke CPP), membuat kartu IO baru dan menulis UI baru.

Sepanjang jalan kami membuat beberapa keputusan yang mengerikan. Kami tidak memiliki pengalaman nyata dalam CPP dan tidak ada mentor untuk mengajarkannya dengan baik. Kami mencoba membangun kerangka UI sendiri berdasarkan win32. Perangkat kerasnya murah dan BSP cacat dengan bug. Perangkat lunaknya sangat fleksibel tetapi sulit dirawat. Tahun lalu kami membuang UI yang dikembangkan di rumah dan mengembangkan UI di .net. Kami juga sepenuhnya menulis ulang mekanisme ketekunan dan protokol komunikasi data kami.

Butuh banyak upaya ekstra, tetapi sekarang proyek ini hampir selesai dan unit pertama diuji di lapangan. Proyek ini memiliki banyak risiko untuk memiliki perubahan untuk menjadi sukses. Ada beberapa hal positif tentang proyek ini, kami mulai menggunakan SVN (alih-alih VSS), kami meluangkan waktu untuk menulis unit test dan mengimplementasikan pembangunan malam. Kami juga mulai menggunakan scrum untuk mendapatkan proses yang lebih baik.

Kalau dipikir-pikir saya pikir penulisan ulang logika bisnis itu tidak perlu, kita seharusnya hanya memfaktorkan ulang bagian yang paling jelek. Dan untuk menulis UI dari awal jangan lakukan itu kecuali itu adalah bisnis inti Anda.

Sebenarnya saya memulai refactoring besar. 4MLocs mungkin harus diperkecil menjadi 800KLocs atau kurang. Proyek ini memiliki banyak fitur Copy & Paste, kesalahpahaman bahasa, banyak dan banyak komentar yang tidak berguna, keputusan yang buruk, peretasan sementara dan peretasan menjadi permanen (termasuk penyelesaian), sama sekali tidak memiliki pengetahuan tentang prinsip - prinsip dasar tentang Ilmu Komputer atau Rekayasa Perangkat Lunak. Mungkin tim pemeliharaan dari 32 programmer yang buruk akan digantikan oleh 2 yang baik setelah refactoring.

Saya menulis mesin blogging dalam 3 minggu. Saya menulis ulang dalam 8 jam.

Perencanaan ke depan adalah kunci untuk penulisan ulang yang sukses. Mengetahui sistem dalam dan luar itu juga bermanfaat.

Sedikit lebih dari satu dekade yang lalu, saya telah bekerja untuk sebuah perusahaan yang memutuskan untuk melakukan "mendesain ulang" produk inti mereka yang sudah tua. Sejak itu, menyebutkan kata "mendesain ulang" adalah pelanggaran yang dapat dihukum. Butuh waktu lebih lama dari yang diharapkan, jelas lebih mahal, dan produk baru jauh lebih mirip dengan produk lama daripada yang direncanakan sebelumnya.