Apakah mungkin bagi programmer yang baik untuk tidak pernah menggunakan kontrol versi? [Tutup]

Saya mencari programmer ahli untuk membantu memecahkan situasi yang sulit.

Wawancara sejauh ini sangat mengecewakan. Kandidat terbaik sejauh ini adalah programmer yang sangat berpengalaman yang tidak pernah menggunakan perangkat lunak kontrol versi.

Masalah itu sendiri mungkin tidak terlalu serius karena itu adalah sesuatu yang dapat dipelajari dalam waktu singkat.

Tetapi ada aspek yang lebih dalam, yang membuat saya khawatir:

Bagaimana mungkin mengembangkan perangkat lunak secara aktif selama 10-15 tahun tanpa perlu kontrol versi?

Apakah fakta itu sendiri dari tidak mencari solusi untuk masalah pelacakan mengubah tanda sikap yang salah terhadap pemrograman?

Saya bekerja selama sekitar 11 tahun di perusahaan yang tidak menggunakan kontrol sumber. Kami berhasil (kebanyakan dengan mengomentari perubahan dan menyimpan kode pada server pusat yang dapat dipulihkan hingga tanggal apa pun). Kami tidak pernah benar-benar bertanya apakah ada cara yang lebih baik. Yang mengatakan, ini juga pada hari-hari ketika saya memiliki seluruh perpustakaan MSDN dalam bentuk buku di meja saya.

Ya, ada pemrograman sebelum internet.

Saya berjuang untuk melihat bagaimana Anda dapat menghabiskan 10+ tahun di industri sekarang tanpa harus mengalami kontrol sumber. Tapi, saya akan memiliki simpati, saya akan percaya itu mungkin dan saya tidak akan menolak kandidat pada satu detail saja. Saya akan menyelidiki dan mencari tahu bagaimana kandidat telah mengelola ini.

Atau, saya mungkin mempertanyakan apakah proses wawancara saya adalah masalahnya. Dengan cara apa dia adalah kandidat terbaik? Apakah ada teknik pemrograman modern lain yang tidak ia miliki yang saya tidak ajukan pertanyaan yang tepat? Jika saya mengajukan pertanyaan yang tepat, akankah calon lain bersinar?

Sebagai catatan terakhir, jangan takut untuk menolak semua kandidat jika Anda memiliki masalah. Memang memakan waktu untuk memulai dari awal, tetapi lebih memakan waktu untuk mempekerjakan orang yang salah.

Saya pikir itu tergantung pada sikapnya. Jika dia adalah programmer yang sangat berpengalaman, dan programmer yang baik, saya pikir dia akan dapat mengambil sistem kontrol versi dengan cepat. Dia mungkin membicarakannya dalam dua cara:

• Baik

  Saya tidak pernah menggunakan kontrol versi, tetapi saya sangat bersemangat untuk belajar, dan sepertinya itu akan sangat membantu membuat pengembangan lebih efisien. Saya belum terlalu membutuhkannya karena saya pernah mengerjakan proyek sendiri.

• Buruk

  Kontrol versi hanyalah kata kunci yang perlahan mati di industri. Saya di atas kontrol versi.

Biarkan saya memberi Anda beberapa perspektif dari melakukan pengembangan perangkat lunak di DOS dan Windows selama lebih dari 20 tahun.

Perangkat lunak kontrol versi di dunia Windows / PC sering tidak dapat diandalkan pada awal-pertengahan 90-an. Visual Sourcesafe (VSS) adalah tentang yang berbasis Windows terbaik di sekitar tetapi bisa jadi aneh dan banyak programmer membencinya. Beberapa tim tidak akan menghibur penggunaannya setelah menghadapi situasi ini.

Sebagian besar opsi VCS lainnya pada saat itu tidak berbasis Windows dan, oleh karena itu, jarang digunakan dalam tim pengembangan Windows. Beberapa di antaranya adalah solusi mahal dan solusi open source tidak diterima semudah sekarang.

Dalam banyak kasus, selama akhir 90-an, awal 00-an, jika tim Windows tidak menggunakan VSS, mereka tidak menggunakan apa pun untuk kontrol sumber selain dari konvensi internal. Beberapa dari mereka masih tidak menggunakan VCS meskipun kecanggihan Team Foundation Server (TFS) dan opsi gratis yang hebat seperti git dan SVN.

Mungkin saja seseorang yang bekerja bertahun-tahun di tim pengembangan Windows kecil selama bertahun-tahun belum pernah menggunakan VCS. Saya telah mewawancarai dan bahkan melakukan pekerjaan kontrak di beberapa tempat yang tidak menggunakannya atau yang sangat serampangan tentang penggunaannya.

