it-swarm-id.com

Kapan BIG menulis ulang jawabannya?

Cukup baca pertanyaan tentang Big Rewrites dan saya ingat pertanyaan yang ingin saya jawab sendiri.

Saya punya proyek mengerikan yang diturunkan kepada saya, ditulis di Jawa kuno, menggunakan Struts 1.0, tabel dengan hubungan tidak konsisten, atau tidak ada hubungan sama sekali dan bahkan tabel tanpa kunci primer atau bidang yang dimaksudkan sebagai kunci primer tetapi tidak unik sama sekali. Entah bagaimana sebagian besar aplikasi "hanya bekerja". Sebagian besar halaman digunakan kembali (menyalin kode yang disisipkan) dan hard-coded. Setiap orang yang pernah mengerjakan proyek telah mengutuknya dalam satu bentuk atau yang lain.

Sekarang saya sudah lama mempertimbangkan untuk mengusulkan kepada manajemen tingkat atas penulisan ulang total aplikasi yang mengerikan ini. Saya perlahan-lahan mencoba menggunakan waktu pribadi, tetapi saya benar-benar merasa bahwa ini layak mendapatkan sumber daya khusus untuk mewujudkannya. Setelah membaca artikel-artikel tentang penulisan ulang besar, saya memiliki pikiran kedua. Dan itu tidak baik ketika saya ingin meyakinkan atasan saya untuk mendukung penulisan ulang saya. (Saya bekerja di perusahaan yang cukup kecil sehingga proposal memiliki kemungkinan untuk disetujui)

TL; DR Kapan penulisan ulang yang besar jawabannya dan argumen apa yang dapat Anda gunakan untuk mendukungnya?

288
Jonn

Maaf, ini akan lama, tapi ini didasarkan pada pengalaman pribadi sebagai arsitek dan pengembang pada beberapa proyek penulisan ulang.

Kondisi berikut ini akan menyebabkan Anda mempertimbangkan semacam penulisan ulang. Saya akan berbicara tentang bagaimana memutuskan mana yang harus dilakukan setelah itu.

  • Waktu pengembangan pengembang sangat tinggi. Jika dibutuhkan lebih lama dari di bawah (berdasarkan tingkat pengalaman) untuk meningkatkan pengembang baru, maka sistem perlu dirancang ulang. Pada waktu ramp-up, 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 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 lengkap versus pembangunan kembali secara bertahap lebih subyektif, dan karena itu lebih bermuatan politis. Apa yang bisa saya katakan dengan keyakinan adalah bahwa secara kategoris menyatakan bahwa itu tidak pernah 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 hal ini (baik teknis dan politik).

  • Teknis
    • Kopling komponen sangat tinggi sehingga perubahan pada satu komponen tidak dapat diisolasi dari komponen lain. Sebuah 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 oleh desain ulang. Hilangnya nafsu makan ini tidak terhindarkan untuk ditulis ulang juga, tetapi sponsor akan lebih cenderung untuk melanjutkan, karena mereka tidak ingin terbagi 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 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 lebih banyak amunisi untuk Dorong kembali.

Perlu diingat bahwa total biaya redesiging secara bertahap selalu lebih tinggi daripada melakukan penulisan ulang yang lengkap, tetapi dampaknya terhadap 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 bisa 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. Eksekutif dan pembelian akhir pengguna tampak seperti Unicorn berkepala dua untuk 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 coba mengonversi 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 yang paling sakit dengan sistem yang ada, dan migrasikan 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 bagaimana untuk 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.
328
Michael Meadows

Saya telah berpartisipasi dalam dua penulisan ulang besar. Pertama adalah proyek kecil. Yang kedua adalah produk utama perusahaan perangkat lunak.

Ada beberapa jebakan:

  • penulisan ulang selalu memakan waktu lebih lama dari yang diharapkan.
  • penulisan ulang tidak memiliki efek/manfaat langsung bagi pelanggan.
  • kapasitas yang ditujukan untuk menulis ulang tidak digunakan untuk mendukung pelanggan.
  • anda akan kehilangan fungsionalitas dengan penulisan ulang kecuali jika Anda memiliki dokumentasi 100%.

Penulisan ulang jarang merupakan jawaban nyata. Anda dapat memperbaiki sebagian besar kode tanpa kehilangan apa pun dan tanpa banyak risiko.

Penulisan ulang bisa menjadi jawabannya jika:

  • anda beralih ke bahasa atau platform lain.
  • anda mengganti kerangka/komponen eksternal.
  • basis kode yang ada tidak dapat dipelihara lagi.

Tapi saya sangat menyarankan pendekatan lambat menggunakan refactoring. Itu kurang berisiko dan Anda membuat pelanggan Anda senang.

112
Toon Krijthe

Saatnya menulis ulang ketika:

Biaya penulisan ulang aplikasi + memelihara aplikasi yang ditulis ulang kurang dari biaya pemeliharaan sistem saat ini dari waktu ke waktu.

