Bagaimana saya bisa meyakinkan programmer koboi untuk menggunakan kontrol sumber?


62

PEMBARUAN
Saya bekerja pada tim kecil devs, 4 orang. Mereka semua menggunakan kontrol sumber. Sebagian besar dari mereka tidak tahan dengan kontrol sumber dan malah memilih untuk tidak menggunakannya. Saya sangat percaya kontrol sumber adalah bagian penting dari pengembangan profesional. Beberapa masalah membuatnya sangat sulit untuk meyakinkan mereka untuk menggunakan kontrol sumber:

  • Tim tidak terbiasa menggunakan TFS . Saya sudah memiliki 2 sesi pelatihan, tetapi hanya diberikan 1 jam yang tidak cukup.
  • Anggota tim langsung memodifikasi kode di server. Ini menjaga kode tidak sinkron. Membutuhkan perbandingan hanya untuk memastikan Anda bekerja dengan kode terbaru. Dan masalah gabungan yang kompleks muncul
  • Perkiraan waktu yang ditawarkan oleh pengembang mengecualikan waktu yang diperlukan untuk memperbaiki semua masalah ini. Jadi, jika saya katakan nono akan memakan waktu 10x lebih lama ... Saya harus terus-menerus menjelaskan masalah ini dan mengambil risiko sendiri karena sekarang manajemen mungkin menganggap saya "lambat".
  • File fisik di server berbeda dalam cara yang tidak diketahui lebih dari ~ 100 file. Penggabungan membutuhkan pengetahuan tentang proyek yang ada dan, oleh karena itu, kerja sama pengembang yang tidak dapat saya peroleh.
  • Proyek lain tidak sinkron. Pengembang terus memiliki ketidakpercayaan terhadap kontrol sumber dan karenanya menambah masalah dengan tidak menggunakan kontrol sumber.
  • Pengembang berpendapat bahwa menggunakan kontrol sumber boros karena penggabungan cenderung kesalahan dan sulit. Ini adalah poin yang sulit untuk diperdebatkan, karena ketika kontrol sumber sedang sangat salah digunakan dan kontrol sumber terus menerus dilewati, itu memang rawan kesalahan. Karena itu, bukti "berbicara untuk dirinya sendiri" dalam pandangan mereka.
  • Pengembang berpendapat bahwa secara langsung memodifikasi kode server, melewati TFS menghemat waktu. Ini juga sulit untuk diperdebatkan. Karena penggabungan yang diperlukan untuk menyinkronkan kode untuk memulai adalah memakan waktu. Lipat gandakan ini dengan 10+ proyek yang kami kelola.
  • File permanen sering disimpan dalam direktori yang sama dengan proyek web. Jadi penerbitan (publikasi penuh) menghapus file-file ini yang tidak dalam kendali sumber. Ini juga mendorong ketidakpercayaan untuk kontrol sumber. Karena "penerbitan merusak proyek". Memperbaiki ini (memindahkan file yang disimpan keluar dari subfolder solusi) membutuhkan banyak waktu dan debugging karena lokasi ini tidak diatur di web.config dan sering ada di beberapa titik kode.

Jadi, budaya itu tetap ada. Praktik buruk menghasilkan lebih banyak praktik buruk. Solusi buruk mendorong peretasan baru untuk "memperbaiki" masalah yang jauh lebih dalam, lebih memakan waktu. Server, ruang hard drive sangat sulit didapat. Namun, ekspektasi pengguna meningkat.

Apa yang bisa dilakukan dalam situasi ini?


24
Bagian penting dari info yang hilang: Apa peran Anda dalam tim?
Moron

116
Apakah hidup ini cukup lama untuk menghabiskan bertahun-tahun untuk bekerja di tempat seperti itu? Anda memiliki tim rekan kerja yang tidak ingin bekerja secara kompeten dan profesional, dan manajemen yang tidak peduli. Anda bisa melakukan yang lebih baik.
Carson63000

8
Tentang tidak digunakan untuk kontrol sumber: jika ini adalah proyek dunia nyata, saatnya untuk terbiasa dengan kontrol sumber.
compman

14
Ubah tempat kerja Anda, atau ubah tempat kerja Anda. Apa pun keputusan Anda, jangan ragu.
Goran Jovic

