Apakah tidak biasa bagi perusahaan kecil (15 pengembang) untuk tidak menggunakan kontrol sumber / versi terkelola? [Tutup]


152

Ini sebenarnya bukan pertanyaan teknis, tetapi ada beberapa pertanyaan lain di sini tentang kontrol sumber dan praktik terbaik.

Perusahaan tempat saya bekerja (yang akan tetap anonim) menggunakan berbagi jaringan untuk meng-host kode sumber dan kode yang dirilis. Merupakan tanggung jawab pengembang atau manajer untuk memindahkan kode sumber secara manual ke folder yang benar tergantung pada apakah kode itu dirilis dan versi apa dan sebagainya. Kami memiliki berbagai spreadsheet yang tersebar di sekitar tempat kami merekam nama dan versi file dan apa yang berubah, dan beberapa tim juga menempatkan detail berbagai versi di bagian atas setiap file. Setiap tim (2-3 tim) tampaknya melakukan ini secara berbeda di dalam perusahaan. Seperti yang dapat Anda bayangkan, ini adalah kekacauan yang terorganisir - terorganisir, karena "orang yang tepat" tahu di mana barang-barang mereka, tetapi berantakan karena semuanya berbeda dan itu bergantung pada orang yang mengingat apa yang harus dilakukan pada satu waktu.

Saya telah mencoba untuk mendorong semacam kontrol sumber yang dikelola untuk sementara waktu, tetapi saya sepertinya tidak mendapatkan cukup dukungan untuk itu di dalam perusahaan. Argumen utama saya adalah:

  • Kami saat ini rentan; pada titik mana pun seseorang bisa lupa untuk melakukan salah satu dari banyak tindakan rilis yang harus kita lakukan, yang bisa berarti seluruh versi tidak disimpan dengan benar. Mungkin perlu berjam-jam atau bahkan berhari-hari untuk menyatukan kembali satu versi jika perlu
  • Kami sedang mengembangkan fitur baru bersama dengan perbaikan bug, dan sering kali harus menunda rilis satu atau yang lain karena beberapa pekerjaan belum selesai. Kami juga harus memaksa pelanggan untuk mengambil versi yang menyertakan fitur baru bahkan jika mereka hanya ingin memperbaiki bug, karena hanya ada satu versi yang sedang kami semua kerjakan
  • Kami mengalami masalah dengan Visual Studio karena beberapa pengembang menggunakan proyek yang sama pada saat yang sama (bukan file yang sama, tetapi masih menyebabkan masalah)
  • Hanya ada 15 pengembang, tetapi kita semua melakukan hal yang berbeda; bukankah lebih baik untuk memiliki pendekatan standar seluruh perusahaan yang kita semua harus ikuti?

Pertanyaan saya adalah:

  1. Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?
  2. Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?
  3. Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Saya meminta terutama untuk merasakan mengapa saya memiliki begitu banyak perlawanan, jadi tolong jawab dengan jujur.

Saya akan memberikan jawaban kepada orang yang saya percaya telah mengambil pendekatan yang paling seimbang dan telah menjawab ketiga pertanyaan.

Terima kasih sebelumnya


3
Sepertinya mereka tidak jauh dari bekerja dengan DVCS seperti Mercurial. Orang-orang yang menyeret kaki mereka masih bisa "menggunakan" Mercurial jika folder yang ada benar-benar dijadikan repositori. Dari perspektif mereka itu akan terlihat hampir sama, dan Anda bisa melakukan perubahan jika tidak.
John Fisher

19
UPDATE (Hampir setahun setelah saya mengajukan pertanyaan ini): Selama tahun lalu, saya telah berkampanye dan membujuk dan memohon dan membujuk sampai saya sampai pada titik di mana saya hampir dipecat karena pembangkangan beberapa kali. Saya senang untuk mengatakan bahwa perusahaan yang dimaksud sekarang akhirnya mengambil perhatian serius pada kontrol sumber, dengan pandangan untuk menerapkan TFS setelah masa percobaan sebulan atau lebih sementara kami memastikan semua pengembang senang dengan proses baru. Sebagian besar respons positif yang saya dapatkan dari pertanyaan ini di programmer. SE yang memberi saya kepercayaan diri untuk mengejarnya. Tepuk tangan.
oliver-clare

10
Pengembang yang tidak menggunakan kontrol sumber sama dengan ahli bedah yang tidak mencuci tangan atau menggunakan peralatan kotor untuk beroperasi. Secara profesional tidak kompeten dan tidak ada alasan untuk malpraktik semacam itu.
Tim

1
Meskipun listrik telah ditemukan sejak lama dan meresap dalam kehidupan kita sehari-hari, beberapa orang masih memilih untuk bekerja di kode cahaya lilin menulis pada papan lilin menggunakan tongkat runcing.
Newtopian

2
15 devs bukan toko kecil.
Louis Kottmann

Jawaban:


108
  1. Ini mungkin tidak normal , tetapi seperti yang dikatakan Treb , itu mungkin tidak biasa
  2. Seperti yang orang lain katakan, tidak ada alasan yang sah untuk tidak memiliki kendali sumber di perusahaan Anda. Jadi, Anda perlu mengidentifikasi dan menyerang alasan yang tidak valid :

    a) yang utama adalah status quo : "jika tidak rusak, jangan memperbaikinya". Ini sulit: Anda bisa mulai menunjukkan semua hal yang tidak berfungsi sebaik yang seharusnya (yang dapat dengan cepat membuat Anda dicap sebagai 'orang negatif'), atau Anda hanya menunggu sesuatu meledak (yang mungkin tidak akan pernah terjadi), atau Anda bisa menekankan semua hal yang bisa salah. Sayangnya orang-orang yang bertanggung jawab perusahaan kecil relatif tahan terhadap 'hal-hal yang bisa salah' sampai mereka benar-benar lakukan salah ...

    b) ketidaktahuan / ketakutan / ketidakpastian : "kita tidak benar-benar mengerti apa itu kontrol sumber; kita tidak tahu bagaimana menggunakannya; kita tidak tahu alat mana yang harus dipilih; itu akan membuat gaya kita kram" . Ini adalah salah satu alasan saya pasti tidak akan mengirim mereka ke sini! Ini mungkin urutan yang cukup tinggi untuk Anda sendiri, tetapi saya pikir untuk memaksimalkan peluang Anda, Anda perlu menghadirkan solusi 'turn-key', dan tidak terlalu banyak varian atau alternatif. Anda memerlukan gagasan yang jelas tentang: bagaimana Anda ingin menyesuaikan / mengubah proses kerja Anda untuk bekerja dengan alat yang diberikan; bagaimana / jika Anda berencana untuk kembali-port kode yang ada; seberapa cepat Anda berpikir Anda dapat 'melatih' pengguna dan membuatnya beroperasi; bagaimana Anda dapat mengelola periode transisi (jika ada); berapa besar kemungkinan 'biaya' (dalam jam, jika tidak dalam dolar).

    c) mungkin ada alasan lain (misalnya pengalaman buruk dengan VSS sebelumnya, atau setelah membaca 'cerita horor' tentang alat yang diduga terlalu rumit), tetapi Anda harus memukulnya secara terpisah ketika Anda menemukannya.

  3. Ada banyak alasan untuk kontrol sumber yang diuraikan dalam jawaban lainnya. Saran saya adalah memilih 2 atau 3 utama yang benar - benar dapat membuat perbedaan bagi perusahaan Anda dan memoles mereka dan mempresentasikannya dalam rapat kepada sebanyak mungkin rekan kerja Anda. Cobalah untuk memprovokasi diskusi: bahkan jika Anda tidak segera meyakinkan mereka, Anda akan mendapatkan wawasan tentang apa poin yang mungkin muncul.

(Sudahkah Anda membaca / mendengar tentang Fungsi Perubahan ?)


2
Terima kasih atas perbedaan (sedih) yang diperlukan antara normal dan tidak biasa. +1
keppla

29
+1 untuk ketidaktahuan / fud. Jika Anda seorang pengembang perangkat lunak profesional, tidak menggunakan SCM, maka Anda tidak. Titik.
Chris Thornton

2
Hanya karena penasaran, siapa yang akan membayar $ 300 per orang untuk kontrol sumber (Valut, menurut tautan wiki Anda), ketika ada banyak aplikasi gratis?
Rob

11
pada poin 2: Saya tidak melihat alasan yang valid untuk tim dengan ukuran berapa pun (termasuk tim 1) untuk tidak menggunakan kontrol Sumber ...?
James Khoury

1
Alasan lain bahwa beberapa kelompok kecil tidak memiliki kontrol versi - ada beberapa biaya tambahan dan pembelajaran yang terlibat dalam pengaturannya. Anda memerlukan server untuk meng-host basis kode. Anda perlu mengelola server dan perangkat lunak VC di server itu. Anda perlu membuat cadangan basis data VC, membuat dan menguji rencana pemulihan dan memantau cadangan untuk memastikan bahwa cadangan / pemulihan masih valid. Semua administrasi ini membutuhkan waktu. Dalam organisasi dengan manajemen perangkat lunak yang buruk, waktu yang dihabiskan pengembang untuk mengelola sistem VC dapat dihukum daripada dihargai.
Jay Elston

185

Sama sekali tidak normal bagi kelompok yang ukurannya dapat bekerja tanpa kontrol sumber — ukuran kelompok programmer terbesar yang dapat bekerja secara efektif tanpa kontrol sumber kurang dari atau sama dengan satu. Benar- benar tidak dapat dimaafkan untuk bekerja tanpa kontrol versi untuk tim profesional dalam ukuran apa pun , dan mungkin saya tidak merasa kreatif, tetapi saya tidak dapat mengemukakan alasan mengapa Anda ingin melupakannya.

Kontrol versi hanyalah alat lain — yang sangat kuat, dan yang memberikan manfaat luar biasa relatif terhadap biaya minimalnya. Ini memberi Anda kekuatan untuk mengelola semua perubahan Anda dengan rapi, dengan semua jenis hal praktis lainnya seperti percabangan, penggabungan otomatis, penandaan, dan sebagainya. Jika Anda perlu membangun versi dari sekian versi yang lalu, Anda dapat memeriksa kode dari titik waktu dan hanya membangun tanpa harus melompat melalui lingkaran lain.

Lebih penting lagi, jika Anda perlu menulis perbaikan bug, Anda dapat menggabungkannya menjadi pembaruan tanpa harus menghadirkan fitur-fitur baru yang sedang Anda kerjakan — karena mereka ada di cabang lain, dan sejauh sisa pengembangan perlu dilakukan. khawatir, mereka belum ada.

Anda mengalami perlawanan karena Anda menantang budaya perusahaan. Akan butuh waktu bagi mereka untuk menyesuaikan, tidak peduli apa yang Anda katakan. Yang terbaik yang dapat Anda lakukan adalah terus mendorongnya, dan jika perusahaan benar-benar tidak mau bergerak, cari pekerjaan lain yang lebih cocok untuk level Anda sebagai pengembang.


45
Sayangnya, tidak dapat dimaafkan tidak sama dengan yang tidak biasa ...
Marjan Venema

6
Belum lagi ada penyedia kendali sumber GRATIS, jadi ini bukan tindakan yang mahal.
Mantorok

9
Ini bisa mahal sejauh membuat orang mengubah kebiasaan, alur kerja, dan prosedur mereka.
user1936

4
@Rook: Tentu saja. Tetapi saya lebih suka memiliki jaring pengaman yang tidak saya butuhkan daripada yang tidak saya miliki. Saya pemrograman jauh sebelum saya tahu apa itu sistem kontrol versi. Meskipun itu bukan keharusan, mencabut diri dari alat yang bagus itu bodoh.
Jon Purdy