Beberapa faktor yang membuat mempertahankan yang sekarang lebih mahal:

  • Bahasanya sangat lama sehingga Anda harus membayar orang yang tahu banyak uang untuk diprogram di dalamnya (COBOL).
  • (dari pengalaman, sayangnya) Sistem ini pada arsitektur perangkat keras yang sudah sangat tua sehingga mereka harus menjelajahi bagian Ebay dan MENGUMPULKAN untuk menambah mesin yang sedang berjalan karena mereka tidak dibuat lagi. Ini disebut "pendukung kehidupan perangkat keras" dan mahal karena ketika bagian menjadi lebih langka, mereka (mungkin) naik harga atau mereka (benar-benar) akhirnya akan habis.
  • Ini menjadi sangat kompleks sehingga //Here be dragons. komentar ada di seluruh kode Anda.
  • Anda tidak dapat menulis proyek lain dan menambahkan nilai baru ke perusahaan karena Anda selalu menambal binatang buas ini.
74
Ryan Hayes

Jika Anda memerlukan perubahan mendasar dalam arsitektur proyek, itu mungkin saatnya untuk memulai dari awal.

Bahkan dengan itu, akan ada potensi besar petak kode yang masih layak digunakan kembali dalam proyek baru Anda.

Perhatikan peringatan yang adil. Sebuah proyek saat ini akan memiliki aturan bisnisnya diuji dan disempurnakan dengan jam kerja penggunaan yang tak terhitung jumlahnya, sesuatu yang tidak akan benar dari proyek yang dimulai dari awal.

Saya ragu kerangka waktu atau firasat adalah ukuran yang tepat dari ukuran drastis tersebut. Anda harus memiliki jelas, dapat dipertahankan dan dipahami dengan baik alasan untuk ikut serta dalam tindakan ini.

17
Dan McGrath

Meskipun saya setuju dengan jawaban Kramii dan pendapat Joel, ada saat-saat yang tepat untuk menulis ulang. Dalam aplikasi berumur panjang (saya berbicara seperti 10-20 tahun atau lebih), pemeliharaan menjadi lebih dan lebih mahal dari waktu ke waktu. Ini karena kode menjadi lebih dan lebih spaghetti-ish sebagai arsitektur asli dikorbankan untuk tambalan perawatan cepat. Juga, pengembang untuk teknologi yang lebih tua menjadi lebih langka dan lebih mahal. Akhirnya, perangkat keras mulai menua dan semakin sulit untuk menemukan perangkat keras baru, sistem operasi, kerangka kerja, dll untuk menjalankan aplikasi lama di atas. Selain itu, bisnis berkembang, dan kemungkinan besar sistem yang lebih lama tidak akan memenuhi kebutuhan bisnis organisasi serta sistem yang baru.

Jadi, Anda harus mempertimbangkan semua biaya perawatan yang sedang berlangsung, serta potensi manfaat sistem baru untuk bisnis, dibandingkan dengan biaya penulisan ulang barang dari awal. Jadilah sangat pesimis dalam perkiraan Anda tentang biaya penulisan ulang. Hampir selalu biayanya lebih tinggi dan lebih lama dari yang Anda kira.

12
RationalGeek

Berhenti! Menulis ulang hampir tidak pernah jawabannya. Lebih sering daripada tidak, refactoring adalah taruhan yang lebih baik.


Tentu saja, ada ada saat saat penulisan ulang dibenarkan:

  • Anda beralih ke platform baru di mana alat migrasi tidak ada (atau tidak dapat ditulis dengan cukup murah).
  • Aplikasi yang akan ditulis ulang itu sepele.
  • Kode sumber untuk aplikasi asli hilang, dan pemulihan lebih mahal daripada menulis ulang.
  • Sebagian besar aturan bisnis yang dienkapsulasi oleh aplikasi yang ada tidak berlaku lagi.
  • Ada beberapa pengguna aktif dari kode yang ada.
  • Anda memiliki sumber daya (waktu, bakat dan alat) untuk melakukan penulisan ulang.
  • Aplikasi yang ada tidak dapat dijalankan di lingkungan produksi, karena alasan hukum atau praktis.

Untuk memahami mengapa saya merekomendasikan refactoring daripada menulis ulang, pertimbangkan apa yang terlibat dalam penulisan ulang. Kamu harus:

  1. Pahami nuansa apa yang dilakukan aplikasi yang ada. Ini biasanya tidak sepele ketika Anda memperhitungkan semua aturan bisnis halus yang diringkasnya, lingkungan (baik manusia dan teknis) di mana ia beroperasi dan keuntungan dan kerugian dari solusi saat ini. Lebih sering daripada tidak, satu-satunya tempat di mana informasi ini ada (jika ada) adalah dalam kode sumber aplikasi yang ada. Sangat disayangkan bahwa salah satu alasan utama untuk melakukan penulisan ulang adalah bahwa kode yang ada sulit dipahami dan dipelihara.

  2. Reproduksi fungsi ini (atau versi yang diperbarui) di aplikasi baru yang teruji dan andal. Kode yang ada mungkin tidak dipahami oleh pengembang, tetapi biasanya dipahami dengan baik oleh penggunanya. Mungkin tidak memenuhi kebutuhan bisnis mereka saat ini, tetapi mereka setidaknya dapat memberi tahu Anda apa yang dilakukan aplikasi dalam berbagai keadaan.