11
Gagasan pengembang yang sebelumnya menggunakan kontrol sumber dan tidak menyukainya hampir di luar pemahaman saya. Mungkin mereka salah menggunakannya?
jhocking

Jawaban:


92

Ini bukan masalah pelatihan, ini masalah faktor manusia. Mereka tidak mau, dan menciptakan blok jalan. Berurusan dengan dinamika kelompok yang terpecah, apa penyebab utama keberatan mereka - biasanya ketakutan, apakah hanya takut akan perubahan, atau lebih menakutkan.

Tidak ada pengembang profesional hari ini, atau selama 20 tahun terakhir, yang menolak kontrol sumber. Suatu ketika, sekitar 30 atau 40 tahun yang lalu, ketika komputer lambat, kontrol sumber bahkan lebih lambat dan program terdiri dari satu file 500 baris, itu menyakitkan dan ada alasan yang sah untuk tidak menggunakannya. Keberatan ini hanya bisa datang dari jenis koboi terburuk yang bisa saya pikirkan.

Apakah sistem memaksa mereka membuat hidup mereka sulit dalam beberapa cara? Cari tahu apa itu, dan ubah sistem untuk membatalkan keberatan. Ulangi sampai selesai.

Saya sarankan melihat GIT atau Mercurial. Anda dapat membuat repositori di setiap pohon kode sumber, mereka bahkan tidak akan melihat dan dapat terus meretas seperti yang mereka lakukan sekarang. Anda dapat melacak perubahan yang telah mereka retas ke dalam basis kode, membuat komitmen, menggabungkannya ke pohon sumber lain, dll. Ketika mereka melihat Anda melakukan upaya gabungan selama beberapa minggu ke dalam produk lain dalam hitungan detik, mereka mungkin mengubah gagasan mereka. Ketika Anda memutar kembali salah satu sekrup mereka dengan satu perintah, dan menyimpan pantat mereka, mereka bahkan mungkin akan berterima kasih (jangan mengandalkannya). Paling buruk, Anda terlihat baik di depan bos dan, untuk bonus, membuat mereka terlihat seperti para koboi.

Penggabungan tidak hanya akan membutuhkan pengetahuan besar tentang proyek

Dalam hal ini, saya khawatir Anda sudah sampai di sungai pepatah tanpa dayung. Jika penggabungan bukan opsi, tidak juga mengimplementasikannya, jadi Anda mengatakan bahwa Anda tidak bisa lagi menambahkan fitur yang sudah Anda miliki di satu cabang (istilah digunakan secara longgar) ke yang lain.

Jika saya jadi Anda, saya akan mempertimbangkan kembali prospek karir saya ...


13
-1, "Tidak ada pengembang profesional hari ini, atau selama 20 tahun terakhir, telah menolak kontrol sumber." - Omong kosong total, dan benar-benar dogmatis. Saya menduga Anda mendefinisikan 'profesional' sebagai 'seseorang yang berkembang seperti Anda'.
GrandmasterB

68
@Grandmaster: Apakah Anda mengatakan bahwa itu dapat diterima bagi seorang programmer untuk tidak menggunakan kontrol kode sumber, atau apakah Anda keberatan karena saya terlalu dogmatis? Dari semua hal yang dapat saya pikirkan yang tidak terbuka untuk negosiasi pada 2011, kendali sumber akan berada di bagian atas daftar saya. Tampaknya 27 orang lainnya setuju dengan saya. DVD dibakar dengan setiap rilis, atau salinan pohon sumber ke folder dengan tanggal bisa dibilang kontrol sumber.
mattnz

8
Saya mengatakan pernyataan bahwa semua profesional menggunakan kontrol sumber terbukti salah . Saya tahu banyak yang tidak, beberapa yang telah 'menolak' itu. Kontrol sumber adalah alat, seperti IDE. Profesional menggunakan alat yang menurut mereka paling cocok untuk pekerjaan itu. Jika mereka ingin menggunakan kontrol sumber, bagus untuk mereka. Jika tidak, itu hak prerogatif mereka. Anda mengklaim bahwa 'tidak terbuka untuk negosiasi' tidak relevan - saya tidak tahu Anda ditunjuk sebagai penentu tunggal dan final tentang bagaimana orang harus menulis perangkat lunak. Secara pribadi, saya tidak terlalu sombong untuk berasumsi bahwa saya tahu lebih baik untuk semua orang.
GrandmasterB

