İyi bir programcının sürüm kontrolünü hiç kullanmamış olması mümkün mü? [kapalı]

Zor bir durumu çözmeye yardımcı olacak uzman bir programcı arıyorum.

Şimdiye kadar yapılan görüşmeler şaşırtıcı derecede hayal kırıklığı yarattı. Şimdiye kadarki en iyi aday, sürüm kontrol yazılımı hiç kullanmayan, çok deneyimli bir programcı.

Sorun kendi içinde çok ciddi olmayabilir, çünkü kısa sürede öğrenilebilecek bir şeydir.

Ama beni endişelendiren daha derin bir yönü var:

Sürüm kontrolüne ihtiyaç duymadan 10-15 yıl boyunca aktif olarak yazılım geliştirmek nasıl mümkün olabilir?

Takip sorununa çözüm aramamak, programlama konusunda yanlış bir tutumun işareti olarak mı değişiyor?

Kaynak kontrolü kullanmayan şirketlerde yaklaşık 11 yıl çalıştım. Biz (çoğunlukla değişiklikleri yorumlayarak ve herhangi bir tarihe kadar kurtarılabilecek merkezi bir sunucuda kod saklayarak) başardık. Daha iyi bir yol olup olmadığını asla sormadık. Bununla birlikte, bu aynı zamanda MSDN kütüphanesinin tamamını masamda kitap şeklinde bulunduğum günlerde yapıldı.

Evet, internetten önce programlama vardı.

Sektörde 10 yılı aşkın bir süredir kaynak kontrolüne girmeden nasıl geçirebileceğinizi görmek için mücadele ediyorum. Ancak, biraz sempati duyardım, bunun mümkün olduğuna inanıyorum ve adayı tek bir detay için reddetmem. Adayın bunu nasıl yönettiğini araştırır ve bulurdum.

Alternatif olarak, görüşme sürecimin sorun olup olmadığını sorgulayabilirim. Hangi şekilde en iyi adaydı? Doğru soruları sormayacağımı bilmediğim başka modern programlama teknikleri var mı? Doğru soruları sorsaydım, başka bir aday da parlar mı?

Son bir not olarak, endişeleriniz varsa tüm adayları reddetmekten korkmayın. Baştan başlamak zaman alıyor, ancak yanlış kişiyi işe almak daha fazla zaman alıyor.

Bence onun tutumuna bağlı. Çok deneyimli bir programcı ve iyi bir programcı ise, hızlıca bir sürüm kontrol sistemi seçebileceğini düşünüyorum. Bu konuda iki şekilde konuşabilir:

• İyi

  Sürüm kontrolünü hiç kullanmadım, ama öğrenmek için çok heyecanlıyım ve gerçekten geliştirmeyi daha verimli hale getirecek gibi görünüyor. O kadar ihtiyacım olmadı çünkü yalnız projeler üzerinde çalıştım.

• Kötü

  Sürüm kontrolü, sektörde yavaş yavaş ölen bir terimdir. Sürüm kontrolünün üstündeyim.

Size 20 yıldan fazla bir süredir DOS ve Windows'ta yazılım geliştirme konusunda bir bakış açısı vereyim.

Windows / PC dünyasında sürüm kontrol yazılımı 90'ların ortalarında genellikle güvenilmezdi. Visual Sourcesafe (VSS) etrafındaki en iyi Windows tabanlı olanıydı, ancak ilginç olabilir ve birçok programcı ondan nefret ederdi. Bazı ekipler bu durumla ilgilendikten sonra kullanımlarını eğlendirmezler.

O sırada diğer birçok VCS seçeneği Windows tabanlı değildi ve bu nedenle Windows geliştirme ekiplerinde nadiren kullanılıyordu. Bunlardan bazıları pahalı çözümlerdi ve açık kaynaklı çözümler bugün olduğu kadar kolay kabul edilmedi.

Çoğu durumda, 90'ların sonlarında, 00'ların başında, eğer bir Windows ekibi VSS kullanmıyorsa, şirket içi sözleşmeler dışında bir kaynak kontrolü için hiçbir şey kullanmadılar. Bir kısmı, Team Foundation Server'ın (TFS) gelişmişliğine ve git ve SVN gibi harika ücretsiz seçeneklere rağmen hala bir VCS kullanmıyor.

Yıllarca küçük bir Windows geliştirme ekibinde yıllarca çalışan birinin VCS kullanmamış olması olasıdır. Onları kullanmayan veya kullanımları konusunda çok tehlikeli olan bazı yerlerde röportaj yaptım ve hatta sözleşme çalışmaları yaptım.

