Mengorganisir kode kotor yang tidak diomentari?

22

Saya ingin menanyakan beberapa pertanyaan tentang kode kotor. Ada beberapa pemula yang berkode pada proyek menengah. Kode itu adalah bola lumpur yang sangat besar. Mereka bukan pemrogram tingkat lanjut. Mereka hanya tahu cara menggunakan keyboard sedikit tentang java. Mereka hanya menulis kode dengan 12.000 baris di kelas utama mereka, meskipun, 6.000 baris milik NetBeans sendiri.

Pekerjaan saya adalah menganalisis kode dan menyarankan cara yang baik untuk mempertahankan kode tersebut. Ide saya adalah untuk membatalkan proyek dan memulai yang baru dengan metodologi OOP. Baru-baru ini saya mengumpulkan beberapa catatan dan ide tentang masalah, dari situs ini dan beberapa lainnya.

Sekarang, saya punya pertanyaan berikut:

  1. Haruskah kita memperbaiki kodenya, dan mengubahnya menjadi OOP? Kami sekarang sedang men-debug-nya.
  2. Kode tidak memiliki komentar, tidak ada dokumentasi, tidak ada gaya pemrograman tertentu, dan sebagainya. Mengubahnya sangat mahal dan memakan waktu. Apa yang bisa kita lakukan tentang ini?
  3. Bagaimana saya bisa mengajar mereka untuk mengikuti semua aturan (berkomentar, OOP, kualitas kode yang baik, dll.)?
  4. Kode ini salah dan rentan kesalahan. Apa yang bisa kita lakukan? Pengujian? Kami hampir menulis dua atau tiga kertas A4 untuk koreksi, tetapi sepertinya tidak ada habisnya.

Saya harus mengatakan bahwa saya baru dengan mereka. Saya pikir saya telah melanggar aturan tentang menambahkan orang terlambat ke proyek, juga. Apakah Anda pikir saya harus meninggalkan mereka?

project-management  code-quality 
— Salivan
sumber
Ini perlu dibagi menjadi dua atau tiga pertanyaan, itu terlalu luas saat ini.
— Jon Hopkins
2
Apakah proyek ini di bawah kendali versi?
— JBRWilkinson
2
Apakah kode saat ini dalam produksi?
— JeffO
Ya Jeff. Ini adalah produksi, proyek manajemen untuk mengelola masalah keuangan!
— Salivan
Maaf JBR, mereka tidak mendengar hal seperti itu. Hanya membuat coupe kode copy paste di seluruh hard disk adalah teknik mereka untuk melakukan pengontrolan versi.
— Salivan

Jawaban:

36

Langkah 0: Cadangkan ke SCM

Karena, seperti yang ditunjukkan oleh JBRWilkinson dalam komentar, kontrol versi adalah garis pertahanan pertama Anda terhadap bencana (yang tidak dapat diubah).

Lakukan juga pencadangan detail konfigurasi perangkat lunak, prosedur untuk membuat kiriman, dll ...

Langkah 1: Tes Pertama

Kemudian mulailah dengan menulis tes :

  • untuk apa yang berhasil,
  • dan untuk apa yang gagal.

Tidak peduli apa yang Anda putuskan untuk dilakukan, Anda dilindungi. Anda sekarang dapat:

  • mulai dari awal dan tulis ulang ,
  • atau memperbaikinya .

Saran saya adalah memulai arsitektur umum dari awal , tetapi ekstrak dari kekacauan bagian-bagian yang memvalidasi pos pemeriksaan dan untuk memperbaiki ini sesuai keinginan Anda.

Langkah 2: Verifikasi dan Monitor

Siapkan sistem Integrasi Berkelanjutan (untuk melengkapi langkah 0 dan langkah 1 ) DAN sistem Inspeksi Berkelanjutan (untuk mempersiapkan langkah 4 ).

Langkah 3: Berdiri di Pundak Giants

(seperti biasa ...)

Langkah 4: Bersihkan

Semacam itu tidak perlu dikatakan lagi, tetapi alih-alih membaca sendiri kode, Anda mungkin ingin menjalankan linter / analisa statis dan alat-alat lain pada basis kode yang rusak untuk menemukan kesalahan dalam desain dan implementasi.

Maka Anda mungkin juga ingin menjalankan pemformat kode, yang akan sedikit membantu dalam tata graha.

