Geçici kod sürüm kontrolü altına alınmalı mıdır ve nasıl?

İşte bazı geçici / yerel kod örnekleri. Kod temeli ile çalışmak için gereklidir, ancak bunun bir parçası olmak zararlı olacaktır:

1. Proje dosyaları Mevcut PC'deki düzeni yansıtabilmek için yolların düzenlenmesi gerekebilir.
2. Makefile'lar. Örneğin, optimizasyonun hata ayıklama sırasında kapatılması gerekebilir, ancak CI sunucusu için gerekli olmayabilir.
3. Kirli çirkin hackler. Örneğin return 7, bir işlevin ortasında, bir işlevi test etmek için, işleve bağlı olarak ve 7 değerinde kırıldığından şüpheleniliyor. Veya 7, henüz uygulanmadığım ve uygulama boyunca test etmem gereken, henüz uygulanmayan düğmenin kodu Şubemin hayatı.

Onları bir depoda tutmaya çalıştım, her zaman repoyu ittirmeden ve sonra ittirmeden önce en üste yeniden indireceğim HEAD~. Bu oldukça sakıncalıdır ve svn ile çalışmaz. Stashing beni daha çok korkutuyor - "bastıktan sonra patlamayı hatırladım mı ??".

Kodun sürüm kontrolünün dışında tutulması, bir taahhüdün gerçekleştirildiği her seferde rahatsız edici bir ses çıkarır ve bazı cuma akşamları yanlışlıkla bir federasyona girebilir.

Bu tür fırlatma kodları için mantıklı bir çözüm ne olurdu?

Tüm kodlar geçicidir. Değişiklikler yaparken, zaman zaman yer tutucuları tanıtacağım - tasarımcıdan gerçek olanı beklediğim bu simgeyi, tanıdığım işlev meslektaşımın yazdığı ve henüz bitmemiş (veya başlamamış) kütüphaneyi arayacak, kaldırılacak veya koşullu hale getirilecek ek günlük kaydı, test ekibi tarafından fark edildikten sonra düzeltmek için alacağım hataları vb.

Bu yüzden her şeyi kontrol edin. Tüm gelişiminiz için bir özellik dalı kullanın, daha sonra son halini bagajda birleştirebilirsiniz ve hiç kimse geliştirme döngüsünde ne tür kesmeler ve geçişler ve düzeltmeler yaptığını bilmeniz gerekmez. son versiyona bakınız. Ancak şubenize düzenli olarak karar verirseniz, bir gün olağanüstü derecede yanlış giderse, tutmaya değer şeyleri görebileceksiniz veya bir öğle yemeğinden sonra pub'da kodlamaya devam etmiş olacaksınız.

Sürüm kontrolü, yapay bir depo veya belge depolama sistemi değildir. Değişim tarihini tutmakla ilgili. Orada istediğin her şeyi yap, bir gün ne olduğunu görmek isteyebilirsin ve bunlar, SCM'nizin gerçekte ne olduğunu anladığın günlerdir.

PS. Gerçekten geçici dosyaların (örneğin .obj veya derleme eserleri) SCM'nizde yeri yoktur. Bunlar kimseye değeri olmayan şeyler. Ne olduklarını söyleyebilirsiniz - silerseniz, sakıncası yoktur, hatta onların gittiğini fark etmezsiniz.

Proje dosyaları Mevcut PC'deki düzeni yansıtabilmek için yolların düzenlenmesi gerekebilir.

Proje dosyaları için en iyi strateji, proje dosyasını bir komut dosyası aracılığıyla oluşturabilmenizdir. Gerçek proje dosyasını yoksayarsaklarınıza ekleyin ve proje dosyasını gereken şekilde yeniden oluşturun. Örneğin, Java projelerinde, güneş tutulması projesi oluşturabilen bir kepçe kullanıyorum.

Makefile'lar. Örneğin, optimizasyonun hata ayıklama sırasında kapatılması gerekebilir, ancak CI sunucusu için gerekli olmayabilir.

Makefile'nizi değiştirmeden optimizasyon ve hata ayıklama modu arasında geçiş yapmalısınız. Bunun yerine, bunu kontrol etmek için havuzunuzda olmayan bir komut satırı bayrağı, ortam değişkeni veya ayrı bir dosya kullanın.

Kirli çirkin hackler. Örneğin, bir işlevi test etmek için, işleve bağlı olarak ve işleve bağlı olarak 7 değerinde kırıldığından şüphelenilen 7 işlevinin ortasına 7 döndürün. şubemin ömrü boyunca test ederim.