12
Saya tidak bisa membayangkan berkembang tanpa kontrol sumber bahkan ketika saya satu - satunya pengembang.
webbiedave

34

Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?

Dalam pengalaman saya, ini bukan norma, tetapi tidak sepenuhnya tidak biasa seperti jawaban lain di sini. Mayoritas perusahaan kecil memang menggunakan kontrol sumber, tetapi sejumlah besar tidak, sayangnya.

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

Lihat pertanyaan ini di SO untuk diskusi yang bagus. Jawaban yang diterima mengatakan:
"Tidak ada alasan bagus untuk tidak menggunakan kontrol versi. Tidak ada."

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Konsensus di antara semua pengembang dan manajer proyek yang saya temui, dan tentu saja di sini di Programmer dan SO adalah bahwa kontrol sumber adalah suatu keharusan. Ini praktik terbaik yang diterima . Jika seseorang memutuskan untuk mengabaikannya, ia perlu memiliki beberapa argumen yang sangat kuat dan meyakinkan mengapa ini adalah keputusan yang tepat baginya (yaitu sedikit lebih dari 'kita tidak pernah membutuhkannya, jadi mengapa kita harus membutuhkannya di masa depan'). Argumen yang telah Anda sampaikan sejauh ini difokuskan pada isu-isu spesifik, mungkin Anda harus mencoba pendekatan yang lebih luas di sepanjang garis 'semua orang melakukannya, jadi mengapa kita tidak melakukannya juga?


"sejumlah besar tidak" ... hmm ... dengan 15 devs pada basis kode yang sama? Keberadaan saya, kami menambahkan SCC ketika kami ... 5 + 2 devs pada basis kode yang sama dan kami merasa itu tinggi waktu untuk itu. Saya yakin berharap bahwa 15 devs dan tidak ada SCC pada basis kode yang sama sangat tidak biasa :-)
Martin Ba

3
@ Martin: Bukan hal yang aneh untuk menemukan 15 orang yang semuanya menderita sindrom yang tidak ditemukan di sini ... Saya kira mungkin 5% dari semua perusahaan kecil (<20 karyawan) tidak memiliki kendali sumber. Saya harap untuk Anda bahwa pengalaman Anda berbeda dengan milik saya ;-)
Treb

+1 untuk yang tidak biasa, sayangnya.
Jonas

6
+1 untuk yang tidak biasa. Beberapa orang tidak mengerti bahwa manfaat dari kontrol kode sumber lebih besar daripada biayanya. Mereka takut biaya, dan berintegrasi dengan menyalin file atau tambalan ke ruang kerja gabungan "sentral" untuk "build"; sebagian besar karena itulah yang mereka pikir akan berhasil, dan tidak ada yang berinvestasi di lingkungan pengembangan. Biasanya ini karena persepsi bahwa mereka memiliki begitu banyak pekerjaan yang harus dilakukan pada kode, mereka tidak dapat membuang waktu pengembangan pada lingkungan. Saya menemukan waktu yang dihemat dengan lingkungan yang lebih efisien daripada membayar investasi pengembang yang mengerjakannya
Edwin Buck

27

Kontrol sumber baik untuk tim pengembang tunggal. Sistem kontrol sumber apa pun pada dasarnya adalah sistem kontrol versi yang melacak perubahan. Bayangkan satu pengembang, yang mungkin telah menghapus beberapa kode dan merasa bahwa kode itu sekarang diperlukan. Bisakah dia mendapatkan kode lama kembali?

Cukup gunakan alat yang membantu Anda. Ukurannya tidak masalah di mana-mana. Kualitas tidak masalah di mana-mana.


4
+1, saya saat ini satu tim pengembang dan saya menggunakan kontrol sumber. Saya bahkan menggunakan kontrol sumber di rumah untuk mengelola dokumen pribadi yang tidak terkait dengan pengembangan perangkat lunak, seperti resep memasak dan resume saya.
maple_shaft

1
+1, Banyak toko kecil mulai menggunakan file zip sebagai arsip mereka. Berpikir "Saya mungkin ingin kembali ke titik ini, jadi saya hanya akan membahas semuanya". Itu tidak sama, tidak sama sekali. Setelah Anda terbiasa dengan SCM, dan alat-alat hebat yang dibangun di atas (log, diff, menyalahkan, dll.), Anda tidak akan pernah kembali.
Chris Thornton

5
Penggunaan hebat lainnya untuk SCM: Saya datang pada hari Senin, bertanya-tanya apa yang saya kerjakan pada hari Jumat lalu. Saya hanya melakukan diff atau melihat log checkin terakhir, dan saya segera kembali ke zona tersebut.
Chris Thornton

1
Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?Ya, saya hanya menggunakan cadangan terakhir yang saya ambil dengan tangan, beberapa minggu yang lalu, dan saya mengambil cadangan kapan pun saya ingin melakukan perubahan besar. Belum gagal saya dalam beberapa tahun, dan tidak pernah membutuhkan (atau merasa seperti saya seharusnya menggunakan) kontrol sumber ...
Mehrdad

Saya adalah satu-satunya yang melakukan pengembangan di perusahaan kami (saya juga melakukan hal-hal IT), dan ketika saya mulai, saya tidak menggunakan kontrol sumber, tidak pernah ada bencana, tetapi saya akhirnya menyadari bagaimana kami berada di ujung tanduk. Saya menginstal Mercuarial sendiri sedikit kemudian, tanpa pernah menggunakannya sebelumnya dan dengan windows ui untuk itu, itu telah menjadi bantuan besar.
Tony Peterson

17

Sepertinya Anda sudah menggunakan sistem kontrol versi, tetapi tidak terlalu bagus. Orang-orang tampaknya sudah mengenali kontrol versi kebutuhan. Anda hanya perlu memperkenalkan mereka ke tingkat berikutnya - kontrol versi perangkat lunak.