Keuntungan besar dari refactoring adalah:

  • Anda dapat mengambil barang-barang satu demi satu.
  • Setiap perubahan dapat diuji dalam konteks aplikasi yang ada dan berfungsi.
  • Hipotesis tentang cara kerja kode yang ada dapat diuji dengan membuat perubahan kecil dan mengamati apa yang terjadi.
  • Perubahan sering kali dapat disampaikan kepada pengguna secara bertahap daripada sekaligus.
  • Belajar dari tahap awal refactoring dapat menginformasikan tahap selanjutnya dari refactoring.
  • Jika Anda mengabaikan bagian proses secara keseluruhan, masih akan ada manfaat dalam hal basis kode yang lebih bersih (dibandingkan dengan penulisan ulang bahwa harus diselesaikan untuk menawarkan manfaat apa pun kepada pengguna atau pengembang).

Ingat juga, bahwa jika Anda menulis ulang, Anda dijamin akan memperkenalkan banyak bug baru dan mengacaukan basis kode baru.

11
Kramii

Grafik ini dapat membantu, ini merupakan fungsi dari kualitas basis kode dan nilai bisnis aplikasi:

enter image description here

Bagan tersebut berpura-pura menjadi panduan kapan rekayasa ulang perangkat lunak warisan dibenarkan dan kapan tidak. Misalnya, jika perangkat lunak memiliki nilai bisnis yang tinggi dan kualitas kodenya buruk, maka rekayasa ulang dibenarkan.

10
Tulains Córdova

Saya pikir saya berada dalam satu-satunya situasi dalam karir saya di mana penulisan ulang besar adalah jawabannya:

Penggabungan perusahaan, tumpang tindih besar dalam fungsi sistem. Banyak, banyak sistem telah digabungkan dan pensiun, dan yang lainnya masih dalam proses.

Saya telah mewarisi sistem dari perusahaan lain yang masih hidup. Ini memiliki basis kode yang sangat besar, yang digunakan untuk mendukung banyak departemen yang sangat mirip dengan milik kami, tetapi dengan desain dan kerangka kerja yang sangat berbeda. Hanya ada satu sektor bisnis yang tersisa menggunakannya, yang menghasilkan cukup uang yang membuat benda ini tetap hidup dalam keadaan zombie. Semua keahlian lama hilang, tidak ada dokumentasi. Beban dukungan tinggi, dengan kegagalan setiap minggu. Itu belum digabungkan ke dalam sistem perusahaan kami, karena perusahaan kami tidak pernah mendukung sektor bisnis ini, sehingga kami tidak memiliki fungsionalitas atau keahlian.

Sepertinya ini adalah satu-satunya kasus di mana penulisan ulang diperlukan. Sepertinya saya harus mencari tahu raksasa ini, mengeluarkan sedikit fungsionalitas yang didedikasikan untuk bisnis ini, dan menulis ulang bagian-bagian yang perlu ditambahkan ke sistem kami yang ada. Setelah itu selesai, sistem kami yang ada dapat mendukung sektor baru ini, dan binatang ini dapat dikeluarkan dari kesengsaraan itu. Kalau tidak, aku akan kehilangan kewarasanku.

8
Jay

Saya bekerja untuk perusahaan perangkat lunak kecil yang memiliki beberapa aplikasi DOS yang ditingkatkan untuk menangani Y2K, ditulis ulang sebagai aplikasi Windows 16-bit dan kemudian benar-benar ditulis ulang sebagai aplikasi 32 bit dengan satu tambahan fitur 'kecil' (akhirnya hanya digunakan oleh satu pelanggan) yang memengaruhi seluruh struktur.

Memindahkan kode 16 bit ke 32 bisa dilakukan dalam satu bulan oleh satu orang, tetapi Tidaaaakak, kami harus menulis ulang untuk membuatnya adalah Soooooooooo jauh lebih baik. Hal ini dapat diadaptasi untuk industri lain, akan memiliki spesifikasi lengkap dan kode psuedo bahkan sebelum mereka memulai. Spesifikasi dibuat, tetapi butuh waktu lama bahkan tidak ada waktu untuk menulis kode yang sebenarnya. Itu dirilis terlambat, dengan lebih banyak bug dari 16 bit 'dimulai' dengan (itu pada v.3.0 dan akhirnya ke titik di mana kami hampir membuatnya seminggu tanpa seseorang melaporkan bug baru).

Anda akan berpikir menulis ulang aplikasi yang sama 3-4 kali akan menghasilkan beberapa perbaikan, tapi saya tidak berpikir bahwa front-end GUI dapat dibenarkan sebanyak itu.

Ini adalah pekerjaan TI pertama saya sebagai kepala dukungan teknis. Saya harus menulis buku tentang bagaimana tidak mengembangkan perangkat lunak untuk distribusi. Jelas kami membuat banyak kesalahan, tetapi fakta bahwa kami terus menulis ulang aplikasi menambah ketidakmampuan.

7
JeffO

Saya punya kasus yang sangat mirip dengan Anda hanya kode bahkan tidak menggunakan Struts. Apa yang saya lakukan adalah menargetkan area yang sangat jelek DAN menyebabkan banyak masalah. Pendekatan yang ditargetkan ini membuat kami semakin baik.

