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


73

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?


25
Siapa bilang dia tidak butuh kontrol versi? Dia membutuhkannya, dan saya kira dia melakukannya secara manual. Mengatakan bahwa, seorang programmer yang melakukan ini tampaknya sangat tahan terhadap belajar sesuatu yang baru - bersiaplah untuk itu.
Doc Brown

6
@ e-MEE tergantung, Anda dapat mempelajari pembaruan / penyelesaian / komit dalam 30-60 menit tetapi tidak ada yang mengetahui bagaimana (d) vcs bekerja dalam satu jam. Kebanyakan ppl yang menggunakannya selama bertahun-tahun masih belum benar-benar mendapatkannya.
atamanroman

3
@ConradFrix Carrot Cake :)
Chad Harrison

7
Dimungkinkan bagi seorang programmer yang baik untuk tidak pernah menggunakan kontrol versi, jika kalender mengatakan bahwa hari ini adalah 1981.
Kaz

7
Ini terdengar seperti kasus klasik dari seseorang yang tidak memiliki 10 tahun pengalaman, tetapi lebih dari 1 tahun pengalaman diulang 10 kali.
Jeanne Pindar

Jawaban:


90

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.


17
+1, ini jawaban yang menarik. Namun, saya tidak begitu setuju dengan "pada masa itu, sumber kontrol menghabiskan banyak uang" . RCS telah ada selama 30 tahun, CVS - 21 tahun; Keduanya open source.
vartec

8
+1: Saya masih bekerja di sini . Kami akhirnya mendapatkan kontrol sumber yang dikelola tahun ini (sebagian besar karena saya). Saya tidak berpikir kita semua pengembang yang mengerikan karena tidak memilikinya sampai sekarang, tapi saya sangat senang itu datang
oliver-clare

3
Jika kandidat memahami prinsip-prinsip Kontrol Sumber maka saya tidak melihat masalah. Pengembang berpengalaman harus dapat mengambil "sintaks" dari sistem mana pun yang Anda gunakan dengan cukup cepat. Satu pertanyaan yang akan saya tanyakan - apakah semua pengalaman ini di satu situs? Jika demikian maka mungkin dia tidak memiliki wewenang untuk dapat memperkenalkan sistem. Jika pengalamannya dengan perusahaan yang berbeda maka saya akan menggali sedikit lebih jauh. Jumlah perusahaan, dengan tim pengembangan, yang tidak menggunakan kontrol sumber harus minimal saat ini.
BIDeveloper

4
+1 untuk poin tentang menanyakan pertanyaan yang tepat. Saya bertanya-tanya apa yang menjadikannya kandidat terbaik juga.
shambulator

3
@Ramhound: dan Anda yakin ketika melakukan kontrol sumber secara manual, Anda memerlukan lebih sedikit perangkat keras dan lebih sedikit waktu untuk pencadangan? Menurut pengalaman saya, yang terjadi justru sebaliknya.
Doc Brown

49

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.


17
Saya setuju bahwa itu mungkin 10 tahun yang lalu, tetapi saat ini? Saya akan mengatakan itu bukan "Baik / Buruk" tetapi "Buruk / Mengerikan"
vartec

24
Bahkan jika Anda bekerja sendirian, menggunakan VCS sangat berharga. Setelah sebuah proyek beralih dari "hampir berhasil" menjadi tidak pernah berhasil lagi, dan tidak memiliki cara untuk kembali ke versi "hampir bekerja", saya bersumpah untuk memasukkan semuanya ke dalam VCS tidak peduli seberapa kecil proyek tersebut .
alroc

11
"Saya sangat senang belajar," - Ini bukan produk komersial yang mahal seperti Coherence. Kontrol sumber adalah sesuatu yang dapat dikenali oleh siapa saja. Jika Anda membaca setiap blog pada pengembangan perangkat lunak Anda harus menyadari hal itu.
andy boot

7
+1 untuk jawaban ini. Itu bukan tanda programmer yang baik bahwa ia memiliki setiap keterampilan. Itu dia dapat mengambil keterampilan yang diperlukan.
Steven

2
@ Seven: Tidak. Tidak sama sekali. Dengan logika itu, seorang anak berusia 8 tahun dapat dipekerjakan karena mereka dapat mengambil pemrograman. IMO ada, atau seharusnya, keterampilan dasar yang diperlukan untuk dianggap sebagai programmer. Kemahiran dalam bahasa pemrograman adalah satu, pengetahuan dan penggunaan VCS apa pun adalah hal lain. Masih ada lagi.
Steven Evers

34

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?