Bu nedenle, adayınızın bu alandaki deneyim eksikliğinin kesin bir 'hayır' olduğunu düşünmüyorum, ancak bunun neden onların deneyimlerinden eksik olduğunu bulmak için muhtemelen önceki çalışma durumlarına daha fazla katılmak istiyorsunuz. Ayrıca sürüm kontrolüne karşı tutumlarını da keşfetmek isteyeceksiniz. Bunun iyi bir fikir olduğunu düşünüyorlar mı, ancak önceki konumlarına devam etmelerine izin verilmedi mi, yoksa zaman kaybı mı olduğunu düşünüyorlar?

Sürüm kontrol yazılımı olmadan sürüm kontrolünüz olmaz mı? Kodlarını nasıl yönettiğini sorun. Belki de zaten evde kurulmuş bir sistem vardı.

İşleri manuel olarak yapmak, tekerleği yeniden icat etmek ve değişime dirençli olmak, programlama için yeni bir şey değil. Visual Source Safe ve "only" VSS kullanan bir adayı ezip geçecek misiniz?

Yeteneği bulmaya çalışırken, şu arasındaki farkı söyleyebilmelisin: olamaz, olmaz ve olmaz.

Tek geliştirici tarafından geliştirilen küçük bir proje için bile sürüm kontrolünü kullanmamak için mazeret yok. Yerel sürüm kontrolünü ayarlamak önemsizdir, faydaları çok büyüktür. Bunu bilmeyen herhangi bir geliştirici iyi veya deneyimli olarak kabul edilemez.

Versiyon kontrolünü tanıtmak istemedikleri "yenilik" olarak algılayan şirketlere gelince:

• SCCS 1972'de ( 40 yıl önce ) serbest bırakıldı.
• RCS 1982'de ( 30 yıl önce ) piyasaya sürüldü ve tamamen açık kaynak kodlu ve ücretsiz
• CVS 1990 yılında ( 21 yıl önce ) yayınlandı, ayrıca tamamen açık kaynak ve ücretsiz

Sürüm kontrolünü hiç kullanmayan bir programcı muhtemelen başka programcılar ile asla işbirliği yapmamıştır. Muhtemelen, herhangi bir referans bilgisine bakılmaksızın, böyle bir programcı tutmayı asla düşünmem.

Tamamen bir kırmızı bayrak gibi gözüküyor, ama neden kullanmadığı konusunda daha derine inin. Yalnız bir geliştiricinin özellikle on yıl içinde sürüm kontrolünü kullanmasını beklerdim, ancak bir takımda çalıştığından ve sürüm kontrolünü getirmeyi hiç denemeden bile daha fazla affederdim.

Sürüm kontrol deneyiminin eksikliği konusunda dindar olmazdım. Bu sadece bir araç. Sonunda svn veya git'in temellerini bir veya iki gün içinde alabilirsiniz. Gerisi zamanla alacaksın. Ve herhangi bir yarı-terbiyeli adayın, kaynak kontrolü kullanan bir ortamda çalışacaksa sığmayacağına inanamıyorum.

Kaynak kontrolünü kullanmak bir beceriden çok bir alışkanlıktır. Bunu hiç kullanmayan biri, gereken çabayı abartıp, kazanılan faydaları hafife alabilir. Ne de olsa şimdiye dek gayet iyiydi. Ancak aslında kaynak kontrolünü kullandıktan sonra, takdir etmek için büyüyecek.

Sormanız gereken soru, kaynak kontrolünün yokluğunda nasıl yönetti? Bu size onun hakkında ve işini nasıl yönettiği hakkında bir şeyler söyleyebilir.

Onun deneyimi hakkında çok fazla bilgi bırakıyorsun.

Temel olarak, bir programcının sürüm kontrolü hakkında bilgi sahibi olmadan 10-15 yıllık deneyime sahip olmasının çok mümkün olduğunu söyleyebilirim. 10 yıl kodlama, 10 yıl boyunca sürekli olarak yeni programlama teknikleri öğrenmeye eşit değildir.

Çok gencim ve kodunu asla dokunmak istemeyeceğim eski ve "deneyimli" yazılım mühendislerini gördüm. Bu, çok yetenekli olabileceğini söyledi, ancak olmadığını söyleyen küçük bilgilerden tahmin ediyorum.

İyi şanslar.