Selama periode 2 tahun kami bekerja pada refactoring bit dan potongan di samping pekerjaan tambahan. Kami selalu mengerjakan tugas 'Pengerasan' ke dalam rencana proyek. Dengan berfokus pada area spesifik yang tidak berfungsi dengan baik, kami mendapatkan yang terbaik. Hal-hal yang berhasil kami tinggalkan sendiri. Juga penting adalah bahwa pekerjaan ini dilakukan dalam perjalanan perkembangan normal dan dirilis. Masalah dengan penulisan ulang besar Anda pergi selama satu tahun atau lebih dan kemudian pada saat Anda kembali setiap hal tetap berubah dan beberapa bug jahat dihaluskan dan Anda kehilangan ROI Anda.

Kami tidak pernah menulis ulang semuanya. Kami berhenti menggunakan platform itu untuk pekerjaan baru, dan mendirikan platform baru untuk proyek baru yang besar. Itu disetujui dan kami mengirimkan produk hebat dalam jumlah waktu yang wajar.

5
Bill Leeper

Jadi di sini saya duduk di meja saya, saya mulai menulis ulang kode untuk kekacauan absolut dari satu file aspx besar ini, database di belakangnya, dan mengganti antarmuka MS Access ke MsSQL.

Program asp penuh dengan hal-hal seperti

  • include(close.aspx) yang di dalamnya memiliki satu baris kode yang menutup koneksi database terbuka terakhir.
  • Kode lama hanya dikomentari secara acak
  • Tidak ada pertimbangan untuk keamanan
  • Kode spageti, ribuan barisnya. Semua dalam satu file.
  • Fungsi dan variabel tanpa arti yang jelas di belakang nama mereka

Jika kita perlu melakukan sedikit perubahan, itu seperti memainkan lima game sim-toh secara bersamaan pada mode mimpi buruk.

Saya disewa untuk meniru fungsi dan membuat produk yang dapat disesuaikan dan dijual kepada orang lain di industri. Masalahnya adalah hal ini telah ditulis selama 10 tahun terakhir untuk memenuhi setiap kebutuhan bisnis (well, saya akan mengatakan sekitar lima atau enam sigma dari mereka).

Jika kita tidak ingin menjual produk, mereka mungkin tidak akan memerlukan menulis ulang karena melakukan sebagian besar dari apa yang mereka inginkan - mungkin tidak elegan, tetapi tidak bijaksana untuk menghabiskan uang membuat kode yang bagus 'lakukan hal yang sama.'

5
Incognito

Solusi yang ada tidak skala.

Saya melihat Anda, MS Access.

4
user21007

Joel Spolsky memiliki artikel yang bagus tentang ini: Hal-Hal yang Seharusnya Tidak Pernah Anda Lakukan, Bagian I

Dari judul yang Anda tahu, ini agak satu sisi (dia berbicara tentang mengapa Anda tidak boleh melempar kode) IMO, ada banyak kebenaran untuk itu, saya baru-baru ini melihat video channel9 pada Peringatan 25 tahun Excel di mana beberapa dev mengatakan, bagaimana bahkan hari ini jika Anda melihat ke sumbernya Anda akan memeriksa revisi dan akhirnya kembali ke kode yang digunakan Excel yang ditulis 20 tahun yang lalu.

