it-swarm-tr.com

Kod ne zaman yapılır?

Bir proje üzerinde çalışırken, kod birkaç hafta/ay/yıl uzun bir süre boyunca tek bir günde veya yavaş yavaş geliştirilebilir. Kod taahhütleri proje geliştirmenin bir ölçüsü olarak kabul edildikçe, daha az kod içeren bir projeden daha fazla kod yazıldığı anlamına gelmez.

Yani soru, depoya ne zaman gerçek bir taahhütte bulunulmasıdır, böylece taahhüt haklı olabilir mi?

Bir ek olarak: Bir projenin gelişimini taahhütlerine göre ölçmek doğru bir uygulama mıdır?

62
user22662

Hatırlamak istediğiniz bir kod tabanı durumuna ulaştığınızda işlem yaparsınız. Belirli bir kod tabanı durumunu hatırlamak isteyebileceğiniz pek çok neden vardır, bu nedenle ne zaman işleneceğiniz konusunda zor ve hızlı kurallar olamaz. Ancak, taahhütlerin sayısı kesinlikle bir kalite veya ilerleme ölçüsü değildir.

80
Neil Butterworth

Kodlamayı bu bağlamda kaya tırmanışı olarak düşünmeyi seviyorum. Biraz tırmanıyorsun ve sonra kayaya bir çapa koydun. Hiç düşerseniz, diktiğiniz son çapa sizi koruyan noktadır, böylece asla birkaç metreden daha fazla düşmeyeceksiniz. Kaynak kontrolü ile aynı; biraz kod yazıyorsunuz ve biraz istikrarlı bir konuma ulaştığınızda bir revizyon yapıyorsunuz. Korkunç bir şekilde başarısız olursanız, her zaman bu son revizyona geri dönebilirsiniz ve bunun kararlı olduğunu biliyorsunuzdur.

Bununla birlikte, bir ekip üzerinde çalışıyorsanız, taahhüt ettiğiniz her şeyin eksiksiz olduğundan, mantıklı olduğundan, temiz bir şekilde oluşturulduğundan ve başkalarının eşyalarını kırmadığından emin olmak gelenekseldir. Diğer insanların çalışmalarına müdahale edebilecek daha büyük değişiklikler yapmanız gerekiyorsa, başkalarını rahatsız etmeden işlem yapabilmeniz için bir şube yapın.

Ayrıca kullandığınız SCM sistemine de bağlıdır. Dağıtılmış sistemler genellikle birleştirme ve çatallama işlemlerini ağrısız ve hızlı hale getirir ve yerel olarak taahhütte bulunabilirsiniz; Bu, çok şey yapmanız ve önemli miktarda iş yaptığınızda Push/birleştirmeniz gerektiği anlamına gelir. Svn veya cvs gibi merkezi sistemlerle işlem yapmak daha maliyetlidir ve herkesi etkiler. Dallanma bu sorunu kısmen çözer, ancak sunucuda olduğu için acı verici yavaş olabilir ve birleştirme hantal olabilir. Merkezi SCM'lerde, genellikle daha dikkatli bir kültür vardır, burada sadece önemli miktarda iş yaptıktan sonra taahhütte bulunursunuz.

Eklentiye gelince: Lütfen bunu yapma. Kod satırları, taahhüt sayısı, bulunan/çözülen hata sayısı, vb., Hepsi kalite ve hatta miktarın çok kötü ölçümleridir.

36
tdammers

Mercurial veya Git gibi DVCS kullanıyorsanız, önemli miktarda iş yaptığınızda yerel deponuza başvurmalısınız. Ancak, yalnızca çalıştıktan sonra paylaşılan depoya aktarın, test edilen bağımsız bir değişiklik.

Dağıtılmamış VCS için (örn. SVN gibi), yerel depo kullanımı yerine ana dalı Push - merge yerine özel dal yerine aynı mantık geçerlidir.

13
vartec

Erken ve sık sık taahhütte bulunmalısınız.