Şahsen, benim için en endişe verici şey, adayın sürüm kontrol sistemlerine bir kavram olarak hiç rastlamamış olması veya kullanmaya değmeyeceğine karar vermesi. İlk senaryoyu pek muhtemel bulmuyorum, ancak durum buysa, adayın bir takımın parçası olarak değerlerinden ciddi bir şüphe uyandıracak olan kariyerleri boyunca önemli ölçüde izole edilmiş olduğunu varsaymamı sağladı. Özellikle, belirli şeylerin nasıl yapılacağına dair çok tuhaf kavramlar olabilir ve şeyleri yapmanın "doğru" yollarından hiçbirini bilmiyorlar.

Sürüm kontrolüne karşı aktif olarak karar verdikleri ikinci durum ise, o zaman ya hiçbir zaman önemli bir şey üzerinde çalışmadıklarını ya da son derece kibirli olmadıklarını varsayıyor. Ya da en iyi ihtimalle, blokları yorumlamak ve her kod satırını bir yazara, tarihe ve hata numarasına atfetmek gibi kodları korumanın gerçekten korkunç yolları vardır.

Burada, yargılanan kişiyi aslında hesaba katmayan bazı yargılayıcı cevaplar görüyorum.

Şahsen sürüm kontrol yazılımını paha biçilmez bir araç olarak buluyorum. Ancak, çalışma ortamımızda kullanılan araçlar ve işlemler konusunda hepimizin seçimi ve kontrolü yok. 1990'dan beri Windows geliştirmesinde çalıştım. Başkaları tarafından yayınlandığı gibi, o zamanlar Windows'ta VCS için pek bir şey yoktu. Sadece bir VCS almak için UNIX sunucularını getirmeyecektik. Bu beni kötü bir programcı mı yaptı? Daha sonra kariyerimde, sürüm kontrolünün bir araç değil bir süreç olduğu düşey pazar ticari ürünü olan bir şirkette çalıştım. Bu beni kötü bir programcı mı yaptı? Son üç işim de büyük ölçüde VCS araçlarına dayanıyordu. Bu beni iyi bir programcı yapar mı?

Hepimiz sadece en yeni ve en iyi araçları, dilleri ve teknolojileri kullanmamız iyi olur. Ancak yazılım geliştirme mesleği her zaman bu şekilde çalışmaz. "İşi derhal bırakacaktım, eğer yapmazlarsa ..." ya da "Asla kullanmayan bir işi yapmam ..." ya da "onları kullanmaya zorlayacağım" demek biraz idealist. .. ". Hepimiz, her şeyin tam olarak istediğimiz şekilde çalıştığı sonsuz bir iş fırsatı arzıyla çevrili değiliz. Ödeyecek ve bir işe ihtiyaç duyacak faturalarımız var, bu yüzden çevremizdekilerle ilgileniriz.

Sonunda, sorunuzun cevabı şudur: Bu programcıyı, önceki işlerinde görevli olan kişilerin verdiği (muhtemelen yanlış yönlendirilmiş) kararlarla değil, becerileri, felsefeleri ve kararları ile değerlendirin.

Profesyonelce para kazanmaya başlayana kadar kendimi asla bir "programcı" olarak görmedim.

Müşterileri daha da çok para yapan sistemler yaratarak oldukça para kazandım. Benim "iyi" bir geliştirici olup olmamam özneldir.

Web geliştirme için müşterilerimi genellikle memnun eden GSD'yi (Bir Şey Tamamlandı) hızlıca yapabilirim. Sahnelerin arkasında çirkin bir kod, yorum eksikliği vb. Görmeyebilirler.

Git'i hiç kullanmamıştım ve bu yıla kadar bir Github profiline sahip değildim, modern programcı standartları açısından "zamanın gerisinde" olduğunu düşünüyorum. Daha önce sadece PHP, Flash ve iOS yaptıktan sonra Rails ve Django projelerini yapmaya daha yeni başladım. O zamandan beri hem müşteriler hem de benim için siteler geliştiren sözleşmelere başladım, 30 yaş ve bir kaç yıl program dışı kalma konusunda yeni bir şeyler öğrenmek çok acı verici değildi.

Günümüz toplumunda çok fazla şey, Jones’a ayak uydurmaya ve başkalarının ne düşündüğünü önemsemeye odaklanıyor. Bu zincirleri kırabilir ve yazılım geliştirmeniz için neye ihtiyacınız olduğunu (pazarlanma hızı / zamanı, optimize edilmiş kaynak yönetimi, iyi belgelenmiş kod, ölçeklenebilirlik vb.) Düşünebilirsiniz, o zaman birinin Mercurial, SVN bildiğinden çok daha önemli olabilir Git veya diğer sürüm kontrol sistemleri.