Anda tidak dapat 100% yakin (ketika bahkan Netscape membuat kesalahan (dari Joels Article)), [~ # ~] i [~ # ~] merasa seperti artikel Joel dikirim oleh Tuhan, karena saya bisa menjadi pesimis dan suka membuang kode berpikir saya selalu dapat menulisnya dengan lebih baik untuk yang kedua kalinya, tetapi saya baru menyadari sekarang ini saja harganya banyak .

Untuk memberikan jawaban yang konkret, saya hanya akan mengatakan Anda perlu melakukan analisis Biaya vs Nilai .

Dunia Nyata saya: Aplikasi silverlight Saya sedang mengembangkan v0.6 sejauh ini memiliki kekacauan panggilan async yang membuat kode begitu berbelit-belit. Karena saya menemukan Ekstensi Reaktif minggu ini saya benar-benar ingin menulis ulang sebagian besar kode, tetapi sekarang apa yang harus saya katakan kepada pelanggan saya? Program ini bekerja dengan baik (dengan beberapa kebocoran memori tho) tetapi mereka tidak peduli? Saya tidak mungkin memberi tahu mereka, Oh, saya butuh 2-3 minggu lagi karena saya ingin melakukan kembali sesuatu. Namun saya, akan menabur kode dan menulis ulang /bermain dengannya di gratis waktu.

Hanya 2 sen saya ok !?

4
gideon

Ada lelucon klasik tentang "jika saya akan ke X saya tidak akan mulai dari sini".

Saya mengambil pekerjaan sekali, di mana motivasi utama majikan adalah membawa bakat ke atas untuk meluncurkan penulisan ulang lama dari aplikasi bisnis-kritis. Pertanyaan yang saya gagal tanyakan adalah, mengapa Anda akhirnya berada dalam situasi ini? Seharusnya bendera merah, apakah penyebabnya

  • terlalu banyak tekanan untuk menambah fungsionalitas untuk mempertahankan dan secara bertahap refactor binatang itu,

  • kemampuan terlalu sedikit di departemen,

  • terlalu sedikit dukungan dari klien atau manajemen untuk pekerjaan tambahan,

atau apa pun, dan ini menyebabkan bernanah sampai masalah mencapai tingkat yang tak tertahankan.

Jadi saya akan setuju dengan Joel bahwa penulisan ulang besar-besaran mungkin adalah ide yang sangat buruk - kecuali jika Anda memiliki bukti kuat bahwa semua alasan mendasar di balik mengapa penulisan ulang besar tampaknya sangat perlu telah ditangani , Anda kemungkinan besar akan mengulangi masalah pada waktunya.

2
Julia Hayward

Ini adalah jawaban ketika penulisan ulang memungkinkan organisasi untuk mengejar strategi yang memberikan keunggulan kompetitif atau memungkinkannya untuk melayani pelanggan dengan lebih baik dengan cara yang tidak dapat diakomodasi oleh arsitektur saat ini.

Sebaliknya, penulisan ulang sering kali terjadi untuk mengurangi kekhawatiran manajemen:

  • semuanya harus dalam. NET,
  • pengembang kami mengatakan kode kami payah,
  • kami tertinggal secara teknis,
  • kami tidak akan dapat menemukan sumber daya untuk mendukung sistem kami atau, sangat sering,
  • sudah sepuluh tahun jadi sudah waktunya.

Sebagian besar kekhawatiran ini tidak akan terwujud dan, jika itu terjadi, mereka dapat ditangani. Yang terakhir, bagaimanapun, adalah yang terburuk. Ini pada dasarnya: kita tidak punya alasan.

Ya, seperti halnya mobil, suatu sistem akan mulai menunjukkan tanda-tanda aus. Ini dapat dikurangi dengan servis rutin. Anda tahu apa yang mereka katakan tentang bagaimana pemeliharaan preventif sedikit berjalan jauh. Sebagai investasi, servis rutin (mis. Refactoring dan standardisasi) hampir selalu membawa biaya lebih rendah daripada menulis ulang.

Namun, kita harus mengantisipasi bahwa penulisan ulang pada akhirnya akan diperlukan. Tetapkan tanggal dan tentatif rencanakan untuk itu, tetapi karena tanggal semakin dekat dalam keterlambatan dalam mewujudkan tujuan strategis lainnya hingga Anda memiliki alasan kuat seperti ...

Dalam beberapa tahun terakhir kami kehilangan kesempatan untuk memenangkan akun besar karena kami tidak dapat mengakomodasi kebutuhan mereka secara tepat waktu atau mahal. Sistem kami akan ditulis ulang menggunakan arsitektur yang dapat diperluas yang memungkinkan kustomisasi untuk dicolokkan (dan tidak hardcode seperti yang kita lakukan saat ini). Ini secara dramatis akan mengurangi waktu dan biaya untuk mengakomodasi pelanggan dengan kebutuhan khusus. Kami akan memenangkan lebih banyak akun dan lebih baik memenuhi kebutuhan pelanggan kami saat ini.

2
Mario T. Lanza

Saya pikir alasan utama yang membenarkan penulisan ulang adalah untuk perubahan platform. Misalnya, jika Anda memiliki aplikasi GUI desktop Windows dan pemilik perusahaan memutuskan mereka ingin versi berikutnya menjadi aplikasi berbasis web. Meskipun tidak selalu, dalam pengalaman saya sebagian besar waktu ini akan memerlukan penulisan ulang, kecuali pengembang asli menulis kode yang sangat modular dan dapat digunakan kembali (jarang terjadi).

2
Craig

Menurut Joel, penulisan ulang besar adalah kesalahan strategi tunggal terburuk yang dapat dibuat oleh perusahaan:

Hal-Hal yang Tidak Seharusnya Anda Lakukan, Bagian I

... Penting untuk diingat bahwa ketika Anda memulai dari awal ada sama sekali tidak ada alasan untuk percaya bahwa Anda akan melakukan pekerjaan yang lebih baik daripada yang Anda lakukan. pertama kali. Pertama-tama, Anda mungkin bahkan tidak memiliki tim pemrograman yang sama yang bekerja pada versi satu, sehingga Anda sebenarnya tidak memiliki "pengalaman lebih banyak". Anda hanya akan membuat sebagian besar kesalahan lama lagi, dan memperkenalkan beberapa masalah baru yang tidak ada dalam versi aslinya.

Mantra lama buat satu untuk dibuang berbahaya jika diterapkan pada aplikasi komersial skala besar. Jika Anda menulis kode secara eksperimental, Anda mungkin ingin merobek fungsi yang Anda tulis minggu lalu ketika Anda memikirkan algoritma yang lebih baik. Tidak apa-apa. Anda mungkin ingin refactor kelas agar lebih mudah digunakan. Itu baik juga. Tetapi membuang seluruh program adalah kebodohan yang berbahaya, dan jika Netscape benar-benar memiliki pengawasan orang dewasa dengan pengalaman industri perangkat lunak, mereka mungkin tidak akan menembak diri sendiri dengan begitu buruk.

2
user3287

Jangan pernah, selalu refactor - kebenarannya adalah jika kode itu ditulis oleh Anda - Anda tidak akan bisa melakukan yang lebih baik.

Kecuali jika Anda ingin mengubah teknologi, kode ini tidak memiliki struktur apa pun (saya melihatnya sangat lama di beberapa situs PHP, penulis hanya menyalin/menempel spahgetti alih-alih menyertakan/kelas/fungsi) atau Anda mengambil alih sesuatu dari orang lain yang ditulis dengan sangat buruk.

Semuanya harus dirancang sebagai kotak hitam. Modular, API Sederhana, apa yang ada di dalamnya ... itu kurang penting :) Jika Anda memiliki spageti, Anda mungkin dapat menutupnya di dalam kotak hitam, sehingga tidak akan mencemari kode yang baik.