18
VSS bukan "aneh" - itu hanya buruk. Repositori yang rusak & kehilangan data adalah hal biasa, tetapi Anda mungkin tidak menemukannya selama berminggu-minggu atau berbulan-bulan setelah masalah terjadi, kecuali Anda menjalankan pemeriksaan integritas harian (dan semoga berhasil pulih darinya bahkan saat itu). Penguncian file & berbagi itu mengerikan. Programmer membencinya karena itu membuat hidup mereka seperti neraka - kebalikan dari apa yang seharusnya dilakukan oleh VCS.
alroc

@ alroc - Percaya atau tidak, ada beberapa yang kurang dapat diandalkan dan lebih unik di luar sana. Saya mengalami kemalangan menggunakan satu sekitar tahun 1995. Saya tidak pernah memiliki masalah serius dengan keandalan VSS tetapi saya memang mendengar kisah celaka dari orang lain. Saya tahu beberapa organisasi yang berhenti menggunakan VCS setelah pengalaman buruk dengan VSS.
jfrankcarr

UGGH, kami mencoba kontrol sumber Powerbuilder kembali pada hari itu. Ini secara aktif menyebabkan kami kehilangan kode sumber. PB akan macet, dan setiap pbl yang diperiksa tidak dapat diakses oleh orang lain. Lelucon apa itu.
GrandmasterB

Saya bekerja selama 1,5 tahun di sebuah toko yang menggunakan Visual Source Safe. Salah satu programmer terbaik akan merusak repositori setiap kali ia mencoba memeriksa kode-nya melalui telepon (ya, ini beberapa waktu yang lalu). Salah satu sistem VCS paling favorit saya.
GlenPeterson

Kami menggunakan tlib ( burtonsys.com/index.html ) pada satu pekerjaan di lingkungan DOS. Memang ini pada tahun 2005, tetapi sepertinya mereka telah menggunakannya untuk sementara waktu.
Doug T.

29

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.


Sebelum saya menemukan tentang kontrol versi dan kegunaannya (saya menemukannya setelah 2 tahun pemrograman non-profesional, hobi) tidak jarang saya memiliki lima folder dengan "cadangan" tonggak proyek - VCS primitif.
orlp

"Tidak bisa, belum, tidak, dan tidak diizinkan"? Saya pernah mendengar tentang tempat-tempat yang tidak setuju untuk menjalankan kontrol sumber karena mereka menyukai hutan yang merupakan drive jaringan mereka.
Philip

19

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

20
Tidak yakin SVN adalah contoh terbaik untuk pengaturan "di luar sepele". Beberapa file yang harus Anda edit, langsung di repo, bisa jadi fiddly. Menyiapkan DVCS lokal sangat mudah. Dan menyiapkan akun BitBucket / GitHub dan mengkloning repo darinya tidak jauh lebih rumit
pdr

9
@artec: Apa yang tak penting adalah sepele git init. Halaman yang tertaut bisa membuat saya melarikan diri karena rasanya cukup rumit.
maaartinus

7
@ vartec: Saya berpendapat bahwa git dan hg lebih mudah dipahami oleh seorang pemula VCS daripada seseorang yang telah menggunakan VCS terpusat selama bertahun-tahun, dan lebih mudah daripada CVCS untuk pemula. Lihat saja bagian Tata Letak Repositori pada halaman itu seolah-olah Anda belum memahaminya. Kemudian pikirkan, "Saya punya repositori di sini, saya ingin mengkloningnya di sini."
PDR

8
@artec: Hmm. Tidak bisa setuju Saya suka bisa bercabang dan mengkloning bahkan ketika saya sedang bekerja sendirian. Kadang saya punya ide. Dan kadang-kadang mereka yang jahat :).
pdr

4
Saya telah bekerja di perusahaan tempat manajemen menolak kontrol versión. Itu bukan pilihan. Dan kami melakukan proyek yang menarik dan kompleks. Saya tidak berpikir saya adalah pengembang terburuk karena itu. Di rumah saya juga tidak menggunakannya, sejauh ini meskipun saya akui saya sudah mempertimbangkannya.
Picarus

14

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.


34
Saya tidak setuju. Tidak menggunakan kontrol sumber akan memerlukan tingkat kerjasama yang jauh lebih tinggi dengan programmer lain dari biasanya. Saya bahkan dapat mengatakan bahwa jika Anda berasal dari lingkungan di mana tidak ada kontrol sumber, maka Anda benar - benar tahu pentingnya kerja sama
oliver-clare

12
Itu pernyataan yang sangat bagus dan jelas tidak benar.
Murph

3
Saya tidak ingin mempekerjakan seorang programmer yang tidak tahu cara menggunakan alat-alat modern. Dia mungkin tahu bagaimana menulis kode yang sangat bagus, tetapi saya akan mempertimbangkan setidaknya pengetahuan dasar tentang versi mengontrol persyaratan mutlak.
JesperE