Geliştirici adaylarına neye tutkuyla bağlı olduklarını, kendi görüşlerine göre şimdiye kadar yaptıkları en havalı sistem nedir ve boş zamanlarını yeteneklerini geliştirmek için harcadıkları şeyleri sormayı tercih ederim. Bu beni diğer şeylerden daha çok korkutuyor, ama seni korkutması gerektiği anlamına gelmiyor.

Bu soruya zaten buradaki insanlardan büyük cevaplar aldığınızı ve gereksinimlerinize dayanarak kendi bilinçli kararınızı vermenize yardımcı olması gerektiğini düşünüyorum.

Bir yazılım uzmanının hiç kaynak kontrolü kullanmadığını inanılmaz buluyorum ve onu işe almak konusunda çok gerginim.

Ne deneyimi var. Şimdiye kadar öğrenemediğiniz başka ne bilmediğini merak ediyorum.

Yazılım geliştirme deneyiminiz kendiniz nedir? Ona mimarlık, tasarım kalıpları, genel yazılım geliştirme sorunları, sistem performansı soruları, sistem güvenliği soruları vb. Hakkında soru sorma pozisyonunda mısınız?

Bu tür şeyler konusunda güçlü çıktıysa, belki kaynak kontrol bilgisinin eksikliğini görmezden gelebilirdim.

İyi bir programcının sürüm kontrolünü hiç kullanmamış olması mümkün mü?

Evet. Kendi kendine öğretilen programcıları olan birçok küçük şirket bunu kullanmaz.

Sürüm kontrolüne ihtiyaç duymadan 10-15 yıl boyunca aktif olarak yazılım geliştirmek nasıl mümkün olabilir?

Kişisel olarak 2 küçük şirkete sürüm kontrolü getirdim, 1 orta ölçekli şirketi tanrıdan SVN'ye (o zaman en iyi seçenek) korkunç bir şey olarak yükselttim ve yalnızca bazı VC'leri olan başka bir küçük şirkette çalıştım, bazı kodlar için kendi VC çözümlerini yazdım ve VC’de pek fazla kod yoktu.

Takip sorununa çözüm aramamak, programlama konusunda yanlış bir tutumun işareti olarak mı değişiyor?

Anlık bir başarısızlık değil, ama kesinlikle birçok soru sormak istiyorum. Gibi şeyler:

Hiç VC yazılımı denediniz mi? Ne? Bunun hakkında ne düşünüyorsun? Kullanmamanın bir sebebi var mı? Kodu yönetmek için daha önce ne kullandınız? Daha önce aynı kod tabanında herhangi biriyle çalıştınız mı ve çatışmaları önlemek için hangi yöntemleri kullandınız?

Patlama Hapları ile aynı fikirdeyim (ama temsilcim çok düşük, atm ...) ... tutum çok daha önemli.

Programlama mükemmellik için yaptığına inanıyorum, aranacak birkaç şey var:

1. İletişim
2. Yaratıcılık
3. Şefkat (ne diyeyim?)

Ve çoğu zaman, bir miktar OKB'den daha fazla.

Bilirsin ... orada oturup bir soruna dövülmüş olanları, seçenekleri keşfederken kodlarını tamamen kaybederler. Bunlar, ilerlerken not alan, kendi mantıksal yollarını anladıklarından emin olmak için kodlarında yorumlar bıraktıkları (ve kendileri veya gelecekte kodla uğraşmak zorunda kalabilecek diğer programcılar için yolu aydınlatacaklardır). .. bu nedenle, yukarıdaki listemdeki "şefkat"!) ve karmaşık fikirleri karar vericilere hızlı ve net bir şekilde iletir, böylece problemlerin etkili bir şekilde çözülebilmesini sağlar.

Mükemmel bir programcı, VCS fikrini satın almayan, yeni sistemler denemek için kendilerini utangaç kılan VCS (la la VSS) ile ilgili kötü deneyimleri olan bir ortamda yıllarca sıkışmış olabilir, ancak bunu garanti ediyorum. Bu durumda mükemmel bir programcı, tüm çalışmalarını bir kaç kötü tasarım yinelemesine kaptırmak için kendilerini korumak için bir tür rutin kurmuş olacaktı.

Bu nedenle, dikkat edilmesi gereken programlayıcı türü, hiçbir zaman VCS'ye gereksinim duymadığını veya kaçınılmaz bozulmalara karşı herhangi bir koruma önlemi almadığını iddia eden türdür . Tutumları "ben inşa ettim, bu yüzden yanlış olamaz." Üniversitedeki herhangi bir kişiden daha fazla korktuğum kişiler bunlar, çünkü bir acemi VCS'nin gücünü takdir etmeyi öğrenebilir, çünkü gerçekte ne kadar az şey bildiklerini biliyorlar.