Jadi, saya tidak berpikir bahwa kurangnya pengalaman kandidat Anda di bidang ini adalah 'tidak' tetapi Anda mungkin ingin mempelajari lebih dalam situasi kerja mereka sebelumnya untuk mencari tahu mengapa ini hilang dari pengalaman mereka. Anda juga ingin mengeksplorasi sikap mereka terhadap kontrol versi. Apakah mereka pikir itu ide yang baik tetapi mereka tidak diizinkan untuk mengejar itu di posisi mereka sebelumnya atau mereka pikir itu buang-buang waktu?

Tidak bisakah Anda memiliki kontrol versi tanpa perangkat lunak kontrol versi? Tanyakan bagaimana mereka mengelola kode mereka. Mungkin sudah ada sistem yang ditanam di rumah.

Ingin melakukan hal-hal secara manual, menciptakan kembali roda dan tahan terhadap perubahan bukanlah hal baru dalam pemrograman. Apakah Anda akan ngiler tentang kandidat yang menggunakan Visual Source Safe dan "hanya" VSS?

Saat mencoba mencari bakat, Anda harus bisa membedakan antara: tidak bisa, belum dan tidak.

Tidak ada alasan untuk tidak menggunakan kontrol versi, bahkan untuk proyek kecil yang dikembangkan oleh pengembang tunggal. Menyiapkan kontrol versi lokal sangat mudah, manfaatnya besar. Pengembang mana pun yang tidak mengetahui bahwa tidak dapat dianggap baik atau berpengalaman.

Adapun perusahaan yang menganggap kontrol versi sebagai "hal baru", yang tidak ingin mereka perkenalkan:

• SCCS dirilis pada 1972 ( 40 tahun yang lalu )
• RCS dirilis pada tahun 1982 ( 30 tahun yang lalu ), dan sepenuhnya open source dan gratis
• CVS dirilis pada tahun 1990 ( 21 tahun yang lalu ), juga sepenuhnya open source dan gratis

Seorang programmer yang tidak pernah menggunakan kontrol versi mungkin tidak pernah bekerja sama dengan programmer lain. Saya mungkin tidak akan pernah mempertimbangkan untuk mempekerjakan programmer seperti itu, terlepas dari kredensial lainnya.

Sepertinya bendera merah baik-baik saja, tetapi gali lebih dalam mengapa ia belum menggunakannya. Saya masih berharap seorang pengembang solo untuk menggunakan kontrol versi terutama dalam sepuluh tahun tetapi saya akan lebih memaafkannya daripada jika ia bekerja dalam sebuah tim dan bahkan tidak pernah mencoba untuk memasukkan kontrol versi.

Saya tidak akan religius tentang kurangnya pengalaman kontrol versi. Itu hanya alat. Pada akhirnya, Anda dapat mengambil dasar-dasar svn atau git dalam satu atau dua hari. Sisanya akan Anda dapatkan seiring waktu. Dan saya tidak dapat percaya bahwa setiap kandidat yang setengah layak tidak akan dapat menyesuaikan diri jika ia bekerja di lingkungan yang menggunakan kontrol sumber.

Menggunakan kontrol sumber lebih merupakan kebiasaan daripada keterampilan. Seseorang yang belum pernah menggunakannya mungkin melebih-lebihkan upaya yang diperlukan dan meremehkan manfaat yang didapat. Bagaimanapun, dia baik-baik saja sampai sekarang. Hanya setelah dia benar-benar menggunakan kontrol sumber, dia akan tumbuh menghargainya.

Pertanyaan yang harus Anda tanyakan adalah, bagaimana dia mengelola tanpa adanya kontrol sumber? Ini bisa memberi tahu Anda sesuatu tentang dia dan bagaimana dia mengelola pekerjaannya.

Anda meninggalkan banyak informasi tentang pengalamannya.

Pada dasarnya, saya akan mengatakan bahwa sangat mungkin bahwa seorang programmer dapat memiliki pengalaman 10-15 tahun tanpa harus tahu tentang kontrol versi. Pengkodean selama 10 tahun tidak sama dengan terus-menerus mempelajari teknik pemrograman baru selama 10 tahun.

Saya masih sangat muda dan saya telah melihat insinyur perangkat lunak yang lama dan "berpengalaman" yang kodenya tidak ingin saya sentuh. Yang mengatakan, dia mungkin sangat berbakat, tetapi saya akan menebak dari sedikit informasi yang diberikan bahwa dia tidak berbakat.

Semoga berhasil.