39
@GrandmasterB - Seseorang dapat membantah apa pun dengan anggapan bahwa kami menerima bukti anekdotal. Tentu saja 100% pengembang tidak menggunakan kontrol sumber. Tentu saja, ada kasus atau beberapa% dari kasus tepi yang sukses. Praktik terbaik adalah menggunakan kontrol sumber. Aman untuk mengasumsikan bahwa setiap pengembang yang mengatakan mereka bekerja di tim yang tidak memerlukan kontrol sumber adalah seorang koboi. Bukan berarti koboi tidak dapat membuat kode, karena sebenarnya mereka bisa dan seringkali sangat baik. Mereka biasanya tidak bisa bekerja dengan orang lain yang juga bisa.
P.Brian.Mackey

4
@MattThrower: Bahkan jika seorang pengembang bekerja sendiri, saya masih menyarankan SVN lokal. Jujur saja, satu-satunya argumen "meyakinkan" (yaitu, saya yakin bahwa orang yang mengambil keputusan melakukan hal itu dari posisi pengetahuan) yang pernah saya dengar menentang kontrol sumber adalah ini: "Kami dilarang membiarkan keberadaan sejarah salinan kode kami, bahkan jika salinan saat ini suatu hari nanti mungkin rusak, menyebabkan kami kehilangan semua pekerjaan kami. " Saya tidak suka argumen itu, tapi saya pernah mendengarnya kadang terjadi dengan pekerjaan rahasia pemerintah.
Brian

31

Terkadang, masalah dunia nyata membuatnya tidak praktis untuk digunakan.

Salah.

Jika tim tidak terbiasa menggunakan kontrol sumber, masalah pelatihan dapat muncul

Itu tidak ada hubungannya dengan kontrol kode sumber dan semuanya berkaitan dengan pelatihan. Pelatihannya mudah, murah, efisien dan dilakukan dalam hitungan jam. Gagal menggunakan kontrol kode sumber mahal, berisiko, tidak efisien, dan masalah tetap ada selamanya .

Jika anggota tim memodifikasi kode secara langsung di server, berbagai masalah dapat muncul.

Itu masalah pelatihan. Lagi. Tidak ada hubungannya dengan kontrol kode sumber dan semuanya terkait dengan pelatihan.

Pengembang terus memiliki ketidakpercayaan terhadap kontrol sumber dan karenanya menambah masalah dengan tidak menggunakan kontrol sumber

Mereka perlu dilatih tentang cara menggunakan kontrol kode sumber. Ini mengurangi biaya, mengurangi risiko, menyederhanakan hal-hal dan lebih efisien. Ini adalah investasi satu kali yang membayar dividen setiap saat.

Apa yang bisa dilakukan dalam situasi seperti ini?

Mulai latih semua orang tentang cara menggunakan kontrol kode sumber.

Memperbarui

Pengembang berpendapat bahwa memodifikasi kontrol sumber secara langsung menghemat waktu.

Karena mereka salah, penting untuk mengumpulkan data untuk menunjukkan dengan tepat betapa salahnya ini.

Sayangnya, bagaimanapun, manajemen tampaknya menghargai tanggapan langsung yang mahal dalam jangka panjang.

Satu-satunya cara untuk mengatasi sistem imbalan ini adalah dengan

A) Identifikasi bahwa biaya jangka panjang lebih tinggi dari nilai jangka pendek yang tampak.

B) Identifikasi imbalan aktual yang sebenarnya ada di tempat yang membuat korupsi jangka pendek (yaitu, perubahan langsung) tampak lebih berharga daripada kontrol kode sumber jangka panjang yang benar. Siapa yang menepuk kepalanya karena melakukan hal yang salah? Apa jenis tepukan di kepala yang mereka dapatkan? Siapa yang memberikannya? Untuk memperbaiki hal-hal, Anda harus menyebutkan hal-hal yang salah dan manajer spesifik yang mendorong orang.