Sürüm kontrolüne ihtiyaç duymadan 10-15 yıl boyunca aktif olarak yazılım geliştirmek nasıl mümkün olabilir?

Küçük projelerin tek bir kişi tarafından yönetildiği eski okul ekiplerinden geliyorsa, bu mümkün. Kendisini öğrenmeden ve geliştirmeden, aynı teknoloji setinde 10 yıllık deneyime sahip olabilir.

Takip sorununa çözüm aramamak, programlama konusunda yanlış bir tutumun işareti olarak mı değişiyor?

Adayınız bir takım geliştirme (en az 4 veya daha fazla programcı) ortamında bulunmuşsa, önemsiz bir sorudur. Ancak, programcılar arasında, yalnızca kendilerine atanan modüller üzerinde çalışan ve kodu kontrol etme gereksinimini azaltabilecek bir iş bölümü olabilir.

Bununla birlikte, internet çağında kaynak kontrolünden haberdar olmamak gerçekten şaşırtıcı bir durumdur. Böylece, yeni şeyler öğrenme isteğine (gelişim ortamınızla ilgili) ve dinamik bir çalışma ortamına ne kadar açık olduğuna bakacağım.

Meseleleri deneyimleyin ve kaynak kontrol araçlarını kullanma mekanizmasının oldukça hızlı bir şekilde öğrenilebileceği konusunda haklısınız. Ama kırmızı bayrak görmekte haklısın.

• Adayın mesleğinden ve eğilimlerinden izole edildi mi?
• Takımda çalışmanın diğer birçok yönü de öğrenilmeli midir?

Benim için sürüm kontrolü ile ilgili mesele hastalıktan çok bir semptomdur. Sebep değişebilir ve oldukça iyi huylu olabilir. Pek çok geçici programlayıcı, programlama ile ilgili birkaç kitaptan başlayarak, anlamlı olduklarını düşündüklerini yapmaya başladılar ve sistematik bir yazılım geliştirme çalışması yapmadılar. Bazen, eskiden daha çok, bilgisayar bilimleri anaları hiç bir kaynak kontrol sistemi kullanmadan mezun olurlardı çünkü tüm projeleri bireysel projelerdi ve çok olgunlaşmamış yazılım süreci olan şirketlere gittiler.

Ancak oraya vardı, on yıl veya daha uzun bir süre yalnız bir kurt olmuşsa, insanlarla yaşamayı zorlaştırıyor olabilir.

Adayınızın birkaç soru sorup sormadığını sormaya değer olabilir.

• Bana bir takımın parçası olarak çalıştığınız bir zamandan bahseder misiniz?
• Bana üzerinde çalıştığınız bir ekibin ekip üyeleri arasında bir çelişki yaşadığı bir zaman hakkında bilgi verin.
• Bana başka bir geliştiriciden kod aldığınızda ve projesini ileri götürdüğünüz zamandan bahseder misiniz?
• Siz ve ekibinizin diğer üyelerinin birlikte kod oluştururken birbirlerinden nasıl uzak durduğunu söyleyin bana?
• Bana eskiden işe yarayan, ancak daha sonraki bir sürümde işe yaramayan bir özellik ile ilgili sorun bildiren bir müşteriden bahsedin. Bunu nasıl çözdün?
• Takımda çalışmaktan hoşlanıyor musunuz?

Metodları, süreçleri üzerinde neredeyse tamamen kontrol sahibi olmaya ve tek yazılım uzmanı olduğu rolde olmaya alışkın olabilir. Bir şeyleri yapmanın yeni bir yoluna açık olacak birini isteyeceksiniz. Daha çok soru:

• Bana bir kodlama standardı oluşturmak için kullandığınız veya yardım ettiğiniz bir zaman hakkında bilgi verin.
• Kodlama standardında ne tür şeyler görmek istersiniz?
• Başka birinin kodunu yeniden yazmak hakkında ne düşünüyorsunuz?
• Bana yazılım ya da belgelerin meslektaş değerlendirmelerine katıldığınızdan bahseder misiniz?
• Yazılıma karıştığınız yazılım geliştirme için bir teklif veya sözleşme hakkında bilgi verebilir misiniz?
• Bana en sevdiğiniz yazılım yöneticisi veya şefi hakkında bilgi verin?
• Bana en sevdiğin iş arkadaşından veya astından bahset.

