Menyelesaikan konflik gabungan karena refactoring

Saya terlibat dalam diskusi baru-baru ini tentang bagaimana menangani refactoring secara umum (yang merupakan topik yang menarik dalam dirinya sendiri). Akhirnya pertanyaan berikut muncul:

Bagaimana seseorang menangani konflik gabungan yang terjadi karena seseorang melakukan refactoring sebagian kode, sementara orang lain sedang mengerjakan fitur untuk bagian kode yang sama?

Pada dasarnya, saya tidak tahu bagaimana menghadapi ini secara efisien. Apakah ada praktik terbaik yang harus diikuti seseorang mengenai hal ini? Apakah ada perbedaan tentang bagaimana seseorang harus menangani ini untuk sistem dengan banyak kode lawas?

Pertanyaan bagus. Strategi terbaik yang dapat saya pikirkan adalah:

Pencegahan

Kombinasi dari integrasi berkelanjutan dan membuat refactoring kecil sering (bukan refactoring besar-besaran sesekali) akan pergi jauh untuk meminimalkan biaya dan frekuensi konflik tersebut.

Saya pikir untuk menjawab pertanyaan Anda, pertama-tama kita harus melihat mengapa konflik terjadi, dan apa arti sebenarnya dan proses penggabungan?

Konflik hanya terjadi ketika dua atau lebih pengembang bekerja pada file yang sama pada saat yang sama dan kemudian mereka berdua mencoba untuk check in. Pengembang pertama tidak akan mendapatkan konflik, tentu saja. Tetapi yang kedua (ketiga, keempat, dan seterusnya) akan mendapat konflik. Mengapa, karena dia memiliki beberapa kode yang sebagian atau seluruhnya berbeda dari kode yang ada di server.

Ini sifatnya berarti bahwa pengembang kedua memiliki sesuatu yang berbeda dari pengembang pertama. Perbedaan ini dapat bervariasi dari gaya, seperti menggunakan new UserManager().GetUserName()alih-alih UserManager userManager = new UserManager(); userManager.GetUserName();ke tingkat yang Anda sebutkan, yang berarti bahwa kedua pengembang memiliki ide berbeda tentang cara membuat ulang kode untuk memperbaikinya.

Penggabungan, di sisi lain, tidak berarti bahwa pengembang dapat memeriksa kode mereka tanpa mempertimbangkan konflik. Mereka harus dan harus mengatasi konflik itu. Jika konflik tidak penting, maka mereka dapat check-in dan mengganti kode sebelumnya. Tetapi ketika mereka melihat sesuatu yang sama sekali berbeda, mereka harus memanggil pengembang sebelumnya, dan berbicara dengannya, sehingga mereka berdua dapat dikoordinasikan bersama untuk memeriksa solusi terbaik.

Misalnya, jika Anda meminta dua pengembang untuk meningkatkan perpustakaan pembayaran online, dan pekerjaan mereka tumpang tindih, ini berarti bahwa setidaknya di beberapa tempat, ada 2 solusi berbeda. Jadi, salah satu solusi itu harus dibicarakan dan diterima, sehingga masuk, sebagai solusi yang lebih baik.

Saya tidak setuju untuk mencegah keadaan ini, karena kita cenderung lebih nyata daripada teoretis. Kadang-kadang seorang pria benar-benar bagus dalam CSS, sementara yang lain sangat bagus di ASP.NET Markup. Tetapi pekerjaan mereka mungkin bertentangan ketika mereka berdua harus bekerja pada halaman login untuk membuatnya berfungsi. Maksud saya, jika kita berpikir nyata (tidak ideal), kita dapat melihat bahwa banyak kali fenomena ini (konflik) terjadi.

Poin lain yang ingin saya sebutkan adalah menggunakan alat untuk membantu Anda dalam proses check-in. Alat-alat ini biasanya memvisualisasikan perbedaan kode server dan kode pengembang, dan banyak membantu dalam menentukan bagian mana yang harus diperiksa.

Jika tidak ada manajemen tugas yang aktif, Anda memiliki konflik.

Namun, jika Anda memiliki rapat harian atau manajer , Anda tidak mungkin mengalami masalah ini.

Entah berbicara (melalui berdiri harian) atau berbicara dengan manajer.

Ini sepele dicegah dengan berbicara.

Memiliki cabang umum yang terpisah untuk mengembangkan fitur tertentu, sering menggabungkan / menarik / mendorong - itu saja.

Dan berkomunikasi . Bicaralah dengan pengembang lain tentang kode bahkan ketika diluncurkan. Bahkan ketika coding)))

Pastikan penggabungannya sesederhana mungkin. Refactoring biasanya merupakan proses yang agak mekanis yang mengubah banyak baris yang ada : Memindahkan deklarasi variabel, mengubah spasi, memformat, urutan operasi. Penciptaan fitur biasanya merupakan usaha yang jauh lebih kreatif, sering kali menghasilkan kode baru ditambah beberapa perubahan kecil pada kode yang ada. Sekarang jika pengembang yang melakukan refactoring mencatat langkah-langkahnya (misalnya sebagai ekspresi reguler), akan lebih mudah untuk menerapkannya pada kode dengan fungsi ekstra daripada sebaliknya. Berdasarkan ini, saya akan mengatakan bahwa sebagai aturan umum Anda harus menerapkan perubahan paling kompleks terlebih dahulu, diikuti dengan perubahan yang semakin sederhana.