C) Rekomendasikan sistem hadiah yang direvisi yang menghargai nilai jangka panjang dan bukan respons cepat jangka pendek. Tepukan yang berbeda di kepala untuk alasan yang berbeda.

D) Latih orang-orang dalam hadiah yang Anda temukan untuk nilai jangka panjang; nilai yang jelas lebih besar dari respons cepat jangka pendek.


Saya sudah menyarankan pelatihan. Lebih dari sekali, berkali-kali. Kami memiliki sesi pelatihan, dua atau tiga, tetapi gagal. Saya hanya diberi ~ 1 jam untuk melatih mereka dalam SEMUA TFS. Dan tindak lanjutnya buruk. Saya sudah diberi yang lama "ikuti wortel", pelatihan akan datang ... tetapi tidak ada yang terjadi. Saya mencoba untuk mendorong masalah ini, tetapi setelah banyak upaya saya mulai merasa seperti orang jahat hanya karena saya orang aneh di sini. Saya sudah memberi tahu mereka apa yang salah, tetapi mereka hanya tidak setuju. Manajemen mengatakan "ya gunakan TFS", tetapi penegakannya adalah 0.
P.Brian.Mackey

3
"mereka gagal". Salah. Mereka dirusak oleh sistem penghargaan yang menghargai perilaku buruk. Diperlukan lebih banyak pelatihan. Hanya saja, pelatihan perlu memperbaiki sistem penghargaan, tidak hanya menjelaskan bagaimana mengarahkan dan mengklik alat tersebut.
S.Lott

1
@ P.Brian.Mackey: "Kami memiliki sesi pelatihan, dua atau tiga". Harap perbarui pertanyaan Anda untuk memuat keseluruhan cerita. Pastikan uraian Anda lengkap dalam pertanyaan. Jangan memperkenalkan fakta baru dalam komentar pada jawaban tertentu.
S.Lott

1
Ok, obsesi terhadap pelatihan itu salah - ini masalah manajemen / kebijakan / lingkungan di mana pelatihan merupakan aspek tetapi semua pelatihan di dunia tidak ada gunanya jika mereka dapat mengabaikannya sedangkan mereka akan belajar (tenggelam atau berenang) terlepas dari pelatihan jika mereka tidak dapat melakukan hal lain.
Murph

6
Salah satu teman sekelas saya dari kelas VLSI membuat transistor beberapa nano-meter lebar dan beberapa mil (ya mil!) Panjang yang sesuai dengan spesifikasi. Jawabannya kepada saya adalah "Yang saya tahu adalah omong kosong saya bekerja." Saya memiliki lebih banyak toleransi untuk orang-orang di perguruan tinggi. Sekarang saya akan benci untuk berakhir dengan seseorang seperti itu di tim saya. Saya percaya bahwa beberapa tim harus dilatih, dan beberapa harus dilambaikan selamat tinggal kepada. Hidup ini terlalu singkat untuk membenci pekerjaan / kolega seseorang.
Pekerjaan

17

Pengembang yang menolak untuk menggunakan kontrol sumber / versi harus dipecat, sesederhana itu. Seperti yang telah Anda tunjukkan, risiko dan biaya yang melekat dari TIDAK menggunakannya melebihi biaya overhead yang dikeluarkan oleh banyak, banyak pesanan besar. Siapa pun yang berusaha menentang hal ini seharusnya tidak terlibat dalam pengembangan perangkat lunak dan saya akan menolak untuk bekerja dengan orang-orang seperti itu.


10

Kami memecahkan masalah dengan terlebih dahulu, menyiapkan server integrasi berkelanjutan untuk membangun kontrol sumber kami menjadi dev. Kedua, kunci akses folder hanya untuk membaca, untuk mencegah orang menghindari kontrol sumber dan memodifikasi file secara langsung.

Ini adalah PITA pada hari-hari di mana Anda tidak dapat mereproduksi bug secara lokal, tetapi selain itu lebih baik untuk dapat bekerja, checkin, dan melanjutkan, mengetahui bahwa itu akan didorong ke dev secara otomatis oleh server CI.