2012 yılında, 15 yıllık endüstri tecrübesine sahip biri için sürüm kontrolünü hiç kullanmadıysanız, bir kırmızı bayraktır. Eğer yıl 1982, hatta 1992 ise bu bir kırmızı bayrak olmayabilir. Fakat bugün, geliştiricinin geçmişindeki bu şaşırtıcı boşluk için mükemmel bir açıklama yapılmalıydı.

Olağanüstü durumlar, olağanüstü açıklamalar gerektirir.

Bu, 15 yıldan beri araba tamir ettiğini iddia eden bir araba tamircisi gibi, ancak hiçbir zaman kendisinin üzerinde yağlanma noktası olmadı.

Tabii ki, kendinize gres yağı sürmek bir şanzımanı düzeltmeyecektir ve onarım kılavuzundaki adımların hiçbiri böyle bir şeyi gerektirmez, ancak mesele bu değil. Mesele şu ki, gıcırtılı temiz olmanın, araba tamircisinin çalıştıkları zamanki gibi görünmelerine şaşkınlıkla uyuşmuyor. Bu işte kendin yağlarsın.

Sürüm kontrolü deneyimi olmadığını kabul eden deneyimli biriyle görüşüyorsanız, muhtemelen deneyiminin bir kısmını abartıyor veya üretiyor (ve sürüm kontrolünün yaygın olarak kullanılan ve önemli bir şey olduğunu ve hatta yalan söylemesi gerektiğini bile bilmiyor!) )

Her türlü şakacıyı röportajlarda görmek mümkün. Bağlantılı listenin bir şemasını çizemeyen veya bağlantılı listenin başına bir düğüm ekleyen bir işlev yazamayan insanlar gördüm. Yine de 20 yıllık iş tecrübesi talep ettiler.

Bilgisayar biliminden yeni mezunların bile, henüz kapsamlı bir şekilde kullanılmamış olsalar bile , sürüm kontrolü konusunda pasif aşina olmaları beklenebilir .

Bunu garip bulurdum ama deneyimli bir programın hiçbir zaman özel kaynak kontrolü kullanmamış olması imkansız değil. Çalıştığım bir şirkette, geleneksel C # ve VB kodları için kaynak kontrolünü yaygın olarak kullandılar. Ancak, saf veritabanı kodu (saklı yordamlar ve komut dosyaları ile tablo tanımları), asıl işi saf veritabanı kodunu yazmak, sürdürmek ve yürütmek olan iki profesyonel SQL Geliştiriciye sahip olmasına rağmen, kaynak kontrolü altında değildi. Oradaki veritabanı varlıkları için kaynak kontrolünü savundum ve kısmen başarılı oldum.

Başka bir şirkette, geliştirme ekibi küçüktü (bir adam uzun süre dükkan sonra iki tane). Önceki geliştiricinin kaynak kontrolü, kaynak dosyalarının sonunda kopyalanmış bir tarih bulunan birden çok kopyaya sahipti. Daha iyi bir kaynak kontrol sisteminden yoksun olmanın yanı sıra, öncülüm kesinlikle yetenekli ve akıllı bir adamdı.

Profesyonel olmadan önce hobi olarak çalışmıştım ve herhangi bir kaynak kontrolü kullanmıyordum, ne olduğunu biliyordum ama rahatsız etmiyordum.

Kısacası, bir profesyonelin çok aşina olmamasının garip olduğunu düşünüyorum, ancak özellikle çok küçük takımlara alışması durumunda, onsuz yetkin olmak kesinlikle mümkün. Bunu işe alırken, ona karşı tutmazdım. Öğrenmeye ve ona karşı iş başında kullanmaya başlamam konusunda kesinlikle isteksiz davranırdım ...

Benim kendi 2c, VC hakkında sorulmasına nasıl tepki verdiğine bağlı. Muhtemel tepkiler şunlar olabilir:

1. Ha? Bu da ne
2. Hayır biz yerine
3. Utanan bir karışıklık yok , yönetim bize izin vermiyor
4. Utanan bir karışıklık yok , ama biraz kendimi araştırdım ve yapmamız gereken bir şey gibi göründüğünü düşündüm.

4 durumunda, adam benden bir pas alırdı, doğru bir tavrı var ve muhtemelen onu iyi alacak. 3 durumunda, yapılması gereken bir şey olduğunu, ancak 4'e kadar kredisi olmadığını anladığı için kredi alır. Eğer VC hakkında birkaç factoid adlandırabilirse (VC paketlerinin bazılarını listele) I ' Bunu bazı merakların kanıtı olarak kabul eder ve onu geçer.