Secara pribadi, hal yang paling mengkhawatirkan bagi saya adalah bahwa kandidat tidak pernah menemukan sistem kontrol versi sebagai sebuah konsep, atau telah memutuskan bahwa itu tidak layak untuk digunakan. Saya menemukan skenario pertama sangat tidak mungkin, tetapi jika itu yang terjadi, maka itu membuat saya berasumsi bahwa kandidat telah terisolasi secara signifikan selama masa karir mereka, yang akan menimbulkan keraguan serius pada nilai mereka sebagai bagian dari tim. Secara khusus, mereka mungkin konsep yang sangat aneh tentang bagaimana melakukan hal-hal tertentu dan tidak tahu cara "benar" untuk melakukan sesuatu.

Jika ini adalah kasus kedua, di mana mereka secara aktif memutuskan untuk menentang kontrol versi, maka itu membuat saya berasumsi bahwa mereka tidak pernah mengerjakan sesuatu yang penting, atau sangat sombong. Atau, paling-paling, mereka memiliki cara yang sangat buruk untuk mempertahankan kode seperti mengomentari blok, dan menghubungkan setiap baris kode dengan penulis, tanggal, dan nomor bug.

Saya melihat beberapa jawaban yang agak menghakimi di sini yang tidak benar-benar memperhitungkan orang yang dihakimi.

Saya pribadi menemukan perangkat lunak kontrol versi menjadi alat yang sangat berharga. Tetapi, kita semua tidak memiliki pilihan dan kontrol tentang alat dan proses yang digunakan di lingkungan kerja kita. Saya telah bekerja dalam pengembangan Windows sejak 1990. Seperti yang diposting oleh orang lain, pada saat itu tidak banyak tersedia untuk VCS di Windows. Kami tidak akan membawa server UNIX hanya untuk mendapatkan VCS. Apakah itu membuat saya seorang programmer yang buruk? Kemudian dalam karir saya, saya bekerja untuk perusahaan dengan produk komersial pasar vertikal di mana kontrol versi adalah proses bukan alat. Apakah itu membuat saya seorang programmer yang buruk? Tiga pekerjaan terakhir saya semuanya sangat bergantung pada alat VCS. Apakah itu membuat saya seorang programmer yang baik?

Alangkah baiknya jika kita semua hanya menggunakan alat, bahasa, dan teknologi terbaru dan terhebat. Tetapi profesi pengembangan perangkat lunak tidak selalu bekerja seperti itu. Agak idealis untuk mengatakan "Saya akan segera meninggalkan pekerjaan, jika mereka tidak ..." atau "Saya tidak akan pernah menerima pekerjaan yang tidak menggunakan ..." atau "Saya akan memaksa mereka untuk menggunakan. .. " Kita tidak semua dikelilingi oleh pasokan kesempatan kerja yang tak terbatas di mana semuanya bekerja persis seperti yang kita inginkan. Kami memiliki tagihan untuk membayar dan membutuhkan pekerjaan, jadi kami berurusan dengan apa yang ada di sekitar kami.

Pada akhirnya, jawaban untuk pertanyaan Anda adalah ini: Nilailah programmer ini dengan keahliannya, filosofi dan keputusannya, bukan keputusan (mungkin salah arah) yang dibuat oleh orang yang bertanggung jawab di pekerjaan sebelumnya.

Saya tidak pernah menganggap diri saya seorang "programmer" sampai saya mulai menghasilkan uang dengan melakukannya secara profesional.

Saya telah menghasilkan sedikit uang untuk menciptakan sistem yang membuat klien lebih banyak uang. Apakah saya seorang pengembang yang "baik" itu subyektif.

Saya dapat GSD (Get Something Done) dengan cepat, yang untuk pengembangan web biasanya menyenangkan klien saya. Mereka mungkin tidak melihat kode jelek di belakang layar, tidak ada komentar, dll.

Saya belum pernah menggunakan Git dan tidak memiliki profil Github hingga tahun ini, yang menurut saya jauh "ketinggalan zaman" dalam hal standar programmer modern. Saya juga baru mulai melakukan proyek Rails dan Django setelah hanya melakukan PHP, Flash dan iOS di masa lalu. Saya sudah sejak kontrak mendarat mengembangkan situs di kedua untuk klien dan bagi saya, itu tidak terlalu menyakitkan untuk mempelajari sesuatu yang baru sama sekali pada usia 30 tahun dan beberapa tahun keluar dari pemrograman.

Terlalu banyak di masyarakat modern berfokus pada mengimbangi Jones dan peduli apa yang dipikirkan orang lain. Jika Anda dapat memutuskan belenggu-belenggu itu dan mempertimbangkan apa yang Anda butuhkan untuk pengembangan perangkat lunak Anda (kecepatan / waktu ke pasar, pengelolaan sumber daya yang dioptimalkan, kode yang terdokumentasi dengan baik, skalabilitas, dll), maka itu mungkin jauh lebih penting daripada apakah seseorang mengetahui Mercurial, SVN , Git atau sistem kontrol versi lainnya.