Jika itu saya, saya akan memperkenalkan SCM sebagai versi perbaikan dari apa yang sudah mereka lakukan. Saya akan menekankan bagaimana menggunakan alat yang baik akan mengotomatisasi banyak pekerjaan yang sudah terjadi.

  • Alih-alih merekam perubahan dalam spreadsheet, sistem SCM melacak tidak hanya apa yang berubah, tetapi siapa yang mengubahnya dan mengapa.

  • Sebagai bonus, Anda dapat kembali ke titik mana pun dalam kehidupan kode dan melihat apa yang sebenarnya ada di sana.

  • Alih-alih memiliki versi kode yang berbeda di folder yang berbeda dan perlu memindahkan / menggabungkan berbagai hal di antara folder untuk melakukan perubahan, Anda dapat menyimpan semuanya di tempat yang sama, dan (yang lebih penting), biarkan alat melakukan penggabungan.

Seperti yang telah dikatakan orang lain, saya akan mengharapkan resistensi, jadi saya akan membuat prototipe sistem dengan menggunakannya pada hal-hal yang saya lakukan.

(BTW, saya benar-benar meletakkan resume saya dan dokumen lain di bawah SVN. Kemudian lagi, saya telah memainkan peran Manajer Konfigurasi dan Integrasi beberapa kali.)


9

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

  • Produk yang Anda kembangkan adalah sistem kontrol versi; manajer khawatir tentang mencegah produk yang ada dari mempengaruhi desain dan implementasi produk baru.

  • Antara akhir pekan DASAR melompat dan berlari dengan lembu jantan, para manajer yang mencari kesenangan menikmati mengemudi untuk bekerja sambil bertanya-tanya apakah semuanya sudah masuk neraka.

  • Menghindari pengambilalihan yang bermusuhan. Siapa yang ingin memperoleh pakaian pengembangan perangkat lunak yang dikelola dengan cara ini?

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

  • Anda sudah melakukan kontrol versi, tetapi saat ini Anda melakukannya dengan cara yang paling tidak efisien, paling padat karya, paling rentan kesalahan yang bisa dibayangkan. Menggunakan VCS akan menghemat uang, menghemat waktu, dan meningkatkan kualitas.

  • Menghemat ruang disk. Sebagian besar sistem kontrol versi hanya menyimpan delta di antara file. Saat ini, Anda menyimpan seluruh salinan dari setiap versi setiap file. (Mencadangkan semua salinan itu harus memakan banyak waktu dan ruang!)

  • Beberapa pengembang dapat mengerjakan file yang sama pada saat yang sama dan merekonsiliasi perbedaan tanpa terlalu banyak kesulitan. Menggabungkan perubahan tentu saja mungkin tanpa VCS, tetapi hampir tidak mungkin untuk melacak siapa yang mengubah apa, kapan, dan mengapa dalam kasus itu.

  • Memberi kebebasan pengembang untuk mencoba ide baru dengan mengetahui bahwa mereka dapat memulihkan versi apa pun kapan saja.

  • Proses yang lebih baik membuatnya lebih mudah untuk merekrut dan mempertahankan pengembang yang berbakat.


1
Pada poin dua, banyak VCS menyimpan delta, tetapi Git menyimpan seluruh file untuk setiap hash unik dari file tersebut. Tapi itu sebenarnya tidak masalah; ruang disk murah dan kode sumbernya kecil. gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
James

8

Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?

Jelas tidak. Ketika saya mulai di perusahaan saya saat ini, ada satu orang yang Anda harus mengirim kode Anda berubah, dan dia akan menggabungkannya. Saya bisa meyakinkan semua orang dalam beberapa hari untuk menggunakan SVN.

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

Saya pikir alasan Anda hanya mendengar alasan yang tidak jelas adalah karena tidak ada alasan yang sah untuk tidak menggunakan kontrol versi.

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Ya, ada banyak alasan.

  1. Bercabang memberi Anda kemungkinan untuk mengembangkan fungsionalitas baru tanpa mengganggu perkembangan lainnya.
  2. Setiap komit memberi Anda informasi tentang apa yang sebenarnya telah diubah, siapa yang melakukan perubahan itu, dan kapan perubahan itu dilakukan.
  3. Anda dapat dengan mudah melakukan perbaikan bug, dan menyebarkannya ke pelanggan, dan meninggalkan fungsionalitas baru yang belum selesai.
  4. Anda dapat mempertahankan versi yang berbeda, jika pelanggan takut pergi ke versi yang lebih baru.
  5. Anda dapat mengerjakan proyek yang sama (bahkan file sumber yang sama!) Dengan mudah.
  6. Anda dapat dengan mudah mengembalikan kesalahan, dengan mempertahankan perubahan setelah kesalahan yang dilakukan.

"Ada satu orang yang harus kamu kirim kode kembalianmu, dan dia akan menggabungkannya" - Kedengarannya tidak terlalu buruk. Banyak proyek opensource bekerja dengan cara ini. Anda mengirim tambalan ke pengelola. Tapi itu tidak akan skala ke tim besar jelas.
Alex Jasmin

6

Beberapa orang kesulitan menyadari betapa buruknya status quo sampai mereka melihat sesuatu yang lebih baik untuk diri mereka sendiri. Yang Anda butuhkan adalah demo yang bagus . Perlihatkan beberapa contoh tugas aktual yang dapat ditingkatkan. "Ini membutuhkan waktu 4 jam untuk melacak dengan sistem kami saat ini, tetapi perintah kendali sumber yang satu ini langsung memberi tahu saya."


Ini adalah sesuatu yang akan saya manfaatkan juga. Saya hanya membaca tentang manfaat kontrol sumber, tetapi tidak pernah mengalaminya sendiri. Saya telah mempertimbangkan untuk menyiapkan SVN di rumah (tetapi saat ini sedang mengerjakan rumah saya dan tidak punya banyak waktu ..!)
oliver-clare

5