2
Slawek

Ketika pindah ke teknologi yang benar-benar baru diperlukan untuk menyediakan fungsionalitas yang diinginkan.

"Benar-benar baru": jika Anda berencana untuk menulis ulang tetapi menggunakan platform yang sama, maka refactoring dan restrukturisasi yang bijaksana hampir pasti merupakan solusi yang lebih baik. "Platform," seperti yang digunakan di sini, agak kabur - pertimbangkan untuk memasukkan bahasa, dan mungkin OS (memperluas dari Linux ke Windows atau sebaliknya muncul di pikiran), tetapi mungkin bukan kerangka kerja (misalnya, mengganti Struts dengan Spring).

"Diperlukan untuk menyediakan fungsionalitas yang diinginkan": sekitar tahun 2000, saya memulai proyek untuk menulis ulang komponen server utama di Java dari C++ untuk mengaktifkan threading out-of-the-box, cache objek, dan transaksi yang dikendalikan oleh klien. Pada saat itu, ada beberapa pustaka threading untuk C++ yang harus kami dukung, dan mengaktifkan banyak kode basis data kami akan membutuhkan penulisan ulang hampir total. Adapun transaksi yang dikendalikan oleh klien. .. tidak akan terjadi dengan arsitektur yang lama.

Bahkan kemudian, saya tidak yakin bahwa saya akan melakukan penulisan ulang, kecuali bahwa saya memiliki pengetahuan rinci tentang perilaku sistem saat ini, dan itu adalah kode yang relatif bersih yang tidak mengembangkan banyak kutil dalam 11 tahun kehidupannya.

1
Anon

Yah saya bisa membayangkan skenario hipotetis di mana saya mungkin hanya membuang basis kode yang ada (situasi hipotetis di mana bola bucky memiliki berat dan volume nol, di mana tidak ada yang peduli jika kita kehilangan produktivitas berminggu-minggu atau berbulan-bulan saat kita berebut untuk menambahkan fitur dan bug yang terabaikan. perbaikan ke dalam sistem, dan di mana sistem itu sangat sepele dan dibenci oleh organisasi yang saya dapat mengganti seluruh hal dan pasukan server dengan notepad ++ dan netbook dalam sepuluh menit dan meningkatkan produktivitas dan moral semua orang di seluruh papan.)

Untuk hampir semua skenario dunia nyata, meskipun saya hanya akan merekomendasikan refactoring di tempat. ^ _ ^. Cenderung ada terlalu banyak biaya tersembunyi dan tidak terduga untuk ditulis ulang ketika persyaratan hukum dan bisnis yang tidak berdokumen mulai muncul dan saat-saat terakhir peretasan bersama-sama menit-menit terakhir mulai terjadi.

== Refactoring in Place untuk kebaikan yang lebih besar, dan barang ==

Refactoring legacy code dengan pendekatan incremental lama yang biasa,

  1. Jika Anda memiliki kesempatan untuk mengonversi ke UML dan mendokumentasikan apa arsitektur kecil yang ada.
  2. Jika Anda berada di kontrol versi, lihat untuk menghasilkan beberapa laporan kode churn dan mencari tahu file dan bagian file mana yang paling sering diubah. Buat catatan tentang ini karena mereka kemungkinan akan menjadi area yang Anda ingin atasi terlebih dahulu.
  3. Sebelum Anda mengubah kode apa pun, selalu mencoba untuk menambahkan beberapa cakupan pengujian (bahkan tes fungsional tumpukan penuh jelek akan dilakukan). Jika berurusan dengan logika ekstrak kode prosedural besar yang berantakan, Anda berniat untuk berubah menjadi beberapa metode atau fungsi bernama wajar dan jika mungkin menambahkan beberapa kasus uji yang memverifikasi metode baru Anda. buatlah apa pun yang Anda harus lakukan dan jika mungkin paramatize perubahan jika itu adalah sesuatu yang biasa di-tweak seperti lebar margin atau judul sehingga akan sedikit lebih mudah untuk memperbarui di waktu berikutnya.
  4. Gunakan pola adaptor dan bekerja keras untuk menyembunyikan bit kode legacy secara kasar di bawah permadani kelas dan metode yang dinamai secara logis sehingga untuk sebagian besar tugas umum yang Anda dan pengembang lain lakukan, Anda tidak perlu khawatir tentang bit menakutkan yang terjadi di belakang punggung Anda di belakang metode dan kelas bersih kecil yang bagus yang telah Anda sembunyikan kode warisan di belakang - seperti keluarga Nice yang menjaga cacat zombie mantan anggota keluarga di lumbung sehingga mereka tidak merusak hari ke hari yang sedang terjadi di salah satu tanah pertanian . . . biasanya.
  5. Ketika Anda terus mengurangi dan membersihkan bagian kode terus meningkatkan cakupan pengujian Anda. Sekarang Anda dapat menggali lebih dalam dan "menulis ulang" bahkan lebih banyak kode bila dibutuhkan/diinginkan dengan kepercayaan yang semakin meningkat.
  6. Ulangi, atau terapkan pendekatan refactoring tambahan untuk terus meningkatkan basis kode Anda.