Saya lebih suka bertanya kepada calon pengembang apa yang mereka sukai, apa sistem paling keren yang pernah mereka buat menurut pendapat mereka sendiri dan apa yang mereka habiskan waktu luang mereka mengembangkan keterampilan mereka. Jika orang tidak memajukan keterampilan mereka di waktu mereka sendiri, itu membuatku takut lebih dari hal-hal lain, tetapi tidak berarti itu membuatmu takut.

Saya pikir Anda sudah memiliki jawaban yang bagus untuk pertanyaan ini dari orang-orang di sini dan itu akan membantu Anda membuat keputusan berdasarkan informasi berdasarkan kebutuhan Anda.

Saya merasa luar biasa bahwa seorang profesional perangkat lunak tidak pernah menggunakan kontrol sumber, dan saya akan sangat gugup untuk mempekerjakannya.

Pengalaman apa yang dia miliki. Saya ingin tahu apa lagi yang dia tidak tahu yang sejauh ini belum Anda ketahui.

Apa pengalaman pengembangan perangkat lunak Anda sendiri? Apakah Anda berada dalam posisi untuk bertanya kepadanya tentang arsitektur, pola desain, masalah pengembangan perangkat lunak umum, pertanyaan kinerja sistem, pertanyaan keamanan sistem, dll?

Jika dia kuat dalam hal-hal semacam itu, maka mungkin saya bisa mengabaikan kurangnya pengetahuan sumber kontrol.

Apakah mungkin bagi programmer yang baik untuk tidak pernah menggunakan kontrol versi?

Iya. Banyak perusahaan kecil dengan pemrogram otodidak tidak menggunakannya.

Bagaimana mungkin mengembangkan perangkat lunak secara aktif selama 10-15 tahun tanpa perlu kontrol versi?

Saya secara pribadi memperkenalkan kontrol versi ke 2 perusahaan kecil, telah meningkatkan 1 perusahaan menengah dari sesuatu yang mengerikan menjadi SVN (opsi terbaik saat itu) dan bekerja di perusahaan kecil lain yang hanya memiliki beberapa VC, menulis solusi VC mereka sendiri untuk beberapa kode dan punya banyak kode tidak dalam VC.

Apakah fakta itu sendiri dari tidak mencari solusi untuk masalah pelacakan mengubah tanda sikap yang salah terhadap pemrograman?

Yah itu bukan kegagalan instan, tapi saya pasti akan mengajukan banyak pertanyaan lanjutan. Hal-hal seperti:

Pernahkah Anda mencoba perangkat lunak VC? Apa? Apa yang kamu pikirkan tentang itu? Apakah ada alasan Anda tidak menggunakannya? Apa yang Anda gunakan sebelumnya untuk mengelola kode? Pernahkah Anda bekerja dengan siapa pun sebelumnya pada basis kode yang sama, dan metode apa yang Anda gunakan untuk menghindari bentrokan?

Saya ingin setuju dengan Pil Ledakan (tapi perwakilan saya terlalu rendah, atm ...) ... sikap jauh lebih penting.

Ada beberapa hal yang harus dicari, yang saya yakini membuat keunggulan pemrograman:

1. Komunikasi
2. Kreativitas
3. Belas kasihan (katakan apa?)

Dan, sering kali, lebih dari OCD kecil.

Anda tahu tipe ... orang-orang yang duduk di sana menggedor suatu masalah, benar-benar kehilangan diri mereka dalam kode mereka saat mereka mengeksplorasi opsi. Ini adalah orang-orang yang membuat catatan saat mereka berjalan, meninggalkan komentar dalam kode mereka untuk memastikan bahwa mereka memahami jalur logis mereka sendiri (dan untuk menerangi jalan bagi diri mereka sendiri atau programmer lain yang mungkin harus berurusan dengan kode di masa depan. .. dengan demikian, "belas kasihan" dalam daftar saya di atas!), dan dengan cepat dan jelas menyampaikan ide-ide kompleks kepada para pembuat keputusan dalam rantai sehingga masalah dapat diatasi secara efisien.

Seorang programmer yang sangat baik mungkin telah terjebak selama bertahun-tahun di lingkungan yang tidak setuju dengan gagasan VCS, memiliki pengalaman buruk dengan VCS (a la VSS) yang membuat mereka malu untuk mencoba sistem baru, tetapi saya akan menjamin bahwa programmer yang sangat baik dalam situasi itu masih akan mengatur semacam rutin untuk melindungi diri dari kehilangan semua pekerjaan mereka untuk beberapa iterasi desain yang buruk.

