Bagaimana cara memperbaiki pola salin / tempel?

Di tempat saya bekerja, orang (konsultan) merasa terdesak untuk merilis fitur secepat mungkin. Jadi alih-alih menghabiskan terlalu banyak waktu untuk berpikir tentang bagaimana melakukan sesuatu dengan cara yang benar atau karena mereka tidak ingin merusak apa pun, kode disalin dari modul yang berbeda dan dimodifikasi.

Tidak mudah untuk mencegah hal ini, karena basis kode terbuka untuk seluruh perusahaan. Banyak orang yang mengerjakan ini.

Sekarang kekacauan sudah ada, apa cara terbaik untuk menghapus redudansi tanpa melanggar terlalu banyak?

Salah satu bagian dari jawabannya adalah Refactoring .

Pertama, mulailah menulis unit test untuk memastikan bahwa Anda tidak secara tidak sengaja merusak apa pun dengan perubahan Anda. Kemudian mulailah meningkatkan desain, menghapus duplikasi, dll. Dalam langkah-langkah kecil, menjalankan pengujian unit Anda setelah setiap langkah, memperbaiki masalah apa pun jika salah satu tes gagal, atau langsung kembali jika Anda mengalami masalah yang lebih besar daripada yang dapat Anda pecahkan dengan mudah.

Bagian lainnya adalah pendidikan .

Orang harus diajari untuk tidak meninggalkan kode buruk. Ini tentu saja merupakan pertempuran jangka panjang, karena kebiasaan dan proses berpikir sulit (kadang-kadang bahkan tidak mungkin) untuk diubah . Namun, tanpa itu, Anda hanya akan terus mendapatkan persediaan kode buruk yang terus-menerus berteriak untuk di-refactored.

Anda dapat memilih untuk melakukan tinjauan kode grup untuk membuka diskusi tentang kebiasaan pengkodean yang baik dan buruk, dan sebarkan manfaat dari yang sebelumnya. Tidaklah cukup untuk mengatakan "Anda harus (tidak) menulis kode seperti ini", Anda perlu meyakinkan orang-orang dengan logika dan fakta keras. Seperti "jika Anda memiliki bagian metode ini digandakan pada basis kode n kali, menurut Anda kemungkinannya adalah bahwa jika bug ditemukan dalam metode itu, itu akan diperbaiki di setiap salinan kode metode?"