Saran bagus, sebenarnya bagus. Tapi, manajemen memberi saya lampu merah pada CI. Tidak ada dana untuk VM atau server fisik. Tidak ada waktu yang dialokasikan untuk pengaturan.
P.Brian.Mackey

7
Dana untuk server CI? Itu mendanai sendiri. Tunjukkan berapa lama untuk melakukan penyebaran manual dengan video jika perlu. Kemudian jelaskan ini dilakukan beberapa kali per hari. Kali beberapa pengembang. Dan itu harus membayar sendiri dalam waktu yang dihemat dalam sebulan.
CaffGeek

6
Sial, jalankan Jenkins di mesin Anda sendiri kalau begitu.
Matthew Flynn

5
+1 untuk mengunci struktur folder. Ambil izin server mereka dari mereka dan mereka HARUS mengikuti rute yang benar (melalui kontrol sumber)
Mauro

8

Saya mendengar rasa sakit Anda. Saya telah berjalan ke beberapa tempat kerja untuk mencari tahu di sana 'kontrol sumber' adalah folder bersama di drive jaringan. Masalahnya umumnya bukan karena mereka percaya ada pendekatan yang lebih unggul daripada yang lain, itu hanya bekerja dan mereka belum pernah diperkenalkan ke alur kerja yang berhasil mengintegrasikan kontrol sumber.

Dengan struktur tim bumi datar Anda telah menjelaskan mendorong perubahan dari atas ke bawah mungkin bukan cara terbaik untuk mendekati situasi. Salah satu metode yang patut dicoba adalah dengan membeli langsung dari satu atau dua pengembang lain untuk memungkinkan konsep mengumpulkan momentum. Begitu Anda memiliki satu pengembang lain di dalamnya, akan lebih mudah untuk menyebarkannya ke anggota tim lainnya. Perlahan perkenalkan mereka dengan konsep tersebut, katakan mulai bekerja pada proyek sampingan kecil, bangun dan masuk Git , atau bahkan cabut sesuatu yang di-host di GitHub .

Mulai dari yang sederhana, perkenalkan konsep secara perlahan dan terpisah dari alur kerja mereka sehari-hari. Manusia hebat dalam mempelajari berbagai hal dan beradaptasi terhadap perubahan, terutama ketika perubahan itu memberikan manfaat langsung bagi mereka (pikirkan evolusi). Namun, ketika disajikan dengan sejumlah perubahan kecil sekaligus itu menjadi mengasingkan. Setelah mereka memahami cara kerja kontrol sumber dan keuntungan yang diberikannya, cobalah mengintegrasikannya di salah satu proyek internal Anda (jika Anda memulai proyek baru, ini adalah waktu yang jahat untuk memperkenalkannya). Biarkan proyek lain berfungsi dengan cara yang ada jika Anda suka juga, ini akan sangat efektif dalam menyoroti keuntungan dari kontrol kode yang layak.

Jika gagal, jalankan.


Saya juga berpikir bahwa ketika pengembang puas karena terjebak di belakang zaman, mereka biasanya mengikuti aksioma "jika tidak rusak, jangan memperbaikinya". Sebagian besar tempat saya bekerja memiliki mentalitas koboi yang sama, karena 1. karena ada kesenjangan literasi komputer yang besar antara pengembang dan manajer mereka atau 2. ada begitu sedikit pengembang sehingga tidak ada hierarki keterampilan, atau karyawan Sr di perusahaan mereka benar-benar berarti "Saya bekerja 10 tahun melakukan hal yang sama seperti yang saya lakukan pada yang pertama".
Chris C

2
Folder jaringan bersama dengan salinan bayangan adalah bentuk kontrol versi. Bentuk yang sangat buruk untuk memastikan, tetapi itu adalah salah satu.
Joeri Sebrechts

4
Saya selalu bertanya sistem kontrol kode sumber apa yang digunakan saat wawancara. Ketika CTO dari satu perusahaan berkata "Apa itu" saya lari.
Zachary K

6

Anda jelas memiliki keterampilan teknis untuk mengidentifikasi dan memperbaiki situasi Anda, masalah Anda adalah manusia dan terkait proses.

Orang-orang cenderung merespons jauh lebih baik daripada contoh visi, jadi saya akan menyarankan "memperbaiki" sendiri:

Ambil salinan sumber terbaru, susun ulang untuk menjadi ramah kontrol versi, buat proyek baru dengan struktur yang berguna dan berwawasan ke depan (cari tahu bagaimana Anda akan menangani cabang, tempat Anda meletakkan dependensi pihak ketiga, dll.). Anda mungkin harus melakukan itu di waktu Anda sendiri.

Kemudian seret rekan kerja dan manajemen Anda ke sebuah ruangan dan tunjukkan pada mereka seperti apa pengembangan perangkat lunak di abad ke-21. Ilustrasikan kegagalan dengan sistem Anda saat ini dan tunjukkan bagaimana mereka dihilangkan dengan struktur baru Anda.

Anda juga harus menjadikan diri Anda sebagai Penjaga Sumber - karena Anda tampaknya menjadi satu-satunya yang peduli, terserah pada Anda untuk memaksa orang (dengan cara teknis atau psikologis apa pun yang Anda inginkan) untuk tetap berpegang pada rencana. Pastikan bahwa satu - satunya hal yang pergi ke pelanggan berasal dari mesin build di luar kendali sumber. Ritually mempermalukan orang-orang yang melanggar aturan dan menyebabkan kekacauan. Suap mereka dengan donat ... apa pun yang berhasil.

Jika itu semua sepertinya terlalu banyak usaha maka (seperti yang telah dikatakan dalam setiap jawaban lainnya) - dapatkan pekerjaan lain. Mereka tidak sepadan dengan waktumu.


lol, saran bagus. Sebagian besar sudah dilakukan. Manajer berkata "ya kita harus menggunakan kontrol sumber". Tapi, tim tidak menggunakan kontrol sumber. Saya memberi tahu manajer dan mgr hanya mengatakan "ya kita perlu menggunakannya". Tidak ada yang dimarahi. Tidak ada penegakan.
P.Brian.Mackey

3
@ P.Brian.Mackey - Terkadang Anda hanya perlu melakukan semua BOFH . Suatu kali saya pergi berlibur dan seorang kontraktor yang bekerja untuk saya menghabiskan seluruh minggu menjelajahi situs-situs kencan. Ketika saya kembali dan menemukan ini, komputernya mengembangkan masalah akses TCP / IP yang tidak dapat dijelaskan yang tidak dapat saya perbaiki. Mintalah atasan Anda mengambil hak mereka untuk meretas langsung di server dan memaksa mereka untuk pergi melalui TFS untuk ditempatkan dan mereka akan segera membersihkan tindakan mereka atau berhenti, dengan cara apa pun Anda menang.
Mark Booth

Gagasan Penjaga Sumber itu bagus. Anda mungkin meminta mereka mengirimkan perubahan kepada Anda - atau setidaknya memberi tahu Anda bahwa mereka membuat beberapa dan memperbarui repo Anda dari diff dengan prod. Atau jalankan fswatchdan minta komit pada repo ketika file berubah.
Joe McMahon

4

Langkah 1 - memecat manajer yang tidak kompeten!

Jika Anda tidak dapat melakukan langkah 1, cobalah membuat manajer membatasi penyebaran untuk mendukung hanya skrip yang diambil dari kontrol sumber. Jika pengembang (yang seharusnya tidak memiliki hak produksi pada prod, lihat langkah 1 jika mereka mau) ingin barang-barang mereka digunakan harus berasal dari kontrol sumber. Itu memecahkan masalah kami tentang tidak menggunakan kontrol sumber dengan sangat baik ketika kami pertama kali menggunakannya untuk hal-hal basis data serta kode C #.


4

Bagaimana mungkin seseorang tidak menginginkan versi berbeda dari file mereka dan kemampuan untuk melihat perbedaannya? Lupakan percabangan dan hal-hal rumit lainnya. Mereka bahkan tidak mendapatkan dasar-dasarnya. Secara langsung memodifikasi file produksi tanpa melakukan perubahan yang paling mendasar dalam lingkungan pengujian adalah gila. Saya telah bekerja dengan beberapa orang dan syukurlah kami tidak pernah bekerja di proyek yang sama.