Jenis programmer berhati-hati, oleh karena itu, adalah orang yang mengaku tidak pernah diperlukan VCS, maupun ukuran perlindungan dari tak terelakkan screw-up. Sikap mereka adalah salah satu dari "baik, saya membangunnya, karena itu tidak mungkin salah." Itulah yang paling saya takuti daripada novisiat langsung dari perguruan tinggi, karena seorang pemula dapat belajar untuk menghargai kekuatan VCS karena mereka menyadari betapa sedikitnya yang mereka ketahui.

Bagaimana mungkin mengembangkan perangkat lunak secara aktif selama 10-15 tahun tanpa perlu kontrol versi?

Jika dia berasal dari tim sekolah tua di mana proyek-proyek kecil dikelola oleh satu orang, itu sangat mungkin. Dia mungkin memiliki 10 tahun pengalaman dalam teknologi yang sama tanpa belajar dan meningkatkan dirinya sendiri.

Apakah fakta itu sendiri dari tidak mencari solusi untuk masalah pelacakan mengubah tanda sikap yang salah terhadap pemrograman?

Jika kandidat Anda telah berada di lingkungan pengembangan tim (setidaknya 4 atau lebih programmer) maka itu adalah pertanyaan sepele. Namun, mungkin ada pembagian kerja antara pemrogram, mengerjakan modul yang hanya ditugaskan untuk mereka, yang dapat mengurangi kebutuhan untuk sumber mengontrol kode.

Namun, tidak mendengar tentang kontrol sumber di era internet adalah situasi yang benar-benar mengejutkan. Dengan demikian, saya akan melihat kesediaannya untuk mempelajari hal-hal baru (mengenai lingkungan pengembangan Anda) dan seberapa terbuka dia terhadap lingkungan kerja yang dinamis.

Pengalaman penting dan Anda benar bahwa mekanisme penggunaan alat kontrol sumber dapat dipelajari dengan cukup cepat. Tapi Anda benar melihat bendera merah.

• Apakah kandidat Anda terisolasi dari profesi dan trennya?
• Apakah banyak aspek lain dalam bekerja dalam tim juga perlu dipelajari?

Bagi saya, masalah tentang kontrol versi lebih merupakan gejala daripada penyakit. Penyebabnya mungkin bervariasi, dan cukup jinak. Banyak programmer ad-hoc baru saja mulai melakukan apa yang menurut mereka masuk akal, dimulai dengan beberapa buku tentang pemrograman, dan tidak membuat studi sistematis pengembangan perangkat lunak. Terkadang, lebih-lebih di masa lalu, jurusan ilmu komputer akan lulus tanpa pernah menggunakan sistem kontrol sumber karena semua proyek mereka adalah proyek individu dan mereka pergi ke perusahaan dengan proses perangkat lunak yang sangat tidak matang.

Namun dia sampai di sana, jika dia telah menjadi satu-satunya serigala selama satu dekade atau lebih, itu mungkin membuat hidup dengan orang sulit dilakukan.

Mungkin ada baiknya bertanya apakah calon Anda beberapa pertanyaan menyelidik.

• Ceritakan tentang waktu Anda bekerja sebagai bagian dari tim?
• Ceritakan kepada saya tentang saat ketika tim Anda bekerja memiliki konflik antara anggota tim?
• Ceritakan tentang saat ketika Anda menerima kode dari pengembang lain dan meneruskan proyeknya?
• Ceritakan bagaimana Anda dan anggota tim Anda yang lain saling menjauh ketika membuat kode bersama?
• Ceritakan tentang masalah yang dilaporkan pelanggan terkait dengan fitur yang dulu berfungsi, tetapi tidak berfungsi di versi yang lebih baru? Bagaimana Anda mengatasinya?
• Apa yang Anda sukai dari bekerja dalam tim?

Ia mungkin juga terbiasa memiliki kendali hampir penuh atas metode, proses, dan berada dalam peran di mana ia adalah satu-satunya ahli perangkat lunak. Anda akan menginginkan seseorang yang terbuka untuk cara baru dalam melakukan sesuatu. Lebih banyak pertanyaan:

• Ceritakan tentang waktu Anda menggunakan atau membantu membuat standar pengkodean?
• Jenis hal apa yang ingin Anda lihat dalam standar pengkodean?
• Bagaimana perasaan Anda tentang menulis ulang kode orang lain?
• Ceritakan tentang waktu Anda terlibat dalam peer review perangkat lunak atau dokumentasi?
• Bisakah Anda memberi tahu saya tentang proposal atau kontrak untuk pengembangan perangkat lunak yang Anda terlibat dalam penulisan?
• Ceritakan tentang manajer perangkat lunak atau penyelia favorit Anda?
• Ceritakan tentang rekan kerja atau bawahan favorit Anda?