Tidak menggunakan kontrol sumber meminta masalah, bahkan untuk pengembang solo. Fakta sederhana bahwa Anda dapat mengedit dengan kejam tanpa risiko kehilangan apa pun merupakan upaya pembelajaran dalam beberapa minggu atau hari.

Yang mengatakan, jika Anda tidak dapat meyakinkan manajer Anda untuk memperkenalkan kontrol sumber, bantulah diri Anda sendiri dan setidaknya gunakan sesuatu seperti git atau lincah secara lokal - jika ada masalah yang meledak karena kurangnya kontrol sumber, setidaknya Anda tidak akan menjadi yang terbaik. orang yang melakukannya.


4
ya, tidak ada alasan untuk tidak menggunakannya sendiri, lalu secara kebetulan menunjukkan kekuatannya kepada rekan kerja ketika dia paling tidak mengharapkannya.
gtrak

5

Perusahaan saya menggunakan GIT untuk kontrol versi. Perusahaan ini adalah satu pengembang, satu CEO, satu penjaga keamanan, satu wanita pembersih dan satu resepresionis. Mereka semua adalah aku. Kontrol versi sumber adalah HARUS setiap saat.



4

Kami berada di posisi yang sama dengan tim 6 orang beberapa tahun yang lalu. Salah satu pengembang mengambil langkah menginstal SVN pada server dev di mana folder bersama itu dan baru mulai menggunakannya.

Semua orang mengikutinya, dan tidak lama sebelum kami menerapkan CI ( CruiseControl ) dan merevolusi proses pembuatan dan pelepasan kami untuk menyertakan otomatisasi dan pemeriksaan kualitas.


4

WTF ?! Ini mungkin pertanyaan paling konyol yang pernah saya lihat. Anda perlu mencari pekerjaan baru. 15 pengembang ?! Anda pikir itu tim kecil? Ini gila. Manajer harus segera diberhentikan. Jujur, saya akan mengalami mimpi buruk setelah membaca pertanyaan ini. Tolong beritahu kami produk yang Anda jual sehingga kita semua tahu untuk tidak membelinya! Saya tidak tahu apa yang lebih menakutkan, pertanyaan ini, atau jawaban yang mengatakan ini tidak biasa!


3

Saya tidak bisa membayangkan bagaimana 15 pengembang dapat bekerja tanpa kontrol sumber. Namun, dari:

(...) menggunakan jaringan berbagi untuk meng-host kode sumbernya (...)

Saya berasumsi Anda telah membuat kontrol versi orang miskin Anda sendiri seperti VSS (juga didasarkan pada folder bersama). Berisiko dan tidak efisien.

Jelaskan kepada bos Anda betapa buruknya, berinvestasilah dalam beberapa pelatihan SVN atau GIT 2 hari, dan mulailah menggunakan sistem kontrol versi nyata saat Anda masih memiliki kode Anda dalam kondisi yang wajar.


2
Saya tidak yakin Anda perlu dua hari untuk belajar SVN. Dengan 15 pengembang, mereka tidak bisa semua "keluar dari sekolah." Pasti setengahnya pernah menggunakannya di suatu tempat sebelumnya.
Michael Blackburn

1
@MichaelBlackburn: Saya setuju. Saya tidak membuat diri saya jelas. Saya sedang memikirkan 2 hari untuk pelatihan dan pengaturan (pengaturan repo, kode impor, dll.)
Michał Šrajer

3

Jika saya tidak melakukan beberapa kali sehari, atau setidaknya sebelum saya meninggalkan rumah, saya merasa .. ada yang hilang, ada yang salah.

Saya pernah bekerja di sebuah perusahaan dengan hanya 2 pengembang (saya + admin berambut panjang), pada tahun 1998. Bahkan saat itu kami menggunakan svn. Sangat nyaman.

Beberapa kali dalam karir saya, saya kehilangan hari kerja karena saya melakukan sesuatu seperti mv bukannya cp dan kemudian rm-rf. Membuatku menangis dan berkeliaran di jalanan kota dengan putus asa.

Saya bekerja di 5 perusahaan selama 13 tahun saya berada di SE, berkunjung ke beberapa konferensi, dan tidak pernah menemukan perusahaan yang tidak menggunakan kontrol versi.

Namun, perusahaan desain interior favorit saya, 20 karyawan, menggunakan papan tulis untuk kolaborasi manajemen + proyek. Mereka tahu itu salah, tetapi sepertinya mereka tidak punya waktu untuk memutakhirkan. Entah bagaimana itu berhasil. Jangan tanya saya bagaimana.


1
svntidak ada pada tahun 1998.
Faheem Mitha

3

Jadilah pemimpin. Menjadi seorang pemimpin berarti melakukan apa yang benar; secara proaktif memecahkan masalah. Kepemimpinan tidak melakukan apa-apa karena tidak ada cukup konsensus. Dan seorang pemimpin yang baik belajar untuk mengenali situasi ketika seseorang harus membangun konsensus dan kapan melakukannya. Ini jelas merupakan situasi yang harus dikerjakan. Kurangnya kontrol kode AKAN meledak di wajah Anda cepat atau lambat.

Pemimpin sering tidak berada dalam posisi manajemen resmi. Orang akan mengikuti pemimpin yang baik dan tegas terlepas dari jabatannya.

Jika upaya tegas Anda terhempas, terutama jika itu dari manajemen maka itu pertanda jelas bagi Anda untuk keluar dari sana. Ini hambatan pada pengembangan profesional Anda; dan Pengembang yang kompeten dan manajemen yang tidak kompeten tidak bergaul, dan yang tidak kompeten dengan kekuasaan akan mengacaukan Anda.

OK, kilas baliknya sampai ke saya. Tanda tangan. Semoga berhasil.