Rekan kerja Anda terlalu bodoh untuk malas. Itu buang-buang waktu. Yang bisa Anda harapkan adalah melatih manajer Anda. Manajemen harus menyukai kontrol sumber karena mereka menyukai semua bentuk kontrol. Buat mereka merasa penting. Sekrup yang lain; Memperbaiki pemimpin adalah satu-satunya harapan Anda karena Anda tidak dapat menggantikannya. Mulai berjejaring dengan pengembang kompeten lainnya dan cobalah untuk mengajak mereka bergabung dengan tim Anda ketika Anda memiliki pembukaan atau minta mereka untuk mempekerjakan Anda di toko mereka.


3

Ini adalah contoh yang baik dari proyek di mana praktik-praktik buruk telah digunakan sedemikian luasnya sehingga praktis tidak mungkin untuk memperbaikinya. Memperbaikinya akan membutuhkan pembekuan, sehingga semuanya bisa dibersihkan tanpa gangguan. Sayangnya, proyek seperti itu biasanya (karena alasan yang jelas) terlalu buggy untuk dibekukan selama beberapa bulan, bug kritis harus diperbaiki setiap hari.

Anda mungkin tergoda untuk membayar proyek untuk membuat versi yang bersih sementara versi kotor diperlakukan dengan perbaikan bug harian; tetapi hasil yang paling mungkin adalah bahwa setelah beberapa bulan, ketika versi "bersih" selesai, tidak ada yang bisa memberi tahu Anda mana perbaikan bug dan perubahan yang digabungkan sejak garpu (karena pola pikir yang sama yang membuat orang tergelincir ke dalam praktik seperti itu membuatnya tidak mungkin bahwa mereka menyimpan catatan tentang perubahan yang mereka lakukan). Versi bersih sudah usang, versi kotor masih berfungsi, jadi apa yang terjadi? Versi bersih dibuang, naysays terbukti benar.


2

Selain yang sudah jelas Temukan pekerjaan baru, saya kira jawabannya lebih dari semuanya di atas.

Pertama pergi ke manajemen untuk membawa mereka ke papan dengan pindah ke dan menegakkan penggunaan kontrol sumber. Kemudian lakukan apa yang perlu dilakukan untuk menjaga hal-hal berjalan, bahkan jika itu berarti bekerja secara langsung di server. Mulai proses untuk mendapatkan semuanya dalam kendali sumber.

Pilihan lain adalah memastikan yang terbaru ada di server (yang harus Anda lakukan terlepas) dan memulai repositori baru sekaligus dari yang terbaru. Anda akan kehilangan sejarah, tetapi pada titik ini adalah kentang kecil.


2

Tampaknya dari uraian Anda bahwa ada satu atau lebih masalah dengan situasi tersebut - apakah tim pengembang tidak terkendali atau solusi kontrol sumber yang buruk telah diterapkan. Either way, adalah tugas tim dev untuk menggunakan beberapa solusi kontrol sumber - langsung memodifikasi kode sumber pada layanan produksi hanya memohon agar masalah terjadi.

Dari pengalaman saya, langkah pertama yang harus dilakukan segera adalah menyinkronkan kontrol sumber dengan server produksi. Langkah ini bisa sesederhana mengambil salinan kode produksi dan memeriksanya - kode prod mungkin merupakan basis yang dikembangkan tim Anda. Langkah ini mungkin perlu ditambah dengan penggabungan dengan kode yang mengambang di dalam sistem kontrol sumber yang ada. Kode harus mengalir dari dev ke integrasi / QA (atau keduanya), dan kemudian ke tahap atau tahap / produksi.

Selanjutnya, manajemen perlu mengamanatkan penggunaan kontrol sumber. Sederhananya, jika build tidak berasal dari sistem kontrol sumber, kode tidak boleh digunakan untuk produksi. Akses produksi perlu dibatasi hanya untuk tim pendukung saja, dengan akses terbatas diberikan kepada pengembang untuk memecahkan masalah produksi. Pengembang umumnya tidak boleh melakukan penyebaran kode panas ke produksi - masalah produksi pasti bisa terjadi, terutama jika pengembang berada di bawah tekanan.