90 saniyede bir sıklıkta iş yapan insanları tanıyorum. Ciddi anlamda. Onlar için işe yarıyor gibi görünüyor. Bir dosyayı her kaydettiğimde, muhtemelen 90 saniyeden daha uzun bir süre çalışmayı denedim. Bugün muhtemelen her 15 dakikada bir taahhüt ediyorum. Birden fazla işlemi bir araya getirmenize ve yerel işlemlerin (git gibi) yapılmasına izin veren bir VCS bunu çok daha kolay hale getirir.

Ne sıklıkla taahhüt etmelisiniz? Söylemesi zor, ama muhtemelen şimdi olduğundan daha sık. Daha fazla ve daha fazla taahhütte bulunmaya devam edin, çok saçma gibi hissettiren bir nokta bulun ve sonra biraz geri çekilin. Muhtemelen makul bir şey elde edersiniz.

Bir ürünün gelişimini, kullanıcılarına sunulan değere göre ölçersiniz. Başka kesin bir ölçüm yoktur.

10
Rein Henrichs

Taahhütler, sürüm kontrollü verilerin/kodların yapı taşlarıdır. Her taahhüt aşağıdakilerden birini yapmalıdır:

  • Yeni bir veri veya işlev parçası ekleme
  • Düzeltmenin olabileceği bir veya daha fazla hatayı (mümkünse her düzeltme için bir taahhüt) düzeltin:
    • Performans iyileştirme
    • Yanlış kod davranışını düzeltme
    • Yazım hatalarını giderme
  • Anlambilimi değiştirmeden kodu veya verileri yeniden düzenleme. Bu içerir:
    • Orijinalle aynı davranan kodu yeniden yazma
    • Verilerin gösterimini farklı bir biçime değiştirme
    • Kod veya verileri projenin biçimlendirme yönergelerine uygun olarak biçimlendirme
  • Başka bir şubedeki değişiklikleri birleştir (yukarı akış/aşağı akış)

Ayrıca şubelerde çalışırken, taahhütler daha uygun bir şubeye gitmelidir. İki taahhüt aynı taahhüt mesajına sahip olmamalıdır (benzer değişiklikleri ima eder), ancak işbirlikçileri karıştırdığı için farklı şubelerde olmalıdır. Daha iyi bir yol ana dal için taahhüt ve özellik dal ile birleştirmektir.

Komisyon üyeleri yukarıdaki kurala uyuyorsa, önemsiz hale gelir:

  • Yan etkisi olmayan belirli bir değişikliği geri alma
  • Kod formatlama değişikliklerinden kod değişikliğini değiştiren davranışı belirleme
  • Çatışmaların çoğunu önleyen farklı şubeler arasında birleştirme
  • Değişikliğinizi kolaylıkla çekebilecek diğer geliştiricilerle işbirliği yapın

Projenin taahhütlere dayalı ilerlemesinin ölçülmesi ile ilgili olarak, Yeniden Düzenleme taahhütleri ve Hata düzeltme taahhütlerinin dikkate alınmaması mümkündür.

8
justjkk

Yalnızca verilen işlevi/modülü/işlevselliği başarılı bir şekilde birim olarak test ettiğinizde ve bunun entegrasyon veya sistem testi için hazır olduğundan makul şekilde emin olduğunuzda taahhüt edin.

Ve eklenti sorularınızı cevaplamak için - HAYIR !! projenin nerede olduğunun ölçüsü asla taahhütlerin sayısına göre belirlenmemelidir ... gerçekte ne taahhüt edildiğini kim bilebilir? Başarılı bir şekilde sistem testinden geçmiş, hatta birim testinden geçmiş mi? Sadece kararlı olduğu için üretime hazır olduğu anlamına gelmez.

7
Catchops

Bir ek olarak: Bir projenin gelişimini taahhütlerine göre ölçmek doğru bir uygulama mıdır?