Pada tahun 2012, bagi seseorang dengan pengalaman industri 15 tahun yang tidak pernah menggunakan kontrol versi adalah tanda bahaya. Itu mungkin bukan bendera merah jika tahun itu 1982, atau bahkan 1992. Tetapi hari ini, lebih baik ada penjelasan yang sangat baik untuk celah membingungkan ini di latar belakang pengembang itu.

Situasi luar biasa membutuhkan penjelasan yang luar biasa.

Ini agak seperti montir mobil yang mengklaim dia telah memperbaiki mobil selama 15 tahun, tetapi tidak pernah mendapatkan begitu banyak noda pada dirinya sendiri.

Tentu saja, mengolesi diri sendiri dengan minyak tidak akan memperbaiki transmisi, dan tidak ada langkah-langkah dalam manual perbaikan yang memerlukan hal seperti itu, tetapi bukan itu intinya. Intinya adalah bahwa menjadi bersih berderit sangat tidak konsisten dengan seperti apa sebenarnya bentuk mekanik mobil saat mereka bekerja. Dalam pekerjaan itu, Anda menjadi gemuk pada diri sendiri.

Jika Anda mewawancarai seseorang yang berpengalaman yang mengaku tidak memiliki pengalaman kontrol versi, ia mungkin melebih-lebihkan atau mengarang beberapa pengalamannya (dan bahkan tidak tahu bahwa kontrol versi adalah sesuatu yang banyak digunakan dan penting, dan sesuatu yang juga harus ia bohongi! )

Mungkin untuk melihat semua jenis pelawak dalam wawancara. Saya telah melihat orang-orang yang tidak dapat menggambar diagram dari daftar tertaut, atau menulis fungsi yang menyisipkan simpul di kepala daftar tertaut. Namun mereka mengklaim 20 tahun pengalaman kerja.

Bahkan lulusan baru dari ilmu komputer dapat diharapkan untuk memiliki keakraban pasif dengan kontrol versi, bahkan jika mereka belum menggunakannya secara luas.

Saya akan merasa aneh, tetapi bukan tidak mungkin bagi program yang berpengalaman tidak pernah menggunakan kontrol sumber khusus. Di satu perusahaan tempat saya bekerja, mereka menggunakan kontrol sumber secara luas untuk kode C # dan VB tradisional mereka. Tetapi kode database murni (prosedur tersimpan dan skrip serta definisi tabel) tidak dalam kontrol sumber meskipun memiliki dua Pengembang SQL profesional yang tugas utamanya adalah menulis, memelihara, dan mengeksekusi kode database murni. Saya memperjuangkan kontrol sumber untuk entitas database di sana dan hanya sebagian yang berhasil.

Di perusahaan lain, tim pengembangan itu kecil (satu orang berbelanja untuk waktu yang lama, kemudian dua). Kontrol sumber pengembang sebelumnya memiliki banyak salinan file sumber dengan tanggal yang ditambahkan di bagian akhir. Selain tidak memiliki sistem kontrol sumber yang lebih baik, pendahulu saya di sana jelas orang yang kompeten dan pintar.

Sebelum saya menjadi profesional, saya adalah penggemar dan tidak menggunakan kontrol sumber sama sekali, saya samar-samar tahu apa itu tapi tidak repot.

Singkatnya, saya pikir itu aneh bahwa seorang profesional tidak akan terlalu akrab dengan itu, tetapi terutama jika dia terbiasa dengan tim yang sangat kecil itu tentu mungkin menjadi kompeten tanpa itu. Dalam mempekerjakan, saya tidak akan menentangnya. Saya benar-benar akan memiliki keengganan untuk belajar dan mulai menggunakannya pada pekerjaan melawan dia ...

2c saya sendiri adalah bahwa itu tergantung pada bagaimana dia bereaksi ketika ditanya tentang VC. Reaksi yang mungkin terjadi adalah:

1. Hah? Apa itu
2. Tidak, kami melakukannya
3. Tanpa malu-malu , manajemen tidak mengizinkan kami
4. Tidak ada shuffle yang memalukan , tetapi saya menyelidiki sendiri sedikit dan berpikir itu tampak seperti sesuatu yang harus kita lakukan.

Dalam kasus 4, pria itu akan mendapat izin dari saya, dia memiliki sikap yang benar dan mungkin akan mengambilnya dengan baik. Dalam kasus 3, ia mendapat pujian karena memahami bahwa itu adalah sesuatu yang harus dilakukan tetapi tidak sebanyak kredit 4. Jika ia dapat menyebutkan beberapa factoids tentang VC (sebutkan beberapa paket VC di luar sana) d menganggap itu sebagai bukti keingintahuan dan mungkin melewatinya.

