Bagaimana cara menegakkan praktik kontrol kode sumber yang baik / lebih baik?


28

Saya menduga bahwa saya berfokus pada masalah yang salah, jadi saya pertama-tama akan menjelaskan apa yang saya pikir masalahnya sebelum menyajikan solusi yang mungkin saya bayangkan kurang optimal.

Situasi
Saat Ini: Saat ini rekan kerja saya melakukan perubahan kode hanya setelah periode waktu yang lama dalam potongan besar dengan perubahan yang menyebar di seluruh proyek. Itu kemajuan saya kira, karena belum lama ini mereka hanya menempatkan arsip zip di beberapa jaringan. Namun, penggabungan adalah mimpi buruk - dan terus terang saya sudah cukup. Dan saya juga bosan berbicara dan menjelaskan dan memohon. Ini hanya harus berhenti - tanpa saya terus-menerus menjadi "orang jahat".

Solusi saya:
Karena tampaknya tidak ada kesadaran dan / atau tidak ada minat pada masalah dan saya tidak dapat mengharapkan upaya apa pun untuk bertahan lebih lama dari beberapa hari ... lakukan itu, berjam-jam, saya ingin server subversi melakukan omelan.

Pertanyaan saya:
Apakah saya jauh-jauh di sini atau saya melihat masalah yang salah? Sepertinya saya kehilangan sesuatu, dan saya pikir saya menanyakan hal yang salah dengan melihat alat untuk menyelesaikan masalah saya.

Haruskah saya mencari alat untuk menyelesaikan masalah ini atau apa yang harus saya lakukan untuk memperbaikinya?


Bukankah masalah yang mereka miliki menggabungkan insentif bagi mereka untuk ingin meningkatkan cara mereka bekerja?
Flosculus

1
Hanya satu ide, buat mereka menggabungkan kode;) Tetapi satu hal yang menghalangi saya di SVN untuk sering melakukan adalah, bahwa itu butuh waktu sangat lama dibandingkan dengan git misalnya ...
Knerd

5
Siapa yang bertanggung jawab untuk menyelesaikan konflik setelah seseorang melakukan penggabungan?
Flosculus

Pendekatan yang tinggi pada percabangan dapat memberikan yang terbaik dari kedua dunia; jika Anda melakukan pekerjaan besar pada cabang dan secara teratur menggabungkan cabang master ke cabang itu (jadi semua gabungan kecil) maka ketika Anda akhirnya menggabungkan cabang kembali ke master yang menggabungkan itu sepele, tetapi sementara itu Anda belum mendapat kondisi perantara pada master yang rusak atau membingungkan tidak lengkap. Ini lebih mudah dengan beberapa SCM daripada yang lain (tergantung pada bagaimana bercabangnya cahaya), tetapi dapat bekerja dengan salah satu dari mereka.
Jon Hanna

Jawaban:


47

Anda sedang mencari solusi teknis untuk masalah manusia. Itu jarang berhasil.

Alasan untuk itu adalah karena jika anggota tim tidak menerima sesuatu (atau memahami implikasinya), daripada mengikuti aturan, mereka akan berusaha mengelak dari mereka. Itulah sebabnya, misalnya, pengembang harus menerima dan memahami aturan gaya alih-alih hanya dipaksa untuk mematuhi oleh pemeriksa.