Terima kasih sobat. Saya suka definisi pemimpin "melakukan hal yang benar", yang berbeda dari definisi manajer "melakukan hal yang benar". Yaitu manajer melakukan apa yang dia lakukan dengan cara yang benar, tetapi itu mungkin bukan hal yang benar untuk dilakukan. Pemimpin melakukan hal yang benar, tetapi seringkali membutuhkan manajer untuk melakukannya dengan benar. Pasti bernilai +1 :)
oliver-clare

2
  1. Dapatkan stopwatch,
    • Hitung waktu yang Anda habiskan di spreadsheet hanya untuk menyinkronkan versi
    • Hitung waktu yang Anda habiskan untuk memperbaiki versi yang rusak
    • hitung berapa kali orang berteriak di lorong " aku mengedit main.c !, hanya untuk memastikan tidak ada orang lain yang sekarang!" .
    • hitung jumlah keluhan yang Anda dapatkan dari pelanggan karena perbaikan bug mereka berisi perubahan lain
    • hitung waktu tunda rilis hanya karena Anda tidak dapat menyinkronkan versi
  2. Buat powerpoint dengan data ini, bandingkan dengan cara kerja vcs.
  3. Tampilkan manajemen

2

Ini hanya kecelakaan yang menunggu untuk terjadi. Anda tidak memiliki riwayat kode, dan dalam satu gerakan, salah satu pengembang Anda dapat menghapus pekerjaan berbulan-bulan. Sebagai perusahaan kecil Anda tidak mampu membayar kemunduran semacam ini.

Anda juga sangat terbuka pada drive share itu. Bahkan dengan cadangan yang bagus, berapa lama Anda mampu untuk tidak bekerja. 1 jam, 1 hari, 1 minggu. Berapa lama untuk mendapatkan server baru di tempat, memulihkan dari cadangan dll. Sekali lagi sebagai perusahaan kecil Anda mungkin tidak memiliki perangkat keras tambahan pada siaga dan mungkin tidak dapat dengan mudah menjatuhkan uang untuk mendapatkan pengiriman yang dipercepat dll.

Pikirkan juga tentang penyimpanan di luar kantor. Banjir atau kebakaran bukanlah hal yang aneh. Apa yang akan terjadi jika ada kebakaran di gedung setelah jam. Berapa bulan kerja akan hilang. Repositori kode terkelola seperti github akan sangat berharga untuk ini. Bahkan menggunakan server SVN sederhana pada layanan yang dihosting akan menjadi langkah maju dalam bidang ini.


2

LordScree, saya dalam kesulitan yang hampir sama dengan Anda, tim langsung saya adalah sekitar 15 pengembang. Saya tidak percaya (hampir ngeri) bahwa kontrol sumber tidak digunakan. Tanggapan awal saya untuk "kita harus menggunakan kontrol sumber" adalah "kita tidak punya waktu untuk mengimplementasikan". Bagi saya, seperti memakai pakaian dalam, kontrol sumber bukan opsional. Setelah beberapa bulan, saya juga memiliki persetujuan untuk mengimplementasikan TFS, dipilih oleh organisasi karena ini adalah MS dan dilengkapi dengan uji coba 90 hari. Intinya, sangat sulit untuk meyakinkan sebuah organisasi tentang perlunya kontrol sumber ketika mereka telah berjuang tanpa itu. Saya memberi tahu pengembang bahwa kapan pun Anda menemukan diri Anda mencadangkan file, terutama dengan tanggal di nama file atau direktori yang dicadangkan, adalah contoh ketika Anda meletakkan sesuatu di kontrol sumber. Saya tidak Saya tidak punya jawaban yang cemerlang untuk Anda, tetapi saya yakin ini tidak biasa. Saya sedang berjuang dalam pertempuran yang sama dan akan membuat Anda tetap pada kemajuan. Dan, semoga akan ada kemajuan kalau aku mencari di tempat lain karena aku tidak bisa bekerja dalam kekacauan!


Saya pikir argumen terkuat saya untuk kontrol sumber adalah untuk risiko bisnis tidak memilikinya. Rilis produk yang salah bisa menghabiskan waktu berjam-jam atau bahkan berhari-hari untuk memilah - belum lagi hubungan yang rusak dengan pelanggan. Ini adalah risiko nyata tanpa kontrol sumber yang dikelola karena jumlah langkah manual yang diperlukan untuk merilis perangkat lunak dan melacak hal-hal seperti versi untuk setiap pelanggan. Cobalah untuk membuat pendekatan Anda dari perspektif bisnis, karena manajer lebih cenderung mendengarkan argumen ini daripada sekadar 'orang lain menggunakannya, jadi kita seharusnya'.
oliver-clare

Faktor lain yang berkontribusi adalah bahwa akreditasi ISO 9001 di tempat kerja saya memandang rendah bisnis TI karena tidak memiliki kendali sumber. Akreditasi ini berguna untuk mengajukan tawaran untuk proyek-proyek baru dan kemitraan bisnis, karena itu adalah sesuatu yang sering dicari pada dokumen tender. Semoga berhasil dengan perjuangan Anda!
oliver-clare

1

kami memiliki 3 anggota staf pengembangan dan menggunakan kontrol sumber. Pada proyek pribadi saya, saya punya satu pengembang dan saya menggunakan kontrol sumber. Ini tidak hanya berguna untuk manajemen tim, ini berguna untuk dapat melakukan pekerjaan eksperimental tanpa takut Anda lakukan untuk menghancurkan sesuatu.

Cara termudah untuk meyakinkan manajemen? Ada sedikit risiko untuk keseluruhan produk, dan itu akan meningkatkan produktivitas pengembang dalam jangka panjang. Keduanya benar juga, dan keduanya menarik bagi para manajer.


1

Ini sama sekali bukan skenario normal dan saya pikir Anda harus berjuang keras untuk mendapatkan pengaturan ini di perusahaan Anda. Ini memiliki manfaat yang jauh dan tidak ada gunanya mewujudkan hal yang sama ketika Anda mendekati hari kiamat dan itu bukan situasi yang termasuk di dalamnya. Jika tidak rusak jangan memperbaikinya.