6
Banyak orang di sekitar sini tampaknya bingung karena tidak pernah terpapar VCS dan secara aktif menolak untuk menggunakannya di pekerjaan baru mereka. Bagaimana jika itu tidak pernah terpikir olehnya / mereka di tempat kerja sebelumnya atau apakah itu verboten oleh manajemen? Yang mengatakan, ini akan menjadi masalah kritis jika saya melakukan perekrutan, dan keinginan mereka untuk belajar akan menjadi persyaratan sulit bagi saya.
György Andrasek

5
Menakutkan melihat begitu banyak orang di sini sebenarnya menemukan kurangnya kontrol sumber sebagai sesuatu yang normal atau dapat diterima.
JesperE

12

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.


6
+1: Saya akan ngeri jika saya menganggur hanya karena manajer saya saat ini tidak melihat pentingnya kontrol sumber. Setidaknya saya memang menggunakan kontrol sumber untuk semua proyek pribadi saya, jadi saya tidak akan benar-benar kacau dengan situasi ini ...
oliver-clare

2
@ LordScree - Bekerja di situs web volume tinggi mungkin sulit dilakukan sendiri, tetapi Anda masih dapat belajar menggunakan kontrol sumber di luar pekerjaan Anda.
JeffO

9

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.


4
Pasti perlu mencari tahu bagaimana ia mengelola pembaruan, rilis dll tanpa kontrol versi
ChrisF

4

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.


4

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.


4

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.


4
Jika Anda hanya bekerja dengan orang idiot selama 15 tahun, dan tidak melakukan sumber terbuka yang cerdas di samping, itu mungkin akan mencerminkan pada keahlian dan sikap Anda. Orang dibentuk oleh lingkungannya. Jika bukan itu masalahnya, mengapa kita bahkan melihat riwayat pekerjaan seseorang.
Kaz

@Kaz Kami melihat riwayat pekerjaan mereka bukan untuk masukan rekan kerja mereka tetapi milik mereka sendiri. Tidak dapat menilai seseorang di daerah tempat mereka dibesarkan jika tidak, kita mungkin akan mulai mewawancarai tetangga juga.
James Khoury

Dibentuk oleh lingkungan kita, ya, tapi kita tidak didefinisikan oleh lingkungan kita. Saya hanya menyarankan agar OP mengambil tampilan penuh dari programmer dan tidak membuat penilaian yang keras berdasarkan satu kriteria.
cdkMoose

4

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.


2

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.


2

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?


1
Tidak ada yang baru dalam jawaban ini.
pdr

1
Pemrogram otodidak yang pintar hari ini semua tahu tentang kontrol versi dan menggunakannya. Sisanya memiliki kepala yang tersangkut di suatu tempat.
Kaz

@ Ka Tidak Setuju. Saya pikir itulah yang ingin kita pikirkan, tetapi saya telah bertemu programmer yang saya anggap pintar yang tidak, seperti yang dikatakan pengalaman pribadi saya. Tidak menggunakan kontrol versi adalah tanda peringatan besar bahwa mereka mungkin akan terjebak di suatu tempat [frase yang menarik :-)] tetapi tidak selalu demikian.
James

2

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.


2

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.


Tidak semua orang membaca blog pemrograman / dll. Secara khusus, seseorang yang kariernya sepenuhnya dengan platform warisan tunggal tidak akan menemukan banyak nilai langsung dari mereka. Berapa banyak blog perangkat lunak Mainframe / COBOL / RPG (bukan game) yang Anda ketahui? Memprogram platform-platform itu tidak banyak berubah dalam 30 tahun terakhir, dan banyak sumber informasi terbaik untuk mereka hampir pasti masih dalam format pohon mati. Jika pemrograman adalah pekerjaan Anda, vs apa kehidupan Anda berputar, ketika bekerja di daerah-daerah membaca blog teknologi / dll tidak akan memiliki banyak ROI jangka pendek.
Dan Neely

1
Bahkan pada proyek satu orang, Anda mendapat manfaat dari kontrol versi. Jika bug ditemukan, Anda dapat menyatakan "yang diperkenalkan di versi 3.13", sehingga pengguna 3.13 dan seterusnya terpengaruh. Anda juga dapat dengan mudah membuat tambalan untuk berbagai versi, untuk orang-orang yang tidak ingin bermigrasi ke yang terbaru. Jika Anda dapat melakukan hal-hal ini tanpa kontrol versi, maka Anda melakukan de facto, kontrol versi ad hoc. Anda berharap pengguna Anda menggunakan perangkat lunak Anda untuk menghilangkan pekerjaan manual yang melelahkan dan rawan kesalahan, tetapi Anda, programmer, jangan lakukan itu sendiri! LOL.
Kaz