1 ya da 2 cevap verdiyse, yani eğer VC hakkında bir şey biliyorsa ve bilmeseydi, adayın kararını ciddiye alırdım. Çalışması gereken başka araçlar (hata izleme, kalite ölçütleri, otomasyon oluşturma vb.) Olacak ve yeni denemeye açık değilse muhtemelen tüm bu konularla ilgili bir yokuş yukarı savaşınız olduğunu göreceksiniz. yaklaşımlar.

Buradaki çoğu insan gibi, işverenlerinin de hız kazanamadıkları için adayı dezavantaj etmenin haksızlık olacağını düşünüyorum; Benim için her şey, nasıl tepki verdiklerine bağlı.

Değişenleri yazmak geriye bakarken iyidir. Neyin yanlış olduğunu ve bir sürü problemi hızlı bir şekilde çözdüğüm için yazdım. Benim düşünceme göre, bir günlük tutmak iyidir. Özellikle de kendinizden daha fazla insanla programlama yapıyorsanız.

Bir web uygulaması yazıyorsanız, sürüm kontrolü olmadan özellik eklemeye devam edebilirsiniz çünkü sürekli olarak yeni şeyler ekliyorsunuzdur. Ama belki yeni şeyler için bir günlük veya haber yazısı yazacaksınız.

Her şey programladığınız şeyle ilgili.

Yazılımın onaylanma sürecinin 12 ile 18 ay arasında olduğu yerlerde çalıştım. Önceden onaylanmış bir yazılım listesinde olmasaydı, makinelere sokmanın yolu yoktu. CD / DVD sürücüleri kilitlendi ve makineler internete bağlı değildi.

Kaynak kontrolüne koştuğum ilk yer, çözümün bir geliştiricinin kendi yazmasını sağlamaktı, çok yıllı projeyi test etmek için hazır olduğu zaman çöküyordu. Sıfırdan yazmanın onay sürecinden daha hızlı olduğu konusunda kumar oynadılar.

Bu sorunla karşılaştığım 2. yer, ilk birkaç ay boyunca kaynak kontrolünü kullandı, ancak daha sonra müşteri kendi iç ağlarında tüm gelişmeleri istedi. Yine her şeyi kilitlediler, bu yüzden birçok sıkıştırılmış klasöre geri döndü.

Sadece bu koşullarda çalışan geliştiricileri biliyorum. Bu araçları kullanmak istiyorlar, bu araçları kullanmayı çok isterler, ancak bu araçları kullanmalarına izin verilmez.

Onları neden kullanmadıklarını araştırın. Sıfır deneyim nedeniyle prosedürleri anlamamak, araçları reddetmekten çok farklıdır.

Son 15 yıldır gelişiyorum. Sürüm kontrolünü yalnızca birkaç kez kullandım. Hala tüm geliştirme klasörlerini adım adım yedeklemek için kendi zamanlanmış komut dosyalarımı ve programları kullanıyorum. Ne diyeceğimi bilemiyorum Biri sorarsa Sürüm Kontrolü kullanıyorsam. Sürüm kontrol sistemine hiç ihtiyacım olmadı, her zaman küçük projeler üzerinde çalıştım. Yani, orada en iyi programcı değilim, ama en kötüsü olmadığımdan eminim. Çoğu zaman insanlara düzenli olarak sürüm kontrol sistemi kullanmadığımı söylemekten utanıyorum, ancak bu benim için de böyle.

IBM MVS sistemlerinde bir programcı olarak deneyimimden bahsetmişken: çalışma kariyerimin ilk on yılında, çalıştığım işletim sisteminin programlayıcı için tam olarak bir tane sürümlenebilir dosya türü vardı: üretim veri seti. Bu aslında sabit sayıda sürüm içeren bir dosyaydı ve modern sürüm kontrolü için hangi sürümün ne olduğunu hatırlamak zorunda kaldınız. Gerçek dizinleri olmayan bir dosya sistemiyle birleştiğinde, az ya da çok (8 karakterli) niteleyicilere sahip olan bir kaynak kod yönetim sistemi kavramı, o ortamda çalışan herkes için tamamen yabancıydı.

SunOS 3'e taşınana ve RCS kullanana kadar bir kaynak kod kontrol sistemi görmedim. Bu noktada işimi çok verimli, çok verimli ve çok verimli bir IBM sistem programcısıydım. Tüm sürümler teyplerin teyplere kopyalanması ve nerede olduğu kaydedilerek gerçekleştirildi.