Langkah 5: Tinjau

Sangat mudah untuk memperkenalkan bug kecil dengan refactoring atau membersihkan berbagai hal. Hanya membutuhkan pilihan yang salah dan klik cepat pada tombol, dan Anda mungkin menghapus sesuatu yang cukup penting tanpa disadari pada awalnya. Dan terkadang efeknya akan muncul hanya beberapa bulan kemudian. Tentu saja, langkah-langkah di atas membantu Anda menghindari hal ini (terutama dengan menerapkan alat uji yang kuat), tetapi Anda tidak pernah tahu apa yang bisa dan akan lolos. Jadi, pastikan agar refactoring Anda ditinjau oleh setidaknya satu pasang bola mata khusus lainnya (dan lebih disukai lebih dari itu).

Langkah 6: Bukti Masa Depan Proses Pengembangan Anda

Ambil semua hal di atas, dan jadikan itu bagian yang tak terpisahkan dari proses pengembangan Anda yang biasa, jika sudah tidak. Jangan biarkan ini terjadi lagi di jam tangan Anda, dan bekerja sama dengan tim Anda untuk menerapkan perlindungan dalam proses Anda dan menegakkan ini (jika itu mungkin) dalam kebijakan Anda. Jadikan memproduksikan Kode Bersih sebagai prioritas.

Tapi sungguh, tes . Banyak .

— haylem
sumber
Saran yang bagus - tidak masalah kerusakan apa yang Anda lakukan jika Anda memiliki tes yang dapat menangkap masalah. Tentu saja, kita semua berasumsi bahwa mereka sudah memiliki kontrol versi ..
— JBRWilkinson
@JBRWilkinson: poin bagus sebenarnya! Memang benar-benar berasumsi mereka melakukannya.
— haylem
2
Mulai kontrol versi terlebih dahulu; lebih baik terlambat daripada tidak sama sekali.
— JeffO
@ Jeff O: ya, itu sudah apa yang saya tambahkan ke jawabannya.
— haylem
Menulis ulang untuk membuat lebih jelas setelah diedit. Atribusi kiri :)
— haylem
15

Secara pribadi, saya tidak akan memulai proyek ini sampai saya memiliki salinan Bekerja Efektif dengan Legacy Code . Serius, itu ditulis untuk hal seperti ini. Ini penuh dengan strategi untuk berurusan dengan kode rumit, dan jauh lebih detail daripada yang bisa saya berikan di sini.

— Jason Baker
sumber
1
+1 untuk penggunaan referensi eksternal yang luas yang menyebutkan semuanya.
— haylem
Sayangnya, di sini orang tidak tahu tentang membaca buku. Hanya mengembangkan proyek yang berhasil adalah semua yang mereka butuhkan. Saya mulai membaca buku yang Anda sebutkan, dan CODE COMPLETE 2 juga. Izinkan saya mengatakan bahwa mereka ditulis dengan sangat baik.
— Salivan
1
@ Salivan - Mungkin mereka tidak punya orang yang meyakinkan mereka bahwa buku-buku seperti itu layak dibaca. Andai saja ada orang yang bekerja dengan mereka yang tertarik membaca buku-buku semacam itu ...
— Jason Baker
1
@ Salivan - kuncinya adalah menemukan satu atau dua kemenangan cepat. Lakukan sesuatu yang memiliki pengembalian yang hampir segera. Seperti kontrol versi, jadi lain kali seseorang mengatakan "bagaimana itu bisa terjadi" Anda bisa mencarinya. Kemudian bawalah mereka ke beberapa saran dari membaca salinan WELC Anda. Jangan hanya melempar buku kepada mereka.
2
@Salivan Anda dapat membaca buku untuk mereka, dan meneteskan konten ke mereka sebagai saran. Anda mungkin menjadi guru tim.
— MarkJ
8

Saya pernah ke sana beberapa kali. Aturan saya adalah: jika perangkat lunaknya tidak sepele (lebih dari 1 minggu berfungsi untuk sumber daya yang Anda miliki) dan itu berfungsi, maka simpan dan lanjutkan dengan refactoring tambahan.

Jika perangkat lunak tidak benar-benar berfungsi (jumlah bug sangat tinggi, persyaratan tidak jelas, dll.) Daripada lebih baik untuk menulis ulang dari awal. Sama jika itu cukup kecil.

