Maaf, ini akan lama, tetapi ini didasarkan pada pengalaman pribadi sebagai arsitek dan pengembang pada beberapa proyek penulisan ulang.
Kondisi berikut ini akan membuat Anda mempertimbangkan beberapa jenis penulisan ulang. Saya akan berbicara tentang bagaimana memutuskan mana yang harus dilakukan setelah itu.
- Waktu pengembangan pengembang sangat tinggi. Jika diperlukan lebih lama dari di bawah (berdasarkan tingkat pengalaman) untuk meningkatkan pengembang baru, maka sistem perlu dirancang ulang. Dengan peningkatan waktu, maksud saya jumlah waktu sebelum pengembang baru siap untuk melakukan komit pertama mereka (pada fitur kecil)
- Baru lulus kuliah - 1,5 bulan
- Masih hijau, tetapi telah mengerjakan proyek lain sebelum - 1 bulan
- Tingkat menengah - 2 minggu
- Berpengalaman - 1 minggu
- Tingkat senior - 1 hari
- Penyebaran tidak dapat diotomatisasi, karena kompleksitas arsitektur yang ada
- Bahkan perbaikan bug sederhana memakan waktu terlalu lama karena kompleksitas kode yang ada
- Fitur-fitur baru memakan waktu terlalu lama, dan biaya terlalu banyak karena saling ketergantungan basis kode (fitur-fitur baru tidak dapat diisolasi, dan karena itu memengaruhi fitur-fitur yang ada)
- Siklus pengujian formal memakan waktu terlalu lama karena saling ketergantungan basis kode yang ada.
- Terlalu banyak kasus penggunaan dieksekusi pada layar terlalu sedikit. Ini menyebabkan masalah pelatihan untuk pengguna dan pengembang.
- Teknologi yang dibutuhkan oleh sistem saat ini
- Pengembang berkualitas dengan pengalaman dalam teknologi terlalu sulit ditemukan
- Itu sudah usang (Tidak dapat ditingkatkan untuk mendukung platform / fitur yang lebih baru)
- Hanya ada teknologi tingkat tinggi yang jauh lebih ekspresif yang tersedia
- Biaya pemeliharaan infrastruktur teknologi lama terlalu tinggi
Hal-hal ini cukup jelas. Kapan memutuskan penulisan ulang yang lengkap versus pembangunan kembali secara bertahap lebih subyektif, dan karenanya lebih bermuatan politis. Apa yang dapat saya katakan dengan keyakinan adalah bahwa secara kategoris menyatakan bahwa tidak pernah ada ide yang baik adalah salah.
Jika suatu sistem dapat dirancang ulang secara bertahap, dan Anda mendapat dukungan penuh dari sponsor proyek untuk hal semacam itu, maka Anda harus melakukannya. Inilah masalahnya. Banyak sistem tidak dapat dirancang ulang secara bertahap. Berikut adalah beberapa alasan yang saya temui yang mencegah ini (baik teknis dan politik).
- Teknis
- Kopling komponen sangat tinggi sehingga perubahan pada satu komponen tidak dapat diisolasi dari komponen lain. Desain ulang komponen tunggal menghasilkan riam perubahan tidak hanya untuk komponen yang berdekatan, tetapi secara tidak langsung ke semua komponen.
- Tumpukan teknologi sangat rumit sehingga desain keadaan di masa depan mengharuskan beberapa perubahan infrastruktur. Ini akan diperlukan dalam penulisan ulang yang lengkap juga, tetapi jika itu diperlukan dalam desain ulang tambahan, maka Anda kehilangan keuntungan itu.
- Mendesain ulang suatu komponen menghasilkan penulisan ulang lengkap dari komponen itu, karena desain yang ada sangat fubar sehingga tidak ada yang layak disimpan. Sekali lagi, Anda kehilangan keuntungan jika ini masalahnya.
- Politik
- Sponsor tidak dapat dibuat untuk memahami bahwa desain ulang tambahan memerlukan komitmen jangka panjang untuk proyek tersebut. Tidak dapat dihindari, sebagian besar organisasi kehilangan keinginan untuk terus menguras anggaran yang dirancang ulang secara bertahap. Hilangnya nafsu makan ini tidak bisa dihindari untuk penulisan ulang juga, tetapi sponsor akan lebih cenderung untuk melanjutkan, karena mereka tidak ingin dibagi antara sistem baru yang sebagian lengkap dan sistem lama yang sebagian sudah usang.
- Pengguna sistem terlalu terikat dengan "layar saat ini." Jika demikian, Anda tidak akan memiliki lisensi untuk meningkatkan bagian vital dari sistem (front-end). Desain ulang memungkinkan Anda menghindari masalah ini, karena mereka mulai dengan sesuatu yang baru. Mereka masih bersikeras untuk mendapatkan "layar yang sama," tetapi Anda memiliki sedikit amunisi untuk mendorong kembali.
Perlu diingat bahwa biaya total untuk menata ulang secara bertahap selalu lebih tinggi daripada melakukan penulisan ulang yang lengkap, tetapi dampaknya bagi organisasi biasanya lebih kecil. Menurut pendapat saya, jika Anda dapat membenarkan penulisan ulang, dan Anda memiliki pengembang superstar, maka lakukanlah.
Hanya lakukan itu jika Anda dapat yakin bahwa ada kemauan politik untuk menyelesaikannya sampai selesai. Ini berarti keterlibatan eksekutif dan pengguna akhir. Tanpanya, Anda akan gagal. Saya berasumsi bahwa inilah sebabnya Joel mengatakan itu ide yang buruk. Tuntutan eksekutif dan pengguna akhir terlihat seperti unicorn berkepala dua bagi banyak arsitek. Anda harus menjualnya secara agresif, dan berkampanye untuk kelanjutannya terus menerus sampai selesai. Itu sulit, dan Anda berbicara tentang mempertaruhkan reputasi Anda pada sesuatu yang beberapa orang tidak ingin melihat sukses.
Beberapa strategi untuk sukses:
- Namun, jika Anda melakukannya, jangan mencoba mengubah kode yang ada. Rancang sistem dari awal. Kalau tidak, Anda akan membuang-buang waktu. Saya belum pernah melihat atau mendengar tentang proyek "konversi" yang tidak berakhir dengan menyedihkan.
- Migrasikan pengguna ke sistem satu tim satu demi satu. Identifikasi tim-tim yang paling sakit dengan sistem yang ada, dan migrasi mereka terlebih dahulu. Biarkan mereka menyebarkan kabar baik dari mulut ke mulut. Dengan cara ini sistem baru Anda akan dijual dari dalam.
- Desain kerangka kerja Anda sesuai kebutuhan. Jangan mulai dengan kerangka kerja I-menghabiskan-6-bulan-ini yang belum pernah melihat kode nyata.
- Jaga tumpukan teknologi Anda sekecil mungkin. Jangan over-desain. Anda dapat menambahkan teknologi sesuai kebutuhan, tetapi mengeluarkannya sulit. Selain itu, semakin banyak layer yang Anda miliki, semakin banyak pekerjaan bagi pengembang untuk melakukan sesuatu. Jangan menyulitkan sejak awal.
- Libatkan pengguna secara langsung dalam proses desain, tetapi jangan biarkan mereka menentukan cara melakukannya. Dapatkan kepercayaan mereka dengan menunjukkan kepada mereka bahwa Anda dapat memberi mereka apa yang mereka inginkan dengan lebih baik jika Anda mengikuti prinsip-prinsip desain yang baik.