Şüphe edilen başarısızlık olayını başlatan bir test yazamaz mısınız?

Çoğu durumda, iş akışınızı ayarlayabilmelisiniz, böylece bu değişiklikleri havuzunuzdaki dosyalarda yapmazsınız. Yerel olarak değiştirilen dosyalar, projenizin yoksayma mekanizmasına eklenmeli ve depoda olmamalıdır. Bazı durumlarda, depoya koymak istemediğiniz geçici değişiklikler yapmaya devam edersiniz. Bunlar için: XXX gibi özel bir sekans ekleyin ve hala orada bulunan taahhütleri reddeden bir ön işleme kancası ekleyin.

Sürüm kontrolü, uygulamayı oluşturmak için gereken kodu ve yapılandırmayı içermelidir.

Bu şu demek:

• Kısa bir süre için tanıtılan geçici şeyler (örneğin, bir hatanın yerini belirlemek için veya örneğin bir dilin özelliğini denemek için gereken süre) sürüm kontrolünde olmamalıdır: ihtiyacınız olana kadar saklamalısınız bu, sonra sadece taahhütte bulunurken onu kaldırın .

• Belirli bir makineye uygun yerel dosyalar bir dalda tutulabilir.

  Dizüstü bilgisayar çalındığında ya da bir virüs sizi işletim sistemini yeniden yüklemeye zorladığından, bunların hepsini yerel olarak tutmaktan kaçınırdım (ve bu arada, son yedeklemenizin iki yıl önce yapıldığını görüyorsunuz) .

  Öte yandan, dosya yapısına dikkat edin: yerel yapılandırma tamam, ezici oluncaya kadar ve sizi projeye katılan 42 geliştiricinin her dosyasında tek bir değişiklik yapmaya zorlar.

  Makineler arasındaki özellikleri kaldırma fırsatını izleyin. Bu demek olabilir:

  • Geliştiricilerin makinelerindeki yerel örnekleri değiştirmek için dev SQL sunucusuna erişim vermek,

  • Kamu paketleri için Pypi veya npm gibi paket dağıtım hizmetlerini ve kurum içi paketler için özel muadillerini kullanmak,

  • Ekip üyelerinden aynı yazılım sürümlerini kurmalarını isteyin,

  • Yazılım güncellemelerini olabildiğince şeffaf yapın,

  • Veya işletim sistemini ve gerekli yazılımı bir tıklamayla bir makineye yerleştirmeyi mümkün kılar (ayrıca her geliştiricinin tercih ettiği Vim vs. Emacs, Chrome vs. Firefox vb.

Yani:

Proje dosyaları Mevcut PC'deki düzeni yansıtabilmek için yolların düzenlenmesi gerekebilir.

Neden her bilgisayarda aynı düzeni kullanmıyorsunuz? Proje içerisindeki yollar proje dosyasına göre olmalıdır; bu, projenin bulunduğu yerin önemli olmadığı anlamına gelir. Yazılımın ve kitaplıkların sürümleri, yalnızca bazı makinelerde görünen şifreli hataları önlemek için aynı olmaktan daha iyidir ve ekibin diğer üyeleri için çoğaltılması imkansızdır.

Örnek:

Visual Studio ile oluşturulan bir projede şunları bulabilirsiniz:

• Dosyaların kendileri. Yolların göreceli olması, ekibimin H:\Development\Hello World Project\diğer üyeleri projeyi kontrol ederken makinemde, projenin içinde olup olmadığı önemli değil C:\Work\HelloWorld\.

• Bağımlılıklar, yani üçüncü taraf ve kurum içi kütüphaneler. Her iki tür de çatışmalarla ilgili tüm tartışmaları modası geçmiş kılan NuGet tarafından ele alınmalıdır. Kütüphanemin aynı sürümüne sahip değilseniz, bağımlılıkları güncellemesini NuGet'ten isteyin. Bu kadar basit (iyi çalıştığında, her zaman durum böyle değil).

  Kurum içi kütüphaneleri özel bir NuGet'te tutmanın çok önemli olduğunu unutmayın. Paylaşılan bir klasörde depolanan veya bir takımın e-posta yoluyla gönderilen bir sürü kütüphaneye sahip olmak anarşi ve depresif CI sunucularına yol açar.

• Ayarlar. Takımın aynı ayarları paylaşması çok önemli. Takımın yarısı uyarılara hata gibi davranmaya karar verirse ve takımın yarısı olduğu gibi uyarılar tutmaya devam ederse, takımın ilk bölümünün üyeleri, geliştiricilerin oluşturduğu uyarıları takımın ikinci bölümünden kaldırarak zamanlarını harcarlar.

• Yardımcı programlar ile ilgili ayarlar. Bunlar aldatıcı, çünkü ekibin bazı üyeleri bazı programları kurmuş olabilir, bazıları ise yüklememiştir.

  Aynı araç setinin kurulu olması şiddetle tavsiye edilir. Bazı programcılar StyleCop kullanmak ister ancak diğerleri kullanmazsa, takım işi yapmaz. Bazıları Kod sözleşmeleri kullanıyorsa, ancak diğerleri kullanmıyorsa, aynı sorunları yaşarlar.

Makefile'lar. Örneğin, optimizasyonun hata ayıklama sırasında kapatılması gerekebilir, ancak CI sunucusu için gerekli olmayabilir.

Sürüm kontrolünde birkaç makefile dosyası bulundurun. CI sunucusunda hata ayıklama sürümü oluşturmak ve onu zor bir hatayla karşılaşan bir müşteriye zorlamak alışılmadık bir durum değil.

Kirli çirkin hackler. Örneğin, bir işlevi test etmek için bir işlevin ortasına 7 geri dönün, işleve bağlı olarak ve 7 değerinde kırıldığından şüphelenilir.

İlk başta böyle bir koddan kaçınırdım. Bir şeyi test etmek için, birim testleri kullanın. Hata ayıklama amacıyla bazı kodları değiştirmek gerçekten birkaç saniye sürerse , o zaman bunu yapın, ancak bu kodu yine de birkaç dakika içinde kaldıracaksınız, bu yüzden bunu onaylamanız gerekmez.

Tanımladığınız gibi bir test yazmalısınız. Örneğin, şunlardan emin olmak istiyorsanız:

class TemperatureConverter
{
    public int CelsiusToFahrenheit(int temperature)
    {
        ...
    }
}

değişmezden temperaturedüşük olduğunda bir istisna atar AbsoluteZero, kodun kendisi ile oynamamanız gerekir. Bunun yerine, şunları yapacak bir birim testi oluşturun:

• kodunuzu kendiniz belgeleyin,
• Kodunuzun güvenilirliğini artırmak,
• yukarıdaki yöntemde değişiklik yaparken, bakıcıların regresyon testine güvenebilmelerini sağlamak,
• aynı testi yapmanız gerekebilecek ekibinizin diğer geliştiricilerine hizmet etmek.

Kullanırız @@ yorumları, herhangi bir şeyin hazır olmadığını, test amacıyla, vb. Belirtmek için kullanırız.

Bu şekilde söz verebiliriz, meslektaşlarım senkronize etmek için çok uzun süre beklemek zorunda değiller ve halen devam etmekte olan işlerin nerede olduğunu görebiliyorlar (örneğin, bir parçanın neden henüz tam olarak çalışmadığını anlamak).

@@Beta testinin son aşamalarına vs. girmeden önce kalanları önlemek için global bir arama yapıyoruz .

Bu disiplini kullanarak, sadece taahhüt etmemek için sebep göremiyorum . Bu şekilde, ayrı dallarımız ve izleyeceğimiz yalnızca bir ekstra 'protokol'ümüz yok.

Ekstra bir fayda olarak, bu yapılacaklar (genellikle küçük şeyler) her zaman koddadır. Üzerinde çalışan geliştirici hızlı bir şekilde üzerinden geçebilir ve ayrı listeler tutmanıza gerek yoktur.
Gelişimin nasıl yürüdüğünü biliyorsunuz: tek bir yerde çalışıyorsunuz ama fikrinizi sürekli olarak yığın olarak kullanıyorsunuz (' Burada işim bittiğinde onu değiştirmeliyim '). Sadece hızlı bir şekilde not düşüyorum@@ notu not almak yığın taşmasını önler.

Hatta @@name'isim' ile tartışmam gereken sorunları belirtmek için kullanıyorum .

2 HAMSTER çözümü:

• HAMSTER gibi sıra dışı bazı anahtar kelimeler için kodunuzu kontrol etmek üzere ön işleme kancası kullanabilirsiniz. İnsanların HAMSTERed kod yazmasına izin vermeyin ve kirli kesmeler yaptığınızda kullanın.

• Örneğin C'deki bir başka seçenek ise #ifdef HAMSTER kullanmaktır, o zaman kod yalnızca makinenizde HAMSTER derleyici bayrağının bulunduğu bir yerde çalışacaktır.

Mevcut ikili dosyaları oluşturmak ve test etmek için gereken her şeyi kaynak kontrolü altına alıyoruz ve olayların neden oldukları gibi tasarlandığını / uygulandığını / test edildiğini anlıyoruz .

Bu , tanımladığınız gibi, http://www.extremeprogramming.org/rules/spike.html gibi çiviler için de geçerlidir ; Onları farklı bir alt ağaçta barındırıyoruz.

Aşağıda, çeşitli koşullar altında zaman zaman kendimi kullandığım ve kendi iş akışlarınıza uygulandığında yardımcı olabileceğinizi düşündüğüm birkaç çözüm vardır:

1. Ezilebilir hafif dalları.

   Git bu konuda harika. Bir şubeye saldırın, çok fazla taahhütte bulunun ve ardından gürültüyü düzeltmek için geçmişinizi yeniden oluşturun veya ezin.

2. SCM'nizin üstünde bir yama sırası kullanın.

   Kendimi StGit'i kullanarak yamaları şu anki dalımın en üstüne çıkarıp buluyorum . Dalla işim bittiğinde, birleştirme, ezme veya yeniden biçimlendirme işleminden önce onları yığından geri çekebilirim ya da etraflarında tutmak istersem bunları ana kod tabanına birleştirebilirim.

3. Kullanım RCS küçük deneyler için bir "out-of-band" SCM olarak.

   Bazen, daha sonra geçmişi temizlemek zorunda kalmadan, devam eden bir dosyayı tek kullanımlık bir şekilde kontrol etmek istersiniz. Tipik olarak Git veya SVN içinde RCS kullanıyorum. Git’e RCS eserlerini görmezden gelmesini, RCS’de devam etmekte olduğum çalışmaları kontrol etmesini ve sonuçları sevdiğimde sadece *,vdosyaları veya tüm RCS dizinini attığımı söylüyorum . git clean -fdxÇalışmanızı "gerçek" SCM'nize taahhüt edene kadar koşma ya da benzeri yapmayın , yoksa pişman olacaksınız.

4. İsimli ziyafetler.

   Başka bir Git-ism, ancak kullanışlı: git stash save --include-untracked <some-cool-title>bir tutam yararlı olabilir. Bu şekilde devam eden işleri kaydedebilir, patlatabilir ve uygulayabilir ve çeşitli kontrol noktalarınızı git stash listveya ile görüntüleyebilirsiniz git reflog --all. Diğer SCM'ler benzer özelliklere sahip olabilir, ancak kilometreniz bununla çok değişebilir.

Bu geçici kodlardan bazıları, gerçekten de yanlış yapılanma / test etme / geliştirme metodolojisinin bir tezahürüdür ve umarım onların varlığı gelecekteki gelişmeleri motive edecektir.

En azından, master / trunk ile birleştirilmeye hazır oluncaya kadar, çok sayıda özellik dalı ile uğraşmakta özgür olmalısınız.

Sürüm kontrolünün size yardımcı olması gerekiyor ve çoğu zaman geçmişte hataların (veya belki de sadece sezgisel kararların altında olduğu) yapılan görüşlerin takdir edilememesi ve şimdiki zaman için daha bilinçli kararlar almamı sağladığımı takdir ediyorum.

Bazı sistemlerin TODO’yu bir yorumda görme konusunda uyarılar alacağına inanıyorum.

// TODO: remove this hack.

geliştirme ortamınızın bir bölümünde ilgili bir seçenek bulabilirseniz ya da buildfile'inize bir çeşit grep komutu eklerseniz, gerekli olan her şey olabilir. Alınacak // HACKherhangi bir dizenin veya herhangi bir dizenin ayarlanması da mümkün olabilir .

Bu, kodunuzu belirli bir şekilde düzenlemek ve insanların kullanmamalarını hatırlamalarını ummaktan daha basittir. Ayrıca, gbjbaanb'ın tavsiyelerine uymayı daha güvenli kılar (eğer herkesin uyarıları görmesini sağlayabilirseniz!).

Orada istediğin her şeyi yap, bir gün ne olduğunu görmek isteyebilirsin ve bunlar, SCM'nizin gerçekte ne olduğunu anladığın günlerdir.

Kaynak denetimine kod koymak hiçbir zaman zararsızdır.

Bahsettiğiniz öğelerin her biri kaynak kontrolünde olmalıdır.