Perusahaan Anda mungkin juga perlu merevisi insentif dan kriteria penerimaan untuk para konsultan - jika mereka bisa lolos dengan menulis kode ceroboh, mereka pasti akan tetap memilih jalur yang lebih mudah. Jika perusahaan terus menilai "pengiriman cepat" dalam pemeliharaan jangka panjang, tidak ada yang akan berubah :-( Jadi Anda mungkin perlu mendiskusikan ini dengan manajemen juga. Salah satu cara untuk membuat mereka mengerti adalah ini: refactoring berarti menjaga kode tetap bersih, mudah pahami dan pertahankan. Menghilangkan refactoring seperti menumpuk hutang pada kartu kredit Anda. Anda dapat meloloskan diri untuk sementara waktu, tetapi jika Anda tidak secara aktif mengelola kebiasaan beli dan utang Anda, suatu hari nanti pasti akan remuk di pundak Anda. Dalam kehidupan proyek perangkat lunak, kebangkrutan adalah ketika proyek menjadi tidak dapat dipelihara: menjadi lebih mudah untuk menulis ulang dari awal daripada menambahkan fitur baru ke basis kode yang ada. Atau pengguna jadi muak dengan tingkat dukungan dan fitur yang lebih rendah sehingga mereka beralih ke kompetisi.

Sebagai bagian dari pendidikan seperti yang dikatakan @Peter, Anda dapat memperkenalkan detektor salin & tempel seperti PMD dan menggunakannya sebagai bagian dari siklus Anda untuk membantu menegakkan bagian standar pengodean Anda ini.

Pastikan bahwa standar pengkodean proyek Anda mencakup pola ini sehingga Anda memiliki dasar untuk memulai diskusi.

orang (konsultan) merasa terdesak untuk merilis fitur secepat mungkin

Anda tidak memiliki masalah teknis, Anda memiliki masalah sosial. Memang, Anda memiliki masalah manajemen.

Tidak mudah untuk mencegah hal ini, karena basis kode terbuka untuk seluruh perusahaan. Banyak orang yang mengerjakan ini.

"Basis kode terbuka untuk seluruh perusahaan" bukan masalah. Tidak masalah.

Yang penting adalah bahwa ada sistem penghargaan manajemen untuk copy-and-paste. Akar penyebabnya adalah bahwa orang-orang dihargai (yaitu, dibayar atau dipuji atau dipromosikan atau diperpanjang) untuk salin dan tempel.

Anda tidak dapat memecahkan ini tanpa mengubah budaya secara mendasar dari "menekan untuk melepaskan fitur secepat mungkin" menjadi "dihargai karena melakukan perubahan basis kode yang sesuai dan teruji dengan baik."

Kamu harus

1. Mulai dari atas, dengan manajer yang memperkuat penghargaan. Anda harus mengekspos praktik saat ini dan mendokumentasikan biaya dan risiko. Anda harus mengusulkan alternatif yang mengurangi biaya dan risiko.

2. Anda harus tanpa henti mendokumentasikan dan memaparkan biaya dan risiko untuk sisa masa kerja Anda di organisasi itu. Tanpa henti. Berbasis fakta. Biaya dan Risiko. Setiap minggu lebih banyak biaya dan lebih banyak risiko dari copy-and-paste.

3. Anda harus membantu manajer menghargai pendekatan baru yang akan membuat mereka terlihat bagus dan Anda akan diabaikan.

Sangat penting untuk mengurangi copy-and-paste. Tetapi sulit untuk mengubah budaya organisasi. Anda harus memberikan banyak fakta dan Anda harus membuat kasus ini berulang-ulang kepada manajer yang tidak setuju dengan Anda.

Saya memiliki basis kode sekarang yang mulai membusuk dari itu. Saya memiliki lebih dari 10 fungsi statis per modul yang pada dasarnya identik dengan fungsi statis yang sama di modul lain. Masing-masing berperilaku cukup berbeda untuk menjamin inkarnasi baru demi melakukan sesuatu secepat mungkin.

Hari ini, saya harus menambahkan fitur lain dan saya tidak tahan lagi. Saya membuat perpustakaan baru, menggabungkan fungsi 100+ menjadi 10 fungsi reentrant yang sedikit mengubah perilaku mereka berdasarkan flag bit dan kemudian menulis serangkaian tes untuk memastikan setiap perubahan pada perpustakaan itu tidak merusak hal lain.

Total waktu yang dihabiskan: 4 jam. Saya siap untuk pergi maraton 20 jam jika perlu dan terkejut melihat betapa cepat saya membawa kekacauan yang tumbuh di bawah kendali. Sebagai bonus, selanjutnya lebih mudah untuk memperbaiki banyak masalah ketergantungan header. Selain itu, karena banyak barang milik kami sekarang ada di objek statis untuk ditautkan, kami dapat memberikan pelanggan kami yang mendapatkan akses ke kode sumber lebih dari yang kami lakukan sebelumnya.

Saran saya: gigit peluru dan ulangi faktor yang berantakan sekarang sebelum melakukannya benar-benar menjadi buruk . Mungkin tidak akan memakan waktu selama yang Anda pikirkan, tetapi buat cabang baru untuk Anda sendiri untuk berjaga-jaga.

Selain itu, Anda masih dapat menyalin / menempel untuk mendapatkan fitur keluar dari pintu sambil memperbaiki masalah mendasar. Setelah selesai, robek saja barang yang disisipkan dan gunakan perpustakaan baru sebagai gantinya.

Saya setuju dengan jawaban yang diberikan sejauh ini. Anda harus:

• buat tes unit
• refactor
• mendidik
• berupaya mengkode standar dan mendeteksi pelanggaran

Tetapi di sisi lain Anda perlu melihat apa yang menyebabkan orang menyalin dan menempelkannya.

• orang mungkin tidak dapat menggunakan kembali kode dengan cara yang baik karena digabungkan ke banyak
• orang mungkin tidak tahu bahwa ada perpustakaan yang bisa mereka gunakan
• Kode perpustakaan mungkin tidak cukup umum dan memanggang versi Anda sendiri jauh lebih mudah daripada menggunakan perpustakaan yang ada
• Mungkin tidak ada strategi versi yang baik (bukan kontrol sumber) dan mengubah perpustakaan umum mungkin hanya menyebabkan banyak aplikasi lain untuk diuji juga.

Jadi saya pikir untuk menghentikan pola salin / tempel yang Anda butuhkan untuk membuat penggunaan kembali lebih mudah.

• membuat perpustakaan dapat ditemukan dan didokumentasikan dengan baik
• membuat perpustakaan independen dari segalanya
• pikirkan strategi versi yang bagus
• memastikan kompatibilitas mundur
• Pikirkan tentang ekstensibilitas yang mudah dari perpustakaan

baca Pedoman Desain Kerangka

Semoga ini membantu.

Ada sikap "copy paste yang dianggap berbahaya" yang kuat. Saya pikir itu bagus, tapi terlalu jauh. Salin tempel sebagai latihan dalam menemukan persamaan dan perbedaan antara dua metode atau kelas - sebagai langkah dalam proses triangulasi - saya pikir sehat. Tetapi menghentikan triangulasi lengkap - menghilangkan duplikasi yang dilakukan oleh copy paste - memang berbahaya.

Jika Anda dapat menemukan cara untuk menggunakan sikap yang lebih bernuansa itu, untuk memberi tahu pengembang bukan "itu buruk!", Melainkan "itu tidak lengkap, bisakah Anda bekerja dengan saya untuk menyelesaikan refactoring?", Maka Anda mungkin menemukan diri Anda mengadakan percakapan yang lebih konstruktif.

Saya prihatin dengan masalah yang sama di sini, dan pendapat saya adalah: Jangan mencoba menghindarinya di muka, hanya refactor ketika itu menjadi terlalu buruk.

Modul yang sedang saya kerjakan di startet sebagai salinan dari modul lain, sekarang saya mengubah semua yang perlu berbeda. Setelah ini selesai, dan modul baru selesai, saya akan membandingkannya dengan modul asli dan mencari tahu bagian mana yang lebih atau kurang tidak berubah dan harus dipindahkan ke perpustakaan, kelas induk abstrak dll.

Siapa pun yang bertanggung jawab bersalah. Satu orang tidak dapat diharapkan untuk meninjau setiap baris kode, tetapi mereka menetapkan standar dan kerangka waktu.

Kontraktor (atau siapa pun yang jangka pendek pada suatu proyek) dapat ditempatkan pada posisi di mana mereka hanya diberi kompensasi untuk membuatnya bekerja pertama kali. Ada beberapa insentif untuk menyelesaikannya secepat mungkin. Kode yang disalin mungkin tidak perlu dimodifikasi dan jika tidak, mereka tidak akan melakukannya.

Anda dapat mencoba dan memaksa mereka untuk memperbaikinya pada waktu mereka sendiri. Kemudian mereka akan mulai melakukannya dari awal, tetapi kemudian mengambil waktu luang untuk menyelesaikan sesuatu. Saya pikir AmmoQ memiliki ide yang tepat untuk melakukan refactoring hal-hal yang menyebabkan masalah.

Satu-satunya cara untuk menghilangkan kode salin / tempel adalah ulasan kode (IMHO), minta seseorang (atau lebih baik lagi) untuk memeriksa kode dan ketika mereka menemukan kode yang tampaknya berasal dari tindakan salin / tempel biarkan programmer refactor.

Seperti yang disarankan ini terutama merupakan masalah dalam organisasi. Cobalah untuk memulai dengan mendidik orang (jangan lupa lapisan manajemen langsung di atas posisi Anda). Sangat membantu untuk mulai membuat satu atau dua orang di kereta Anda dan membiarkan virus menyebar. Ketika mayoritas berpikir ini adalah ide yang baik, uraikan dan cobalah untuk memperkenalkan ulasan untuk memastikannya tetap seperti ini. Ini adalah proses yang sangat lambat dan membosankan tetapi tidak bisa berubah dengan cepat. Pada awalnya akan membutuhkan waktu tambahan sehingga manajemen penting mengetahui dan mendukung tujuan jangka panjang.

@Anders K. Ulasan adalah cara yang baik untuk menjaga praktik tetap di tempatnya. Ketika memaksa orang untuk menulis kode, mereka tidak percaya akan menciptakan banyak gesekan. Mereka akan jatuh kembali ke kebiasaan lama secepat mungkin. Saya yakin Anda harus mulai dengan pendidikan untuk mendapatkan momentum.