Intinya dalam refactoring (seperti dalam buku Fowler dan yang Kerievsky http://www.industriallogic.com/xp/refactoring/ ) adalah bahwa hal itu membuat sistem bekerja, mungkin refactoring akan memakan waktu dua kali lipat tetapi risikonya nol.

Menulis ulang dari awal dapat menimbulkan banyak risiko, mulai dari kesalahpahaman persyaratan hingga implementasi yang salah (toh sebagian besar tim akan sama).

Saya benar-benar melihat prosedur kompleks yang ditulis ulang dari awal dua kali dan masih tidak berfungsi seperti yang diharapkan.

— Uberto
sumber
Saya juga menyarankan penulisan unit test untuk metode yang tepat, jika memungkinkan. Mereka akan membantu menentukan dengan jelas apa yang seharusnya dilakukan oleh kode , yang akan membantu proses refactoring.
— Michael K
2
Tak usah dikatakan ... Saya menganggap TDD syarat untuk kode yang baik (alias yang baru).
— Uberto
Menulis dari awal adalah ide yang sangat bagus. Tetapi pertama-tama Anda perlu memiliki beberapa diagram pekerjaan. Tapi apa yang akan Anda lakukan jika Anda harus menganalisis kode untuk mengekstrak hubungan? Selain itu, ukuran proyek membuatnya tidak mungkin, atau itu akan membuat kita menyewa beberapa programmer lain.
— Salivan
Pengembangan Test Driven dihargai!
— Salivan
"Tapi apa yang akan kamu lakukan jika kamu harus menganalisis kode untuk mengekstrak hubungan?" -> jika ini masalahnya berarti proyek tidak kecil atau rusak. Aku akan mulai melakukan refactoring satu per satu. Lihat juga metode Mikado. danielbrolund.wordpress.com/2009/03/28/…
— Uberto
2

Saya akan menulis ulang sepenuhnya. Terkadang tidak mungkin untuk memperbaiki kode semacam itu. Pilihan lain adalah membuatnya berfungsi, tanpa menambahkan fitur baru. Untuk mengajar tim menulis kode yang baik (dirancang dengan baik, didokumentasikan, dengan tes) biarkan mereka memperbaiki kode yang Anda miliki sekarang. Biarkan semua orang untuk memperbaiki bug / meninjau kode pengembang lain, bukan bagiannya. Setelah beberapa upaya mereka akan memahami bahwa hampir tidak mungkin untuk meninjau / memperbaiki kode tersebut.

Menambahkan orang ke proyek yang terlambat sangat jarang membantu. Biasanya itu melanggar tenggat waktu. Anda harus melakukan apa saja untuk menyelesaikan proyek dengan sukses, dan kemudian berpikir untuk pergi.

— duros
sumber
Berapa biaya untuk menulis ulang sepenuhnya dibandingkan iteratif meningkatkannya? Pendekatan mana yang akan memberikan hasil tercepat?
— JBRWilkinson
@ JBRWilkinson Tergantung. Pendekatan berulang baik, ketika Anda memiliki kode kerja.
— Duros
1
@duros, untuk kode yang rusak, ya. Kode ini berjalan dalam produksi.
2

Saran saya adalah untuk tidak menghapus seluruh kode sepenuhnya. Ini adalah masalah kehidupan sehari-hari, yang dihadapi oleh setiap tim pengembangan. Serang satu bagian kode sekaligus. Perbaiki, bersihkan, dokumentasikan. Dan kemudian pindah ke bagian lain. Hal utama adalah selalu menyimpan beberapa kode yang dapat dikirim di tangan. Menulis ulang seluruh kode dari awal akan mengambil jumlah waktu yang telah dihabiskan sampai sekarang dan tidak akan ada jaminan bahwa itu akan lebih baik daripada saat ini.
Tetapi kemudian juga orang-orang harus menghindari penulisan kode dengan cara ini. Luangkan lebih banyak waktu dalam ulasan kode. Beradaptasi dengan beberapa gaya pengkodean seragam. Diskusikan desain terlebih dahulu dan kemudian tulis kodenya. Hal-hal sederhana seperti itu akan membuat perubahan besar.

Blog yang bagus menceritakan mengapa Netscape longgar

— Manoj R
sumber
2
Memulai proyek baru, sambil memperbarui / men-debug versi lama dalam waktu yang berarti (dan Anda tidak dapat menghindari ini jadi jangan bermimpi tentang hal itu) sedang mencoba untuk menembak pada beberapa target bergerak.
— JeffO
"Serang satu bagian kode sekaligus" tidak berhasil, Manjo. dengan kesedihan yang mendalam, kode itu mengandung banyak kesalahan. Itu selalu berubah menjadi sesuatu yang lain. Kita harus menyerang dan menghancurkan satu bagian dari kode dan membangunnya kemudian. Saya menyarankan pemikiran ini kepada manajer sekali, tetapi coders harus tidak menulis kode baru.
— Salivan
@ Salivan ... harus tidak menulis kode baru . Saya yakin manajemen mengatakan ini. Tetapi hal pertama yang harus dilakukan ketika Anda berada di dalam lubang adalah berhenti menggali (jangan terus melakukan kesalahan yang sama). Agar lebih banyak yang bisa dibuat dalam kondisi ini adalah dengan terus menggali lubang. Bagian yang sulit adalah bagaimana mendapatkan manajemen dan coders untuk memahami masalahnya.
— SeraM
1

Jika berhasil, refactor saja. Ada alat untuk membantu Anda melakukan itu. Jika tidak berhasil, gunakan perintah peningkatan kode magis, yaitu deltreepada Windows resp. rm -rfdi Linux.

— pengguna281377
sumber
2
Menyarankan untuk "sepenuhnya menghapus semua kode" sangat tidak membantu - apakah Anda memiliki jawaban yang lebih konstruktif?
— JBRWilkinson
LOL. Saya sepenuhnya setuju dengan Anda, amunisi!
— Salivan
JBRWilkinson: Melakukan restart baru kemungkinan besar merupakan pendekatan yang lebih baik daripada mencoba membuat kekacauan bekerja dan bersih. Sebuah perusahaan tempat saya pernah mencobanya, dan tahun demi tahun, mereka telah menyia-nyiakan banyak sumber daya dan sama sekali tidak punya tempat.
— user281377
@ammoQ, Anda perlu kode lama untuk melihat apa yang sebenarnya terjadi, ketika Anda salah.
1
Thorbjorn: Kita berbicara tentang kode yang tidak berfungsi , bukan? Menganalisis kode kotor tanpa komentar yang tidak melakukan hal yang benar memberi tahu saya lebih banyak tentang kondisi mental penciptanya daripada yang lain.
— user281377
1

Haruskah kita memperbaiki kodenya, dan mengubahnya menjadi OOP? Kami sekarang sedang men-debug-nya. [... mengandung kesalahan, tidak ada dokumentasi ...]

Aku pernah ke sana, kau punya simpati. Saya bahkan menulis artikel tentang ini yang mungkin bisa membantu Anda mendapatkan perspektif. Namun singkatnya:

Jika kode berisi banyak duplikasi, Anda harus menulis ulang. Jika tidak ada struktur yang dapat dilihat (tidak ada antarmuka yang jelas, spageti), refactoring akan gagal dan Anda mungkin harus menulis ulang.

Bagaimana saya bisa mengajar mereka untuk mengikuti semua peraturan?

Mulailah dengan menjelaskan mengapa mereka mungkin ingin melakukan itu dengan menunjukkan kepada mereka apa yang dapat mereka peroleh darinya secara pribadi. Ketika mereka setuju dengan ini dan mau belajar, mulailah mengajar mereka menggunakan shuhari .

— Martin Wickman
sumber
Terima kasih Martin. "Mulailah dengan menjelaskan mengapa mereka mungkin ingin melakukan itu dengan menunjukkan kepada mereka apa yang dapat mereka peroleh darinya secara pribadi. Ketika mereka setuju dengan ini dan bersedia untuk belajar, mulailah mengajar mereka menggunakan shuhari."
— Salivan
0

Saran saya adalah kombinasi dari jawaban @ duros & @Manoj R.

Mulai dari awal, ingat untuk membuat kode yang baik / OOP / berkomentar / dll kali ini, lihat / salin & tempel dari kode lama Anda. Ketika Anda memenuhi bagian-bagian buruk dari kode lama Anda, tulis ulang / perbaiki mereka.

Jika pengembang Anda tidak terlatih dengan baik, saya pikir bagus untuk mengirim mereka ke kursus. Ini penting untuk pelatihan ulang reguler di industri TI yang cepat berubah

— Jiew Meng
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.