Berikut adalah beberapa pendekatan yang saya gunakan di masa lalu atau yang ada dalam pikiran tanpa benar-benar memiliki kesempatan untuk mereka dalam praktek. Beberapa mungkin tidak berlaku untuk kasus Anda, tergantung pada posisi yang Anda miliki dalam tim (jika Anda seorang pemimpin tim dengan reputasi yang sangat baik, kemungkinan Anda akan memiliki kesempatan yang lebih baik untuk menegakkan pandangan Anda daripada jika Anda seorang sarjana yang baru saja bergabung dengan tim selama masa magang Anda).

  1. Diskusikan masalah ini dengan rekan kerja Anda dan jelaskan konsekuensi dari komitmen besar. Mungkin mereka tidak mengerti bahwa penggabungan yang rumit adalah konsekuensi langsung dari komit yang jarang, dan dari komit yang kecil dan sering akan membuat penggabungan (relatif) mudah.

    Saya tahu banyak programmer yang hanya yakin bahwa penggabungan selalu rumit. Mereka melakukan paling banyak satu komit per hari, menghindari menggunakan alat yang kuat seperti diff Visual Studio dan auto-merge, dan memiliki praktik penggabungan manual yang buruk (kecuali "Ambil milikku" tanpa inspeksi lebih lanjut sebenarnya adalah praktik yang baik). Bagi mereka, ini tidak ada hubungannya dengan mereka , dan merupakan sifat yang melekat dari suatu penggabungan.

  2. Berikan contoh nyata tentang apa yang terjadi di perusahaan lain (terutama yang sangat dihargai oleh rekan kerja Anda). Mereka mungkin tidak menyadari bahwa itu adalah masalah, dan diyakinkan bahwa komitmen maksimum satu per hari adalah apa yang dilakukan oleh setiap tim.

    Beberapa orang tidak menyadari bahwa ada tim yang terdiri dari 5-10 anggota yang membuat hingga 50 dorongan untuk produksi, yang berarti rata-rata 5-10 komitmen per hari per orang. Mereka mungkin tidak mengerti bagaimana itu mungkin, atau mengapa ada orang yang melakukannya.

  3. Menurut contoh. Cukup lakukan sedikit diri Anda. Jika memungkinkan, lakukan presentasi singkat yang menunjukkan gabungan mereka dan Anda secara berdampingan selama lebih dari seminggu (saya tidak yakin apakah mengekstraksi informasi semacam ini mudah dari kontrol versi). Tekankan pada kesalahan akhirnya yang telah mereka lakukan selama penggabungan dan bandingkan dengan jumlah kesalahan yang telah Anda lakukan (yang seharusnya mendekati nol).

  4. Gunakan teknik "Sudah kubilang", jika perlu . Ketika Anda melihat kolega Anda menderita karena penggabungan yang menyakitkan, berkomentar keras bahwa komit kecil dan sering dapat membuat penggabungan (relatif) tidak menyakitkan.

  5. Jelaskan bahwa tidak ada durasi minimum untuk membuat komitmen. Komit bahkan mungkin sesuai dengan perubahan kecil yang dibuat dalam beberapa detik. Mengganti nama file, menghapus komentar usang, mengoreksi kesalahan ketik adalah semua tugas yang dapat dilakukan segera.

    Pemrogram tidak perlu takut melakukan komit kecil, melainkan menggabungkan banyak perubahan menjadi satu komit besar.

  6. Bekerja dengan individu alih-alih tim, jika perlu. Jika ada seseorang yang secara khusus menolak untuk sering melakukan, melakukan sedikit, berbicara dengan orang ini secara individual untuk melihat mengapa dia menolaknya.

    Mereka mungkin memberikan alasan yang benar-benar valid yang dapat memberi Anda petunjuk tentang apa yang terjadi dengan tim. Beberapa alasan saya pernah mendengar sendiri:

    • “Guru / mentor saya memberi tahu saya bahwa praktik terbaik adalah dengan melakukan satu komitmen per hari.” Itu tidak mengejutkan saya, mengingat apa yang harus saya dengar dari guru-guru saya di perguruan tinggi .

    • “Rekan-rekan saya mengatakan kepada saya bahwa saya harus membuat lebih sedikit komitmen.” Saya telah diberitahu itu juga di beberapa tim, dan saya mengerti maksud mereka. Kami memiliki catatan yang praktis diisi dengan komitmen saya (tidak sulit untuk dilakukan ketika empat rekan tim bahkan tidak melakukan satu komitmen per hari), yang membuat rekan kerja saya frustrasi.

    • “Saya pikir komit kecil membuat sulit untuk menemukan revisi.” Entah bagaimana poin yang valid, bahkan ketika tim berusaha menulis pesan log deskriptif.

    • "Saya tidak ingin membuang terlalu banyak ruang di server kontrol versi kami." Orang itu jelas tidak mengerti bagaimana komit disimpan (atau seberapa murah ruang penyimpanan).

    • "Saya pikir komit harus sesuai dengan tugas tertentu." Mengingat bahwa sering, tugas sesuai dengan beberapa pekerjaan yang harus dilakukan dalam satu hari (seperti di papan tugas manajemen visual), ini bukan kebetulan. Orang tersebut kemudian harus belajar untuk membuat perbedaan antara tugas dalam tumpukan (2 sampai 8 jam kerja) dan perubahan yang terisolasi secara logis yang harus dilakukan (beberapa detik hingga beberapa jam kerja). Ini juga terkait dengan poin 5.

  7. Cari alasan tim tidak melakukan komitmen lebih sering. Anda mungkin akan terkejut dengan hasilnya.

    Baru-baru ini, saya menyebutkan dalam jawaban yang berbeda bahwa kecepatan sebuah komit penting, dan bahkan ratusan milidetik mungkin mendorong pengembang untuk melakukan komitmen lebih jarang.

    Alasan lain mungkin termasuk:

    • Aturan yang terlalu rumit untuk menulis pesan komit.

    • Aturan yang memaksa pengembang untuk menautkan komit ke tugas dari sistem pelacakan bug.

    • Ketakutan merusak bangunan.

    • Keengganan untuk berurusan dengan risiko melanggar pembangunan sekarang: jika Anda melakukan komitmen pada Jumat malam sebelum pergi, Anda dapat menunda berurusan dengan bangunan rusak hingga Senin.

    • Takut melakukan penggabungan.

  8. Tentukan apakah pengembang memahami bahwa ada manfaat lain yang sering dilakukan . Misalnya, platform Integrasi Berkelanjutan adalah insentif besar untuk sering melakukan , karena memungkinkan untuk menentukan dengan tepat di mana regresi diperkenalkan .

    Saya lebih suka platform CI mengatakan kepada saya bahwa saya melanggar build di revisi 5023 yang terdiri dari perubahan dalam dua metode dalam satu file yang saya lakukan lima belas menit yang lalu, daripada di revisi 5023 yang terdiri dari perubahan yang menjangkau empat lusin file dan mewakili 13 jam kerja.