Alasan apa pun untuk tidak menerapkannya bisa jadi hanya alasan untuk pekerjaan yang buruk atau kesalahan besar yang menunggu untuk terjadi.

Beri tahu mereka betapa hebatnya menemukan aplikasi itu pada 1 Jan tahun ini

bagaimana kalau fungsi ini ditambahkan pada bulan Maret saya pikir kita perlu memperluas lebih lanjut tentang ini.

Wow bug ini 154256 telah diperbaiki dalam komit ini.

saya dapat membuka aplikasi dan mengirimkan penyebaran tidak masalah, Anda dapat terus bekerja.

Ini bisa terus-menerus ... (jangan lupa untuk menambahkan komentar tentang commit di lain waktu yang akan muncul sebagai pertanyaan lain)


1

Saya menggunakan kontrol versi untuk proyek satu orang dan proyek kerja saya, di mana kami memiliki lebih dari 30-40 orang yang mengerjakan kode yang sama sekaligus. Kontrol versi memiliki keunggulan organisasional, tetapi kemampuan untuk mengembalikan file dan menyimpan perubahan benar-benar dapat menghilangkan sakit kepala dari mengelola kode ... dan pada akhirnya itu adalah skenario terbaik untuk seorang programmer, sehingga mereka hanya dapat fokus pada pengkodean.


1

Alasan untuk mendukung tidak menggunakan kontrol versi cukup terbatas. Yang bisa saya pikirkan hanyalah aspek teknis dari banyak hal.

  • Ada terlalu banyak kurva belajar untuk mengubah alur kerja seluruh staf Anda untuk memasukkan sistem versi menjadi efektif biaya.
  • Manajer proyek Anda tidak merasa bahwa akan bermanfaat untuk memperkenalkan overhead ke dalam alur kerja mengelola dan memelihara repositori. (Terutama masalah dengan Sistem Versi yang lebih lama)

Ada banyak alasan untuk menggunakan sistem versi. Paling tidak berhenti bergerak di sekitar. Bekerja dengan tambalan. Sistem versi dapat melakukan persis apa yang Anda katakan Anda lakukan.

  • Anda dapat bekerja pada versi berikutnya pada saat yang sama Anda melakukan perbaikan bug dan melepaskannya secara terpisah.
  • Alih-alih memindahkan file dari satu lokasi ke lokasi lain untuk mengerjakannya, Anda dapat membuat cabang dan menggabungkannya ke master setelah selesai.
  • Setiap pengembang dapat memiliki salinan kode sumbernya sendiri untuk mencegah masalah dengan proyek yang sama terbuka di beberapa mesin.
  • Kecelakaan terjadi, jika kode menjadi sangat rusak semua yang perlu Anda lakukan kembalikan ke nomor revisi kerja terakhir.
  • Kontrol versi berfungsi dengan baik dipasangkan dengan pelacak bug dan sistem integrasi berkelanjutan.

Saya pribadi sebagai tim satu orang menggunakan versi, pelacakan bug, integrasi berkelanjutan, tinjauan kode, pengecekan konsistensi kode, pengujian unit, tes selenium, analisis kode sumber, dan mungkin ada lebih banyak lagi yang saya lupa. Saya akui, ada sedikit kurva belajar. Ada juga tradeoff waktu administrasi tambahan yang diperlukan untuk langkah-langkah tambahan yang Anda otomatisasi. Dalam pengalaman saya, upaya yang dihemat lebih besar daripada waktu administrasi tambahan.


1

Pada pekerjaan serius pertama saya pada tahun 1990 saya adalah satu-satunya pengembang yang bekerja di departemen saya dan tidak tahu untuk menggunakan kontrol sumber.

Tidak lama kemudian saya belajar, sejak saat itu saya belum pernah melihat proyek yang tidak menjadikannya salah satu hal pertama yang mereka buat.

Saya hampir kehilangan semua pekerjaan saya di pekerjaan itu karena saya menghapus folder pada level yang salah. Untungnya saya telah membawa pulang salinan pada disket 5 "minggu sebelumnya dan dapat membuat kembali minggu bekerja dalam beberapa hari yang panjang.

Jadi saya kira saya akan menganggap itu dapat diterima jika itu adalah proyek pertama untuk semua orang di tim dan tidak ada yang tahu lebih baik, tetapi jika bahkan satu orang benar-benar dapat menjelaskan manfaat dan tim masih tidak mendengarkan saya akan mengkategorikan ulang saya pendapat kelompok dari "naif" hingga "sangat tidak kompeten" (Perlawanan untuk menggunakan alat dengan manfaat yang ditunjukkan secara luas seperti itu hampir bersifat kriminal - seperti jika tim Anda tidak mempercayai "Penyusun" dan bersikeras melakukan segala sesuatu dalam bahasa assembly ).


1

Saya telah menemukan banyak hal ini ... di perusahaan teknik / elektronik kecil di mana mereka melakukan banyak perangkat lunak / perangkat keras tertanam.

Di tempat-tempat ini SCM bukan bagian dari budaya rekayasa elektronik. Mereka biasanya memiliki satu insinyur per proyek, yang hanya perlu mencadangkan rilis terbaru.

Jadi percabangan / penggabungan dan bahkan berbagi kode dianggap tidak dapat diselesaikan. Juga, perusahaan-perusahaan ini mungkin ISO9000, jadi prosesnya, albiet aneh, mungkin didokumentasikan.

Bagaimanapun, saya / pengembang lain baru saja mulai menggunakan SCM secara pribadi.


0

Di tempat saya bekerja, kami memiliki masalah yang sama. Saat ini saya mencoba untuk menggeser kontrol sumber di "di bawah radar" untuk mengatasi masalah yang sama yang Anda miliki. Saya menggunakan fosil untuk proyek yang saya kembangkan secara pribadi.