Percabangan Berdasarkan Abstraksi

  1. Tentukan titik masalah dalam kode yang ingin Anda hapus (lapisan kegigihan, generator pdf, mekanisme penghitungan faktur, generator widget, dll.).
  2. jalankan (tulis jika perlu) beberapa kasus uji fungsional (otomatis atau manual tetapi Anda tahu otomatis) terhadap basis kode yang menargetkan fungsi ini bersama dengan perilaku umum.
  3. Ekstrak logika yang terkait dengan komponen itu dari sumber yang ada ke dalam kelas dengan beberapa antarmuka yang masuk akal.
  4. Verifikasi semua kode sekarang menggunakan antarmuka baru untuk melakukan aktivitas X yang sebelumnya tersebar secara acak di seluruh kode (Grep basis kode, tambahkan jejak ke kelas baru dan verifikasi halaman yang seharusnya memanggil itu, dll.), Dan bahwa Anda dapat mengontrol implementasi mana yang akan digunakan dengan memodifikasi satu file. (objek registry, kelas pabrik, apa pun IActivityXClass = Pengaturan.AcitivtyXImplementer ();)
  5. jalankan kembali kasus uji fungsional yang memverifikasi semuanya masih berfungsi dengan semua Activity X dilemparkan ke kelas baru Anda.
  6. Tulis tes unit jika memungkinkan di sekitar kelas pembungkus X aktivitas baru.
  7. mengimplementasikan kelas baru dengan logika spageti yang lebih tidak gila daripada implementasi legacy yang melekat pada antarmuka yang sama dengan kelas legacy.
  8. verifikasi bahwa kelas baru lulus tes unit yang Anda tulis untuk kelas warisan.
  9. perbarui kode Anda dengan mengubah registri/metode pabrik/apa pun untuk menggunakan kelas baru alih-alih kelas lama.
  10. verifikasi bahwa tes fungsional Anda masih lulus.

Prinsip Tertutup Terbuka dan Logika Bisnis Umum/Lapisan Persistensi

Hingga taraf tertentu Anda mungkin dapat melepaskan lapisan presentasi, bisnis, dan kegigihan Anda dan menulis aplikasi baru yang sepenuhnya kompatibel dengan solusi legacy, atau setidaknya masih dapat menangani data yang dimasukkan oleh solusi legacy. Saya mungkin tidak akan merekomendasikan pendekatan ini tetapi kadang-kadang itu adalah kompromi yang wajar dari waktu/jadwal/sumber daya/fungsionalitas baru yang diperlukan.

  • Setidaknya pisahkan lapisan presentasi dari lapisan bisnis dan kegigihan.
  • menerapkan lapisan presentasi baru dan lebih baik yang menggunakan lapisan umum bisnis dan kegigihan yang sama.
  • Verifikasi bahwa data yang dibuat dengan ui baru tidak merusak ui lama. (Anda akan berada di air panas jika pengguna alat baru mengganggu pengguna alat lama). Jika Anda berjuang untuk kompatibilitas mundur penuh Anda harus menyimpan semuanya ke lapisan kegigihan yang sama. Jika Anda hanya ingin meneruskan kompatibilitas ke alat baru kemudian gunakan database baru dan tabel baru atau tabel ekstensi untuk melacak data yang tidak ada dalam sistem lama.
  • Untuk fungsionalitas baru dan lapisan persistensi perlu menambahkan tabel baru dan metode tidak mengubah logika warisan yang ada, atau menambahkan kolom, kendala ke tabel yang ada. misalnya jika Anda perlu mulai melacak kontak darurat pemberi kerja dan beberapa bidang lainnya tidak mengubah tabel karyawan yang ada (kami tidak tahu asumsi apa yang dibuat oleh data lawas tentang tabel itu) menambahkan tabel ekstensi id employee_ext, employee_id, emergency_contact_id, etc_id.
  • Migrasikan pengguna dengan lambat ke sistem baru. jika memungkinkan, masukkan sistem lawas ke mode hanya baca, atau tambahkan saja pengguna yang memberi tahu peringatan itu tidak akan tersedia lagi setelah tanggal X.
  • menerapkan fungsionalitas apa pun yang terlewatkan prioritas tinggi atau persyaratan bisnis di ui baru
  • berguling basis pengguna.
  • lanjutkan untuk membersihkan logika bisnis dan kegigihan pengguna lapisan metodologi refactoring lainnya.
0
Keith Brings