Hayır. günlük bir WTF vardı bunun neden korkunç bir fikir olduğu konusunda.

Kod işleme konusundaki genel kuralım, bir kod yığınını tamamladığımda ve derlediğinde check-in yapmaktır. Chunk gerçekten tanımlanmamış. Bu küçük bir görevse, bitene kadar check-in yapmayabilirim. Daha büyükse, her mantıksal bölüm tamamlandıktan sonra check-in yapabilirim.

Ancak derlemediğini asla kontrol etmeyin. Yüksek sesle söylemek aptalca bir şey gibi geldiğini biliyorum, ama bunu daha önce insanlara açıklamak zorunda kaldım.

6
Tyanna

Bir şeyi bozduğunu düşünmediğiniz her önemli değişikliği yapın. Taahhüt etmemeniz gereken tek şey stil değişiklikleri çünkü mantıktaki değişimi somutlaştırmıyorlar. Ancak aksi takdirde, yaptığınız değişiklikler ne kadar küçük olursa o kadar iyidir.

Taahhütler ne kadar küçük olursa, iyi bir işlem kaydının bir yönü olan düşünce sürecini daha ayrıntılı olarak belgeleyebilirsiniz. İyi bir kod incelemesi sadece kod sonucu değil, aynı zamanda düşünce süreci ile de ilgili olmalıdır.

Ayrıca, çok sayıda küçük işleme sahip olmak, sürüm denetiminin çok az kullanılan bir özelliği olan iki noktaya ayırmayı kolaylaştırır, bu da bana samanlık kod tabanlarında iğne hataları aramak için saatlerlerce zaman kazandırdı.

Kısaca ikiye ayırma; Geçerli kod tabanındaki bir sorunu keşfedin. Ardından, belirli bir sorun olmadığından emin olduğunuz değişiklik günlüğünde bir taahhüt seçin. "İyi" ve "kötü" sürüm arasındaki ortadaki taahhüdü kontrol ederek başlayın. Sorunun hala mevcut olup olmadığını test edin. Eğer öyleyse, "iyi" ve daha önce test edilmiş taahhüdün ortasına, daha geriye bakmanız gerekir. Sorun giderildiyse, bu spesifik değişiklikten sonra ortaya çıktı, bu nedenle "kötü" ve daha önce test edilmiş taahhüt arasındaki ortaya bakmanız gerekir. Tekrar et. Sonunda sorunu ortaya çıkaran taahhütle sonuçlanacaksınız. Ancak sadece küçük taahhütleriniz varsa, aksi takdirde sorunun hangi büyük yığın yığınında ortaya çıktığını bileceksiniz.

Here , Git ile nasıl çalıştığıdır, ancak yönetici herhangi bir sürüm kontrolü için geçerlidir.

1
Jasper Kennis

Kod, kodun diğer kullanıcılarıyla paylaşılmaya hazır olduğunda - nispeten kararlı, güvenli ve uygun şekilde test edildiğinde - bir taahhütte bulunun.

Ve hayır, taahhütlerin bir projenin gelişimi için büyük bir ölçüt olduğunu düşünmüyorum, çünkü her küçük ve küçük değişikliği yapacak bazı geliştiricileri ve işlevsellikte sadece büyük değişiklikler yapacak bazı geliştiricileri biliyorum. Bir taahhüdün değerini diğerine göre nicel olarak nasıl ölçersiniz?

İlgili görev yapılır yapılmaz . görev , kullanıcı hikayesinin bir parçasıdır.

Aşağıdaki durumlarda bir görev yapılır:

  • ilgili birim pasajı test eder,
  • kod düzgün bir şekilde belgelenmiştir ve
  • kod işlendi.

Farklı bir tamamın tanımı olabilir.

Taahhütlerin sayısını ölçmedeki değeri görmüyorum. Ancak, aynı kullanıcı hikayesinde (veya daha kötüsü hikayelerde) uzun süre çalışan birini görürseniz, bu bir koku.

1
user2567