Saya baru-baru ini menyiapkan server fosil di LAN perusahaan, jadi sekarang ini lebih nyaman. Saya berharap bahwa ketika saya menunjukkan kegunaan pada beberapa proyek kecil yang saya akan merusak resistensi dan menjauhkan kita dari status quo folder jaringan.

Alasan terbesar yang saya dengar untuk tidak menggunakan fosil, atau VCS lainnya adalah:

  1. Banyak "programmer" adalah skrip kiddies, dan tidak akan mengerti cara menggunakannya
  2. Mereka yang bisa belajar, menganggapnya sebagai gangguan untuk digunakan
  3. Orang-orang ini adalah penjaga lama, nyaman dengan folder jaringan, jadi semua orang seharusnya
  4. Tidak ada yang punya waktu untuk mengaturnya dengan benar, atau belajar cara menggunakannya
  5. Meskipun fitur-fiturnya mungkin luar biasa, tidak ada yang diperlukan

Seperti yang Anda lihat, saya mencoba menyiasatinya dengan menunjukkan bahwa itu mudah digunakan, sudah diatur, mudah dipelajari, dan fitur-fiturnya sangat sepadan.

Akhirnya, bahkan jika Anda tidak membuat mereka menggunakan kontrol sumber, semuanya ada di pohon jaringan. Fosil dapat membuat versi semua yang ada di seluruh pohon, dan Anda dapat mengaturnya agar berjalan setiap kali terjadi perubahan file, atau setidaknya setiap jam. Saya telah melakukan itu untuk beberapa proyek kami yang "tidak memerlukan kontrol sumber" dan akhirnya memungkinkan saya untuk kembali ke versi yang baik ketika ada masalah.

Lakukan dengan benar, dan mereka bahkan tidak akan tahu Anda telah melakukannya. Maka Anda bisa menjadi pahlawan yang mengembalikan bangunan yang rusak, dan menunjukkan betapa berguna alat Anda.


0

Sekarang alat DVCS seperti Git dan Mercurial telah tersedia, dan sangat mudah diatur dan digunakan, benar-benar tidak ada alasan untuk bahkan tim 1 (!) Untuk tidak menggunakan kontrol sumber. Ini bukan tentang ukuran tim, ini tentang memiliki riwayat komentar tentang perubahan Anda dan kemampuan untuk mendukung alur kerja seperti memperbaiki masalah produksi saat mengerjakan rilis baru, dan melacak status kode sumber untuk versi yang berbeda.

Jika saya ditawari pekerjaan di tim yang mencapai ukuran itu, dan tidak ada pengembang yang menyarankan menggunakan VCS, atau jika "manajemen" mencegah mereka, saya akan menolaknya. Ini bukan cara kerja yang bisa diterima akhir-akhir ini.


Kontrol versi mudah diatur menggunakan Source Safe dan SVN. Bahkan CVS. (GIT TIDAK mudah diatur dan digunakan di lingkungan Windows)
Tim

0

Anda harus segera mendapatkan kontrol versi GIT. Anda dapat menggunakannya bahkan dari Google Code Project Hosting. Ketika orang lain melihat Anda melakukan perubahan hanya dalam satu klik saat mereka secara manual menyalin sesuatu, mungkin mereka berubah pikiran tentang hal itu.


Saya sangat setuju. Pemasang Git sangat mudah digunakan dan Anda dapat beroperasi dalam hitungan menit. Fungsi-fungsi lanjutan dapat menunggu, kontrol versi dasar tidak bisa menunggu. cd topleveldirectory; git init; git add *; git commit -m "initial commit"
dustmachine

0

Wow Hanya wow. Meskipun saya tidak berpikir itu adalah cara terbaik untuk menangani kontrol kode, itu tidak sepenuhnya aneh. Saya bekerja di sebuah perusahaan dengan 6 pengembang dan tidak ada kontrol sumber yang digunakan, mereka semacam memiliki cara internal mereka sendiri dalam mengelola file, manajer rilis dan yang lainnya akan mengawasi semua perubahan. Sebenarnya mantra adalah bahwa fungsionalitas baru dapat ditambahkan ke dalam proyek selama beberapa jenis saklar melilit fungsionalitas.

Misalnya kami sedang mengerjakan jejaring sosial kelas atas yang ditulis dalam PHP dan klien menginginkan fungsionalitas untuk dapat berlangganan profil pengguna. Pada dasarnya fungsionalitas dibungkus dengan cek seperti ini jika (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {lalu jalankan kode}

Tempat saya bekerja juga tidak pernah memiliki lebih dari satu pengembang pada suatu waktu mengerjakan file tertentu, sebagian besar semuanya modular sehingga dalam hal itu tidak perlu untuk kontrol sumber. Namun, saya percaya keuntungan dari kontrol sumber jauh lebih besar daripada kerugian karena tidak memilikinya dalam banyak kasus.

Fakta bahwa perusahaan Anda beralih ke spreadsheet yang mendokumentasikan perubahan file dan apa yang diubah ketika sesuatu seperti Git atau Subversion dapat mengatasinya bagi Anda benar-benar konyol.


0

Tampaknya Anda yakin, tetapi seseorang dalam organisasi tidak memberdayakan Anda untuk melakukannya. Seperti yang dapat Anda baca dari komentar lain, Anda harus melakukannya.

Anda dapat menemukan beberapa informasi di sini: http://www.internetcontact.be/scm/?page_id=358

Faktor yang paling penting adalah bahwa pelanggan Anda dipaksa ke cabang 'tidak stabil' terakhir dan jika kontrak Anda dengan pelanggan Anda membuat Anda bertanggung jawab untuk menggunakan versi tidak stabil, perusahaan Anda kehilangan uang. Anda harus benar-benar fokus pada stabilitas rilis di sini. Ini adalah alasan utama untuk kontrol sumber, dan sepertinya kegagalan utama Anda. Yang lain tidak akan ditingkatkan sebanyak itu dengan menggunakan kontrol sumber karena Anda sudah memiliki sistem alternatif.

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.