Saya akan mengatakan ada kategori ketiga dalam ruang Refactor vs Menulis Ulang ... Dan itu memperbarui versi bahasa Anda, kompiler, dan perpustakaan ... Kadang-kadang hanya mengadopsi teknik pengkodean modern memiliki manfaat besar.

Ambil C # misalnya, kode v7 menulis jauh lebih bersih, lebih aman, dan lebih ringkas daripada v2 .. Hal-hal seperti Elvis dan operator penggabungan nol membantu satu ton.

Mengganti kompiler juga dapat menghidupkan kehidupan baru ke dalam kode yang lebih lama. Jadi mungkin perpustakaan baru yang mungkin membuat hal-hal lebih mudah untuk dikerjakan dan diimplementasikan ... Jaringan adalah contoh yang bagus dari spektrum kesulitan implementasi.

Juga - sistem linux tertanam ... Pikirkan tentang menginstal alat baru - beralih ke git dari svn. atau tambahkan Vi ke sistem Anda dll.

Itu tidak selalu harus menjadi refactor vs menulis ulang .. Arsitektur Anda mungkin perlu perbaikan, tetapi berfungsi ... mungkin Anda hanya perlu berpikir tentang bagaimana kode Anda ditulis dll.

0
visc

Untuk menentukan titik di mana Anda harus memulai dari awal, Anda perlu mencari tahu di mana nilai melanjutkan proyek Anda saat ini jauh dari nilai dalam memulai kembali.

Alasan mengapa hal ini sangat sulit adalah karena Anda membuat perkiraan yang akurat tentang kecepatan pengembangan tim pada proyek baru sampai Anda benar-benar memulainya. Yang mengatakan, jika, dengan menggunakan perkiraan SANGAT konservatif dari kecepatan pengembangan Anda pada proyek baru, proyek diperkirakan memberikan pengembalian investasi yang berharga, maka Anda memiliki kasus bisnis untuk memulai lagi.

0
Nobody

Dengan metrik saya, Anda harus memenuhi dua syarat untuk membenarkan penulisan ulang:

  1. Setelah menulis ulang fitur baru akan lebih mudah/lebih cepat/kurang buggy untuk menulis
  2. Penulisan ulang akan memakan waktu kurang atau sama daripada menambahkan fitur baru saat ini.

Bahkan kemudian Anda ingin membatasi ruang lingkup penulisan ulang Anda. Sebagai contoh, kami memiliki beberapa perangkat lunak lama di sebuah perusahaan yang ditulis dalam C++ dengan pola pikir seorang programmer C yang tidak tahu tentang modularitas. Hasil akhirnya adalah kode speghetti dalam bentuk mesin negara terbatas yang membentang beberapa kelas dan DLL. Kami memiliki persyaratan baru yang sangat berbeda dari asumsi yang dimasukkan ke dalam kode, dan akan menjadi bagian dari nilai tambah yang dipatenkan perusahaan kepada pelanggannya.

Setelah menghabiskan waktu dengan kode yang mengimplementasikan fitur-fitur lain, saya memiliki ide yang bagus tentang berapa lama waktu yang dibutuhkan untuk mencari tahu dari beberapa pernyataan pergantian mana yang perlu saya ubah, dll. Proposal saya adalah untuk menulis ulang bagian kode yang mesin negara terbatas yang besar - itu harus saya kurang waktu daripada memperpanjang kode yang ada. Saya dapat mengkonsolidasikan ke dalam satu DLL apa yang dulu tiga, dan memberikan struktur yang lebih berorientasi objek yang akan membuatnya jauh lebih mudah untuk melakukan fungsionalitas baru yang kritis bersama dengan membuatnya lebih mudah untuk tambahkan fungsionalitas baru.

Ada tiga aplikasi lain yang menggunakan perpustakaan yang membutuhkan penulisan ulang, jadi saya tidak mau harus menulis ulang program-program itu sepenuhnya. Ruang lingkup terbatas pada perpustakaan dan apa yang diperlukan untuk mengikat perpustakaan dengan perangkat lunak yang ada. Perkiraan saya tidak jauh, dan pekerjaan itu dibayar sendiri. Tak lama setelah mendesain ulang, saya ditugaskan untuk menambahkan fitur baru. Apa yang akan membuat saya seminggu dengan struktur lama hanya butuh satu hari dengan struktur baru.

0
Berin Loritsch

OP tidak menunjukkan ruang lingkup proyek, tetapi petunjuk utama yang saya ambil adalah "ditulis dalam [bahasa/dialek] lama menggunakan [libs]" yang bagi saya merupakan pendorong utama penulisan ulang. Pada kenyataannya, sebagian besar proyek yang saya ikuti dari umur panjang pasar yang signifikan pada akhirnya menyadari bahwa mengakomodasi pembaruan untuk kompiler/juru bahasa/sistem operasi adalah tugas penting dalam mempertahankan basis kode.

Singkatnya, saya akan merencanakan penulisan ulang secara bertahap, terlebih dahulu memprioritaskan pembaruan dalam libs. Mungkin di sepanjang jalan, Anda bisa menyelinap dalam optimasi lain, tetapi fakta bahwa Anda berencana menunda beberapa perubahan ke fase selanjutnya bisa menjadi cara yang bagus untuk tetap pada jadwal dan menghindari "terjebak."

0
MarkHu