2

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?

2

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.


Yang terbaik yang dapat Anda harapkan secara konsisten dari lulusan baru adalah, "Oh, saya pernah mendengarnya". Kami memiliki pengantar satu minggu untuk apa itu, berbasis di sekitar Subversion, tetapi tidak pernah menggunakan kontrol versi untuk apa pun.
Izkata

Ya, dan karena mereka adalah lulusan baru, kami "membeli" itu dan melanjutkan.
Kaz

"melewati keakraban" (apa yang saya pikir Anda maksudkan dalam jawaban) menyiratkan mereka telah menggunakannya pada titik tertentu; Saya menunjukkan Anda bahkan tidak bisa mengharapkan itu.
Izkata

Saya akan mengatakan bahwa jika lulusan CS tidak menggunakan kontrol versi, maka departemen almamater mereka telah gagal menerapkan kursus rekayasa perangkat lunak yang memadai dan wajib, di mana program sarjana tidak hanya belajar tentang konsep rekayasa perangkat lunak, tetapi juga bekerja pada proyek tim (dengan versi kontrol dan semua). Saya ingin berbicara satu atau dua dengan kepala departemen itu.
Kaz

Saya telah memprogram secara profesional selama hampir 20 tahun. Saya tahu apa daftar tertaut itu, dan mengapa daftar itu akan digunakan. Saya belum pernah menggunakan satu, dan mungkin akan berjuang dengan poin-poin halus menulis fungsi Anda. Saya pikir hanya karena Anda menggunakan teknik berusia 30 tahun, mengatakan bahwa semua orang seharusnya sedikit tidak adil.
DefenestrationDay

1

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 ...


minta DBA untuk menghasilkan skrip SQL dari database dan kemudian dia bisa menempatkan skrip dalam kontrol sumber.
linquize

@linquize Oh setuju. Itu adalah salah satu cara yang lebih baik untuk melakukannya (walaupun bukan satu-satunya). Saya hanya menyebutkan bahwa saya telah bertemu banyak profesional yang kompeten dan seorang amatir yang terampil yang tidak memiliki pengalaman dengan kontrol sumber, terutama di sisi DBA. Dalam mempekerjakan, saya akan enggan mempelajari kontrol sumber terhadap calon karyawan baru, tetapi saya tidak akan terlalu terkejut karena tidak pernah menggunakannya sebelumnya, terutama jika mereka terbiasa dengan tim kecil dan sebagian besar berada di sisi basis data.
TimothyAWiseman

1

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.


1

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.


0

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.


Tidak ada yang baru dalam jawaban ini.
pdr

0

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.


Saya memiliki pengalaman yang berlawanan: beberapa orang memberi saya tampilan lucu ketika saya mengatakan bahwa saya menggunakan kontrol versi pada proyek-proyek kecil di mana saya satu-satunya pengembang. Mungkin kurang begitu hari ini, karena kontrol versi digunakan untuk hosting proyek open source dan karenanya dipahami sebagai metode penyebaran.
Kaz

2
Anda harus mengubah sikap dan melihat kontrol versi karena memungkinkan Anda melakukan banyak hal dengan mudah. Misalnya gitsistem kontrol versi memiliki alur kerja otomatis ( git bisect) untuk menemukan bug regresi. Ini melakukan pencarian biner melalui riwayat versi proyek untuk mencoba menemukan perubahan yang memperkenalkan bug. Yang Anda lakukan adalah membangun kembali, menjalankan tes Anda, dan memberi tahu gitapakah itu baik atau buruk; kemudian memilih dan mengambil garis dasar untuk diuji selanjutnya.
Kaz

Di gitAnda dapat membuat beberapa perubahan eksperimental dan kemudian memasukkannya ke dalam stash. Pekerjaan Anda dikembalikan ke aslinya dan perubahan disimpan. Kemudian Anda dapat menjelajahi simpanan Anda dan menerapkan kembali perubahan itu untuk terus bereksperimen dengannya, atau membuangnya. Dan tentu saja setiap sistem kontrol versi yang layak memiliki percabangan, yang dengannya Anda dapat melakukan hal-hal seperti mengembangkan fitur, secara terpisah, dari versi stabil. Atau kembali dan perbaiki bug dalam rilis (untuk memberikan tambalan kepada pelanggan) dan gabungkan perubahan itu dengan versi pengembangan saat ini juga.
Kaz

0

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.


0

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.


-1

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

-2

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.


-2

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?

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.