"Kamu mencari solusi teknis untuk masalah manusia. Itu jarang berhasil." - Saya tahu, tapi saya lelah dan sudah menyelesaikan semua poin Anda. Ini bukan masalah saya lebih lama, namun ...
VolkerK

@VolkerK: lihat edit saya (dua paragraf pertama dari jawabannya). Apakah Anda memiliki server CI? Ketika Anda sudah berbicara dengan rekan kerja Anda, bagaimana mereka menjelaskan keengganan mereka untuk melakukan lebih sering?
Arseni Mourzenko

1
@VolkerK Jawaban ini menjelaskan dengan sangat baik. Anda tidak memiliki masalah teknis. Masalahnya adalah orang menolak untuk mengikuti prosedur.
BЈовић

1
Menuju poin 3: Klien TortoiseSVN dapat membuat berbagai diagram yang memvisualisasikan perilaku check-in berdasarkan parameter yang berbeda (seperti waktu). Sebenarnya cukup menarik untuk mengevaluasi mereka. Saya sering melakukan ini pada hari-hari kami menggunakan SVN. stackoverflow.com/questions/412129/... :)
Aschratt

2
Terima kasih atas masukannya tetapi saya mengambil rute lain dan hanya memberi pemberitahuan ;-)
VolkerK

-3

Sebuah organisasi yang pernah saya kontrak sebelumnya ingin menyelesaikan masalah yang sama ini, dan menghasilkan solusi sosial yang cukup baik: pengembang tidak memiliki komputer sendiri. TIM pengembangan memiliki komputer, tetapi setiap individu dapat diminta dan diharapkan untuk bekerja pada komputer pengembangan apa pun pada hari tertentu. Jadi, memeriksa adalah satu-satunya cara untuk memastikan Anda dapat terus mengerjakan apa yang Anda lakukan kemarin!

Manajemen kemudian pergi berkeliling dan secara diam-diam mengembalikan perubahan pada komputer setelah jam sehingga apa pun yang tidak diperiksa hilang. Ini "kegagalan komputer simulasi" hanya harus terjadi beberapa kali sebelum devs naik.

Tentu saja, penting untuk menjelaskan "mengapa" aturan serta "apa". Kecuali jika "mengapa" dibuat jelas, mereka bisa menyimpan sumbernya di drive USB atau apalah.


4
Ini adalah cara yang mengerikan untuk memperlakukan orang. Apa yang terjadi ketika Anda memikirkan sesuatu yang benar sebelum pergi dan ingin memilikinya di mesin, tetapi tidak lengkap (seperti tidak membangun) sehingga Anda tidak ingin melakukannya?
user1118321

3
Dan itu adalah pemborosan sumber daya, karena biasanya Anda memiliki lingkungan pengaturan yang sesuai dengan kebutuhan Anda. Saya memiliki situasi yang sama sejak lama, dan mendapatkan laptop saya sendiri setelah 4 minggu. Saya benci setiap hari untuk melakukan pengaturan yang sama, hanya untuk melakukan pekerjaan yang saya harapkan.
mliebelt

1
Wow, ini ide yang buruk karena banyak alasan. Seperti yang telah disebutkan dalam komentar di atas, (1) mencegah kemungkinan kesinambungan dari hari ke hari dan (2) menyangkal orang kemampuan untuk mengatur lingkungan dev kustom yang bertahan ...
Ben Lee

1
... Tetapi juga (3) memiliki potensi untuk menghancurkan jam kerja jika seseorang lupa untuk memeriksa kode, atau tidak sengaja karena suatu alasan dan (4) menunjukkan kepada para devs bahwa manajemen tidak percaya mereka untuk mengikuti aturan , alih-alih memaksakan aturan dengan cara yang kejam, berpotensi menjadikannya lingkungan as-vs-mereka dan (5) memiliki potensi untuk mendorong mereka menghindari aturan hanya agar menjadi produktif.
Ben Lee

Tolong, tidak ada yang menerapkan ide ini.
Ben Lee
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.