Jika dia menjawab 1 atau 2, yaitu, jika dia benar-benar tahu dan tidak peduli tentang VC, saya akan secara serius mempertanyakan penilaian kandidat. Akan ada alat-alat lain (pelacakan bug, metrik kualitas, otomasi pembuatan, dll. Dll) yang perlu dia kerjakan dan Anda mungkin akan menemukan Anda memiliki perjuangan yang berat pada semua masalah ini jika dia tidak terbuka untuk mencoba yang baru pendekatan.

Seperti kebanyakan orang di sini, saya pikir itu tidak adil untuk merugikan kandidat hanya karena majikan mereka tidak cepat; bagi saya, itu semua tergantung pada bagaimana mereka bereaksi terhadapnya.

Menulis apa yang berubah adalah baik ketika melihat ke belakang. Ini telah menyelamatkan saya banyak kali ketika mencari tahu apa yang salah dan banyak masalah diselesaikan dengan cepat karena saya sudah menuliskannya. Menurut pendapat saya, ada baiknya menyimpan log. Terutama jika Anda pemrograman dengan lebih banyak orang daripada diri Anda sendiri.

Jika Anda menulis aplikasi web, Anda dapat terus menambahkan fitur tanpa kontrol versi karena Anda terus-menerus hanya menambahkan hal-hal baru ke dalamnya. Tapi mungkin Anda akan menulis log atau posting berita dengan hal-hal yang baru.

Ini semua tentang apa yang Anda pemrograman.

Saya telah bekerja di lokasi di mana proses mendapatkan perangkat lunak disetujui adalah 12 hingga 18 bulan. Jika itu belum ada dalam daftar perangkat lunak yang disetujui, tidak ada cara untuk mendapatkannya di mesin. Drive CD / DVD dikunci, dan mesin tidak terhubung ke internet.

Tempat pertama saya bertemu dengan sumber kontrol solusinya adalah membuat pengembang menulis sendiri, pada saat itu siap untuk menguji proyek multi-tahun mereda. Mereka bertaruh bahwa menulis itu dari awal lebih cepat daripada proses persetujuan.

Tempat ke-2 yang saya temui masalah ini memang menggunakan kontrol sumber untuk beberapa bulan pertama, tetapi kemudian pelanggan menginginkan semua pengembangan dilakukan pada jaringan internal mereka. Mereka kembali mengunci semuanya, jadi itu kembali ke banyak folder zip.

Saya tahu pengembang yang hanya bekerja dalam kondisi ini. Mereka ingin menggunakan alat ini, mereka akan senang menggunakan alat ini, tetapi mereka tidak diizinkan untuk menggunakan alat ini.

Selidiki mengapa mereka belum menggunakannya. Tidak memahami prosedur karena nol pengalaman, jauh berbeda dari menolak alat.

Saya berkembang selama 15 tahun terakhir. Kontrol versi yang digunakan hanya beberapa kali. Saya masih menggunakan skrip dan program terjadwal saya sendiri untuk membuat cadangan semua folder pengembangan secara bertahap. Saya tidak tahu harus berkata apa. Jika seseorang bertanya kepada saya Jika saya menggunakan Kontrol Versi. Saya tidak pernah membutuhkan sistem kontrol versi, saya selalu bekerja pada proyek-proyek kecil. Maksud saya, saya bukan programmer terbaik di luar sana, tetapi saya yakin saya bukan yang terburuk. Sebagian besar waktu saya malu untuk memberi tahu orang-orang bahwa saya tidak secara teratur menggunakan sistem kontrol versi, tetapi itulah yang terjadi pada saya.

Berbicara dari pengalaman saya sebagai programmer pada sistem IBM MVS: selama sepuluh tahun pertama karir saya bekerja, sistem operasi tempat saya bekerja memiliki tepat satu jenis file versi yang tersedia untuk programmer: kumpulan data pembangkitan. Ini pada dasarnya adalah file dengan sejumlah versi tetap, dan Anda harus mengingat versi apa itu - cukup banyak tidak berguna untuk kontrol versi modern. Ditambah dengan sistem file yang tidak memiliki direktori nyata, hanya lebih atau lebih sedikit (8 karakter) kualifikasi, konsep sistem manajemen kode sumber benar-benar asing bagi siapa pun yang bekerja di lingkungan itu.

Saya tidak benar-benar melihat sistem kontrol kode sumber sampai saya pindah ke SunOS 3 dan harus menggunakan RCS. Pada saat itu saya adalah seorang programmer sistem IBM yang sangat lancar, sangat produktif, dan sangat baik dalam pekerjaan saya. Semua versi ditangani dengan menyalin cadangan ke kaset, dan merekam apa yang ada di mana.