Bu noktada hala ana bilgisayarlar üzerinde çalışıyor olsaydım, hala hiçbir zaman resmi bir sürüm kontrol sistemine maruz kalmamam mümkündü; Özel olarak desteklenen alternatifler, ikisi de ücretsiz olmayan ClearCase ve Rational'dir (ve aslında her ikisi de oldukça pahalıdır).

Yani birisinin tanımı gereği yetersiz olduğunu söylemek, çünkü sürüm kontrolünü hiç kullanmadı çünkü çok tartışmalı bir argümandır. Kazıp detaylara bakmak gerekiyor. Bir Linux / Unix / Mac OS geliştiricisi olduğunu iddia ediyorlar ancak sürüm kontrolünü hiç kullanmamışlarsa, onlar için daha az iyi konuşuyorlar ve genel deneyimlerinin sizin için uygun bir seçim olup olmadığını tartmanız gerekebilir. onları modern yazılım mühendisliğinde eğitin. Eğer onlar ve eski okul anabilgisayar programcısı - ve ihtiyacınız olan şey - o zaman tam olarak istediğiniz programlama becerisine sahip olup olmadıklarına odaklanın ve kendinize bunu onlara öğretmeniz gerekeceği gerçeğinden istifa edin. Diğerlerinin de söylediği gibi, bu kavrama tepkileri bu durumda karar verici faktör olacaktır.

Güzel lütfen! Topluluğumuzun tamamı, geeky hangout'larının ve hack olaylarının aşırı derecede bol olduğu, çok gelişmiş sosyal topluluklarda yaşamıyor, ne de hepimiz yazılım geliştirme şirketlerinde çalışıyoruz ve bazılarımız ilgili veya güncel yayınlanmış kaynakları bile bulamıyoruz. Anadillerimizde, basılı veya çevrimiçi olarak, etten çok iyi bir programcıyla karşılaşalım.

Anladığım kadarıyla, eğer söylediğiniz gibi deneyimli bir yazılım geliştiricisi ise, o zaman küçük işletmeler için serbest çalışan olarak çalışan yalnız bir kurt olmuştur.

Sürüm kontrolünü kullanmamak için birkaç olası neden vardır:

1. Ana iş kolu olarak yazılım geliştirme yapamayan firmalarda çalışmak.
2. Veya geliştirici başka bir sistemi kullanmaya karar verdiyse - sadece deneyimli olanlar için geçerlidir.
3. Veya geliştirici henüz her sistemin nasıl çalıştığını öğrenmediyse
4. Ya da tanımadıkları aletlere karşı tutum sorunu

Ancak, aşağıdakileri varsayan insanlarla tanışırken dikkatli olmalısınız:

1. Bir şey yapmanın tek bir yolu var.
2. Veya her programcının yaptıkları gibi yapması gerekir.
3. Veya insanların kullandığı uygulamaların kolayca değiştirilebileceğini

Fakir bir programcının sürüm kontrolü konusunda uzman olması için mümkün olduğu kadar. Demek istediğim, programlama becerileriniz veya problem çözme yetenekleriniz için sürüm kontrolünün ne yaptığını bilmiyorum. Bu bir deneyim meselesidir. Birçok küçük dükkan ya kullanmaz ya da kendileri için çözmek için (genellikle yalnız çalışan) kişilere bırakır.

Sanırım, "10-15 yıl boyunca sürüm kontrolüne gerek kalmadan aktif olarak yazılım geliştirmek nasıl mümkün olabilir?" Sorusu değil, " Son 10-15 yıl boyunca hiç sürmeden aktif olarak yazılım geliştirmek nasıl mümkün?" sürüm kontrolü mi gerekiyor? "

Elbette programlama sürüm kontrolü olmadan mümkündür, ancak bir profesyonel sanatın mevcut durumuna aşina olmalı ve işi yapmak için doğru araçları seçebilmelidir. Uygun sürüm yönetimi yazılımını kullanmamak, çalışmanızı riskli ve güvenilmez hale getirir ve profesyonel bir geliştirici kiralamak istemenizin nedenlerinden biri de, riski yönetebilmeleri gerektiğidir.

Bir VCS'ye düzgün şekilde eklenmiş bir kod tabanı olmayan bir değerden çok daha değerlidir. Her değişikliğin sebebi izlenebilir ve anlaşılabilir, bu da bakıcıların bilmeleri gerekenleri daha derinlemesine kavramasını mümkün kılar. Bunu yapmamak profesyonelce değildir ve bunun tek bahanesi önceki işlerinde fakir yöneticiler tarafından kısıtlanmış olsaydı olacaktır. O zaman bile, özel projeleri için versiyonlama kullanmamışlar mıydı?