Saya akan mencoba memberi Anda beberapa petunjuk yang didukung oleh pengalaman pribadi saya.
Salah satu rekan tim saya, meskipun berpengalaman, tidak benar-benar mengerti SVN. Secara alami, area kosong pada peta mentalnya yang menggambarkan lautan SVN menyebabkan dia mengadopsi pola penggunaan yang agak aneh.
Misalnya, ia telah menyatakan kebijakan "1 SVN komit per hari per pengembang" karena jika tidak, "server akan segera kehabisan ruang disk". Ketika saya menjelaskan kepadanya bahwa komitmen SVN adalah delta, bukan salinan lengkap, dia menjawab dengan keraguan dan bahkan hari ini saya tidak sepenuhnya yakin apakah dia mengerti apa artinya.
Bahkan jika ruang disk adalah masalah, Anda selalu dapat melakukan banyak file sekaligus, jadi saya pikir apa yang ia sarankan adalah solusi yang salah. Lebih lanjut, adalah mungkin untuk membuang banyak ruang dengan memeriksa file biner besar karena SVN tidak menyimpan delta untuk file biner. Satu kali check-in per hari juga buruk karena memaksa Anda untuk melakukan perubahan yang tidak termasuk bersama, misalnya jika Anda memperbaiki lebih dari satu bug per hari.
Solusi yang kami adopsi di perusahaan kami adalah ada filter yang menolak komit yang berisi file biner. Kami dapat memaksa komit dengan menggunakan kata kunci khusus di komentar check-in (kami harus menunjukkan kepada SVN bahwa kami tahu apa yang kami lakukan). Sekali dalam satu atau dua tahun manajer proyek mengarsipkan cabang-cabang lama dan memindahkannya dari repositori. Dengan strategi ini kami tidak memiliki masalah ruang yang saya tahu (repositori kami mendukung beberapa proyek berbeda dan memiliki lebih dari 100.000 revisi).
Meringkas, Anda bisa memberi tahu dia bahwa Anda setuju dengannya bahwa ruang disk adalah masalah penting tetapi, di sisi lain, tunjukkan
- pentingnya check-in terkait fitur daripada satu check-in harian monolitik;
- fakta bahwa dengan memeriksa dalam satu file biner besar per hari, orang tetap dapat mengisi disk.
Kemudian Anda dapat menyarankan agar Anda mengadakan pertemuan (mungkin dengan pengembang lain atau administrator sistem juga) untuk membahas strategi untuk menjaga penggunaan ruang disk di bawah kendali (mis. Filter file biner, cadangan reguler, dan membersihkan cabang lama yang tidak digunakan).
Kami juga memiliki argumen panas tentang apakah akan memasukkan konfigurasi Eclipse .project di SVN. Rekan satu tim saya bersikeras bahwa kita harus melakukannya, walaupun itu telah menyebabkan banyak konflik yang tidak berguna. Saya menentang menjaga file konfigurasi pengembang individual di SVN. Akhirnya, ternyata rekan tim saya memiliki praktik checkout ulang seluruh pohon sumber setelah setiap komitmen untuk memastikan "kode yang dikomit ke dalam karya repositori". Itulah alasan dia sangat bersikeras dalam menjaga konfigurasi proyek di SVN - jadi akan mudah untuk mengimpor kembali proyek. Ketika saya menjelaskan bahwa komit menyinkronkan copy pekerjaan ke byte-demi-byte jarak jauh yang membuat checkout kembali tidak perlu, rekan tim saya menjawab dengan keraguan lagi dan akhirnya melambaikan seluruh masalah sebagai tidak signifikan.
Menurut pendapat saya, tim kami membuang-buang waktu dengan menyelesaikan konflik SVN dalam file konfigurasi proyek yang hanya berisi pengaturan khusus pengembang yang tidak perlu dibagi ke SCM sama sekali. Semua ini berantakan karena seseorang menyesuaikan proses dengan asumsi yang salah.
Apakah Anda menggunakan server build? Kami memiliki server build yang memeriksa proyek lengkap dan mengkompilasinya setiap malam. Pagi berikutnya, penguji memiliki penginstal produk yang siap uji (jika master build berjalan dengan benar) dan kami (pengembang) memiliki laporan build dengan semua peringatan (dan kesalahan, jika ada). Tentu saja, Anda perlu mengatur file konfigurasi standar untuk server build dan memeriksanya. Setiap pengembang kemudian dapat memeriksanya bersama dengan sisa proyek, tetapi mereka tidak diizinkan untuk memeriksa perubahan lokal apa pun .
Dalam skenario ini Anda mengatasi kebutuhannya untuk dapat memeriksa proyek lengkap dan membangunnya kapan saja. Anda juga menghindari menghabiskan waktu untuk menggabungkan perubahan yang seharusnya tidak diperiksa sejak awal karena itu bukan bagian dari produk: produk adalah master build, dan itu harus dijaga kebersihannya. Jika seseorang merusak master build (mis. Memeriksa sendiri file .projectnya), Anda dapat mengembalikan perubahan atau memaksa pengembang untuk memperbaiki masalah.
Mungkin jika dia mengemukakan masalah lagi, Anda dapat kembali menyarankan untuk mengadakan pertemuan (mungkin dengan pengembang lain) dan menemukan strategi bersama bersama.
Bagaimana saya bisa meyakinkan teman satu tim, yang melihat diri sendiri sebagai senior, untuk mendapatkan pemahaman yang lebih baik tentang dasar-dasar SVN?
Saya pikir strategi terbaik adalah untuk menghindari membawa konflik ke tingkat pribadi dan lebih baik membahas masalah yang ada dan solusi yang mungkin. Jika Anda memiliki kesan bahwa dia mencari konfrontasi pribadi, berikut adalah beberapa saran (dari pengalaman pribadi):
- Bagaimana dinamika tim Anda? Apakah kolega Anda yang lain memiliki pengalaman yang sama dengan rekan setim ini? Ada banyak petunjuk kecil, tidak terlalu eksplisit yang dapat diberikan oleh tim kepada salah satu anggotanya untuk mencegah perilaku tertentu (lelucon kecil atau pengamatan) dan mendorong konfrontasi konstruktif (mengusulkan pertemuan, atau mengangkat topik secara informal saat rehat kopi) ). Terkadang tim yang baik dapat dengan cepat mengisolasi elemen yang mengganggu dan membawa semuanya kembali normal.
- Seberapa baik manajemen personalia Anda? Kami memiliki satu kasus konflik di perusahaan kami dan kepala personel harus turun tangan untuk membersihkan situasi. Itu tidak baik, tetapi kadang-kadang suasana kerja memburuk sehingga tidak akan membaik dengan sendirinya. Saya harap ini bukan kasus Anda (saya tidak memiliki kesan itu sudah sejauh ini) tetapi selalu baik untuk mengetahui apakah Anda memiliki administrasi kepegawaian yang baik atau jika Anda harus menyelesaikan konflik sendiri.
Mengapa saya menulis ini? Anda mengatakan bahwa Anda ingin "meyakinkan rekan setim, yang menganggap diri Anda sebagai senior, untuk mendapatkan pemahaman yang lebih baik tentang dasar-dasar SVN". Bagi saya itu terdengar seperti konflik mungkin menjadi terlalu pribadi. Beberapa psikolog berpendapat bahwa 70% dari komunikasi kita berada pada level emosional, jika level ini tidak berfungsi, maka orang-orang berhenti berbicara tentang fakta karena mereka terlalu sibuk berurusan dengan emosi.
Jadi, selain menjelaskan poin Anda, Anda juga bisa mencoba melakukan sesuatu untuk meningkatkan komunikasi. Mengundang kopi atau istirahat makan siang bersama, berbincang-bincang singkat tentang topik yang tidak terkait dengan pekerjaan, dll., Dapat meningkatkan komunikasi dan mengembalikan perhatian rekan kerja Anda ke fakta - fakta penting yang Anda ingin dia pahami. Jika dia menerima komunikasi semacam ini, maka mungkin konflik yang Anda miliki sejauh ini terkait dengan fakta bahwa Anda tidak mengenal satu sama lain dengan baik dan ada beberapa kesalahpahaman kecil tetapi dia mungkin terbuka untuk membangun kolaborasi yang konstruktif. Jika dia menolak, maka mungkin ada permusuhan yang lebih dalam di sisinya.
Dalam hal ini, saya pikir Anda harus menunggu sampai peran Anda menjadi lebih jelas. Jika rekan setim Anda tidak secara resmi memiliki peringkat lebih tinggi dari peringkat Anda, ia tidak perlu merasa kesal dengan upaya Anda untuk memperbaiki keadaan. Seiring waktu ia harus menerimanya atau membodohi dirinya sendiri jika terus berusaha menunjukkan bahwa ia lebih tahu. Jika dia memang memiliki peringkat yang lebih tinggi, Anda harus menemukan cara untuk membuatnya mengerti bahwa ini tidak sedang dibahas: pengamatan Anda ditujukan untuk meningkatkan produktivitas dan tidak merusak posisinya, ini harus 100% jelas. Ketika peran telah diklarifikasi, jika dia masih tidak dapat menerima saran atau kritik yang membangun, maka dia benar-benar harus memiliki beberapa masalah dengan harga diri atau sesuatu seperti itu.
Jadi, jika semua strategi di atas gagal dan Anda terus merasa frustrasi, saya khawatir satu-satunya hal yang masuk akal untuk dilakukan adalah mengepak barang-barang Anda dan mencari tempat yang lebih baik. Saya membuat pengalaman ini tiga tahun lalu dan menemukan perusahaan yang jauh lebih baik di mana saya sangat puas sekarang. Mungkin ini bukan kasus Anda (saya harap tidak tentu saja) tetapi cobalah untuk memahami hal ini juga.
Hanya 2 sen saya.