Jika saya masih bekerja pada mainframe pada saat ini, sangat mungkin bahwa saya mungkin belum pernah terkena sistem kontrol versi formal; alternatif yang didukung secara khusus adalah ClearCase dan Rational, tidak ada yang gratis (dan pada kenyataannya keduanya cukup mahal).

Jadi mengatakan bahwa seseorang secara definisi tidak kompeten karena dia tidak pernah menggunakan kontrol versi adalah argumen yang tidak masuk akal. Penting untuk menggali dan melihat detailnya. Jika mereka mengklaim sebagai pengembang Linux / Unix / Mac OS tetapi tidak pernah menggunakan kontrol versi, itu berbicara kurang baik untuk mereka, dan Anda mungkin harus mempertimbangkan apakah pengalaman mereka secara keseluruhan sangat cocok sehingga Anda akan bersedia untuk latih mereka dalam rekayasa perangkat lunak modern. Jika mereka dan programmer mainframe sekolah tua - dan itulah yang Anda butuhkan - maka berkonsentrasilah pada apakah mereka memiliki keterampilan pemrograman yang dibutuhkan yang Anda inginkan, dan pasrah pada kenyataan bahwa Anda harus mengajarkan ini kepada mereka. Seperti yang dikatakan orang lain, respons mereka terhadap konsep akan menjadi faktor penentu dalam kasus itu.

Cukup cantik! Keseluruhan komunitas kami tidak hidup dalam komunitas sosial yang sangat maju di mana tempat nongkrong dan acara hack yang sangat banyak, kami juga tidak bekerja di perusahaan pengembangan perangkat lunak dan beberapa dari kami bahkan tidak dapat menemukan sumber daya yang dipublikasikan yang relevan atau terbaru. dalam bahasa asli kami, dicetak atau online, biarkan pernah bertemu sesama programmer dalam daging.

Yang bisa saya mengerti, jika dia seorang pengembang perangkat lunak yang berpengalaman seperti yang Anda katakan, maka dia kemungkinan besar adalah serigala yang bekerja sebagai freelancer untuk bisnis kecil.

Ada beberapa kemungkinan alasan untuk tidak menggunakan kontrol versi:

1. Bekerja di perusahaan yang tidak melakukan pengembangan perangkat lunak sebagai lini bisnis utama mereka.
2. Atau jika pengembang telah memutuskan untuk menggunakan beberapa sistem lain - hanya berlaku untuk yang berpengalaman.
3. Atau jika pengembang belum mempelajari cara kerja setiap sistem
4. Atau itu masalah sikap terhadap alat yang mereka tidak terbiasa

Tetapi Anda harus berhati-hati ketika bertemu orang-orang yang menganggap:

1. Bahwa hanya ada satu cara untuk melakukan sesuatu
2. Atau bahwa setiap programmer harus melakukannya dengan cara yang sama seperti yang mereka lakukan
3. Atau bahwa praktik yang digunakan orang mudah diubah

Sedapat mungkin bagi seorang programmer miskin untuk menjadi ahli dalam kontrol versi. Maksud saya adalah, saya tidak tahu kontrol versi apa yang dilakukan untuk keterampilan pemrograman Anda atau kemampuan pemecahan masalah. Itu adalah pertanyaan tentang pengalaman. Banyak toko-toko kecil yang tidak menggunakannya atau menyerahkannya kepada orang-orang indavidual (yang sering bekerja sendiri) untuk mencari tahu sendiri.

Saya pikir itu tidak begitu banyak pertanyaan tentang "Bagaimana mungkin untuk secara aktif mengembangkan perangkat lunak untuk 10-15 tahun tanpa pernah perlu kontrol versi?", Tapi "Bagaimana mungkin untuk secara aktif mengembangkan perangkat lunak untuk yang terakhir 10-15 tahun tanpa pernah memerlukan kontrol versi? "

Tentu pemrograman mungkin tanpa kontrol versi, tetapi seorang profesional harus terbiasa dengan keadaan saat ini, dan dapat memilih alat yang tepat untuk melakukan pekerjaan itu. Gagal menggunakan perangkat lunak manajemen versi yang sesuai membuat pekerjaan Anda berisiko dan tidak dapat diandalkan, dan salah satu alasan Anda ingin mempekerjakan pengembang profesional adalah karena mereka harus dapat mengelola risiko.

Basis kode yang dianotasi dengan benar dalam VCS jauh lebih berharga daripada yang tidak. Alasan untuk setiap perubahan dapat dilacak dan dipahami, sehingga memungkinkan bagi pengelola untuk lebih memahami apa yang perlu mereka ketahui. Gagal melakukan ini adalah tidak profesional, dan satu-satunya alasan adalah jika ia dihambat oleh manajer yang buruk di pekerjaan sebelumnya. Meski begitu, bukankah seharusnya mereka menggunakan versi untuk proyek pribadi mereka?