Manajemen jelas perlu mendapatkan penanganan yang lebih baik tentang masalah-masalah di sini - hampir tidak mungkin untuk mempertahankan pengembangan jika kode diterapkan ke prod secara langsung (dan tidak masuk ke kontrol sumber).


1

Masalah sebenarnya bukanlah coders koboi tidak menggunakan kontrol versi. Masalah sebenarnya adalah bahwa mereka telah memilih beberapa cara untuk melakukan sesuatu, dan Anda mencoba mengubah proses mereka. Proses yang dipilih tidak termasuk kontrol versi. Semua perubahan proses sulit, kecuali jika programmer sendiri melihat adanya masalah. Jika ada perasaan bahwa sistem yang ada cukup baik, mencoba memaksakan beberapa sistem yang berbeda hanya sia-sia. Kami adalah borg, Anda akan berasimilasi. Tentu saja mereka berusaha berjuang menjadi borg.


1

Untuk kewarasan Anda sendiri, saya sarankan menyiapkan Git atau DVCS lain di mesin Anda sendiri sehingga Anda dapat melacak perubahan. Impor perubahan rekan kerja Anda ke dalam repositori Anda sesering mungkin. Selesaikan konflik sebaik mungkin. Ini sebagian akan melindungi Anda dari kegilaan rekan kerja Anda.

Anda telah menyebutkan bahwa manajemen telah mengatakan bahwa pengembang harus menggunakan kontrol sumber. Jika Anda ingin menjadi jahat, Anda bisa memberlakukan ini dengan memeriksa perubahan ke TFS dan menerbitkan repositori secara berkala, sehingga menghambat setiap perubahan yang tidak ada di TFS. (Jika Anda juga mempertahankan DVCS Anda sendiri, Anda harus tetap menyinkronkan keduanya.) Pembenaran Anda untuk melakukannya adalah Anda mengikuti perintah dari manajemen. Jika rekan kerja Anda bosan ditimpa perubahannya, undang mereka untuk menggunakan TFS. Dan tetap lakukan perubahan yang tidak diinginkan yang belum diperiksa. Lanjutkan sampai rekan kerja Anda mengalah atau Anda dipecat.


0

Kunci semua server selain dari pengembangannya. Gunakan manajer konfigurasi. Lakukan build yang dapat diidentifikasi secara teratur (terhadap tag). Tag setiap set perubahan (yaitu 1 set perubahan per bug). Kami juga memberi tag pada setiap bangunan. Memiliki sistem tipe QA antara dev dan produksi (minimal). Lakukan build ke sistem QA menggunakan tag build yang benar. Beri mereka kesedihan karena "menghancurkan bangunan".

Saya tidak pernah mengalami situasi di mana saya tidak dapat membuat kembali / memperbaiki masalah (yang hanya terlihat pada produksi). Ya, saya telah menghabiskan berjam-jam mendapatkan masalah untuk diciptakan kembali pada sistem pengembangan (ditambah ketika Anda mengetahuinya, Anda dapat menambahkannya ke tes regresi Anda).

Kami melakukan proyek dengan sekelompok kontraktor koboi yang melakukan semua hal buruk itu. Saya menghabiskan 4 minggu membersihkan setelah itu dan kemudian menempatkan praktik di atas. Proyek itu tidak memiliki masalah dengan hal-hal itu sejak saat itu.


-3

Mengutip:

Tim tidak terbiasa menggunakan TFS

TFS ternyata adalah Microsoft Team Foundation Server.

Insting pertama saya mengatakan: "ini adalah rilis terbaru dari Microsoft Visual SourceSafe"

Saya akan berada di sisi Anda rekan kerja dan benar-benar menentang ini.


1
Team Foundation Server adalah binatang yang sangat berbeda dari SourceSafe. Perbandingannya tidak adil.
pap

Inti dari argumen saya hampir tidak ada hubungannya dengan TFS. Masalah mendasar adalah kurangnya historis menggunakan kontrol sumber apa pun.
P.Brian.Mackey

Apakah mereka tahu itu berbeda? Saya tidak melakukannya.
Niels Basjes

@Hiels Basjes - Apakah mereka tahu apa yang berbeda?
P.Brian.Mackey

TFS berbeda dari Source Safe.
Niels Basjes
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.