Çalışmayan kodları işlemek hiç doğru mu?

Sadece çalışma kodunu vermeyi istemek iyi bir fikir mi?

Bu taahhüdün, depoyu çalışma durumunda bırakması gerekmez:

• ... tasarımın erken aşamalarındayız, kod henüz kararlı değil.
• ... projedeki tek geliştirici sizsiniz. İşlerin neden işe yaramadığını biliyorsun. Ayrıca, hiç kimsenin çalışmalarını bozuk kod işleyerek durdurmazsınız.
• ... kod şu anda çalışmıyor. Bunun üzerinde büyük bir değişiklik yapacağız. İşler çirkinleşirse geri dönecek bir noktaya sahip olmak için söz verelim.

• ... zincir uzun, yerel şubede bozuk kod varsa sorun yok. yani

  1. yerel dosyalar
  2. evreleme alanı
  3. yerel şubede taahhüt eder
  4. uzak kişisel özellik dalında taahhütte bulunur
  5. uzak developdal ile birleştirme
  6. uzak masterdal ile birleştirme
  7. uzak releasedal ile birleştirme

• ... erken taahhüt, sık sık taahhüt.

Bu yüzden yukarıdaki bağlantılı soruda cevapların çoğunluğu, derlenemez kod uygulamanın yerel ve özellik dallarında sorun olmadığını söylüyor. Neden? Kırık bir taahhüdün değeri nedir?

Eklendi: Yerel grupta bir kişinin istediği şeyi yapabileceğini söyleyen birkaç yüksek oylu yorum var. Ancak, sorunun teknik tarafı ile ilgilenmiyorum. Daha ziyade, sektörde uzun yıllar çalışmış insanların alışkanlıklarını en verimli hale getiren en iyi uygulamaları, alışkanlıklarını öğrenmek istiyorum.

Çok büyük cevaplara hayran kaldım! Beni kodumu düzenlemek için dallar kullanma konusunda usta olmadığım sonucuna vardılar .

Dallanma felsefelerinden biri ( Gelişmiş SCM Dallanma Stratejilerinde Dallanma Stratejisi ve Kod Çizelgesi Politikası Geliştirme bölümü - aynı zamanda Performansı En İyi Uygulamalarını okuyun , pdf, ancak başka ayrıntılara da giriyor), uyumsuz politikalara dallı olmanızdır.

Bir codeline politikası, codeline için adil kullanımı ve izin verilen check-in'leri belirtir ve codeline SCM için gerekli kullanıcı el kitabıdır. Örneğin, bir geliştirme kodeli politikasının serbest bırakılmadığını belirtmesi gerekir; Aynı şekilde, bir sürüm kodunun politikası, onaylanmış hata düzeltmelerindeki değişiklikleri sınırlamalıdır. Politika ayrıca, kontrol edilmekte olan değişikliklerin nasıl belgelendirileceğini, hangi incelemenin gerekli olduğunu, hangi testlerin gerekli olduğunu ve check-in işlemlerinden sonra kodel istikrarının beklentilerini de tanımlayabilir. Politika, belgelendirilmiş, uygulanabilir bir yazılım geliştirme süreci için kritik bir bileşendir ve SCM bakış açısına göre politika içermeyen bir kodlayıcı kontrol dışıdır.

(Best Practices Uygulamasından)

Diyelim ki bir sürümün oluşturulduğu dallar 'sürümü' (veya 'ana') ve geliştiricilerin çalışma kodunu kontrol ettiği yerlerde 'gövde' (veya 'dev') var. Bunlar şubelerin politikaları. 'Çalışma kodunu' 'dev' şube politikasının bir parçası olduğuna dikkat çekmek gerekirse, hiç bir zaman dev branşına bozuk bir kod vermemelisiniz. Genellikle, bu şubelere bağlı CI sunucuları ve bozuk kodda dev'leri kontrol etmek herkesin dalını karıştırabilir ve yapıyı bozabilir.

Ancak, çalışmayan kısmi kodları kontrol etmenin uygun olduğu zamanlar vardır. Bu gibi durumlarda, biri dallanmalıdır - ana hat ile uyumsuz bir politika. Bu yeni dalda politika karar verilebilir ('bozuk kod tamam') ve sonra ona kod verebilir.

Bir kodelin dallanıp ayrılmayacağını belirlemek için basit bir kural vardır: kullanıcıları farklı check-in politikalarına ihtiyaç duyduğunda dallanmalıdır. Örneğin, bir ürün sürümü grubunun zorlu testleri zorlayan bir giriş politikasına ihtiyacı olabilirken, geliştirme ekibinin kısmen test edilmiş değişikliklerin sık sık kontrol edilmesini sağlayan bir politikaya ihtiyacı olabilir. Bu politika ayrışması bir kod satırı için çağrı yapar. Bir gelişim grubu diğerini görmek istemediğinde

(Best Practices Uygulamasından)

Bunun, güçlü bir kurumsal zihniyete sahip merkezi bir sunucu tabanlı SCM'den geldiğini fark edin. Temel fikir hala iyi. Bunlar genellikle örtük olarak düşünülür - denenmemiş dev kodunu sürüm dalına girmezsiniz. Bu bir politika.

Öyleyse şube, bu şubenin kodunu bozabileceğini ve kabul edebileceğini söyleyin.

Linus Torvalds'ın önerdiği felsefelerden biri, yaratıcı programlamanın bir dizi deney gibi olması gerektiğidir. Bir fikrin var ve onu takip et. Her zaman işe yaramıyor, ama en azından denedin. Geliştiricileri, yaratıcı fikirleri denemeleri için teşvik etmek istiyorsunuz ve bunu yapmak için, bu deneyi denemek için ucuz ve kurtarılması ucuz olmalı. Git'in bu kadar ucuz olmasının (hızlı ve kolay) gerçek gücü budur. Geliştiricilere başka türlü sahip olamayacaklarını denemelerini sağlayan bu yaratıcı paradigmayı açar. Bu git kurtuluşudur.

Evet, bir serbest bırakma şubesi olmadığı sürece.

Kişisel branşlarda, deney işe yaramadıysa her şey gider ve sonra atılabilir. DVCS'nin temel faydalarından biri: özgürlük

Bozuk kod vermenin değeri ?: işbirliği ve deneme

Evet, sorun değil bu benim yaptığım çok şey.

Derlenemeyen bir kod verme (en azından dallarda), bazen kodunuzun devam eden bir çalışma olduğu, ancak şu ana kadar yapılan çalışmaların başkalarıyla paylaşılmaya ve / veya paylaşılmaya değer olduğu

Uygulamalarım:

• önce testleri yaz
• silme (devam eden çalışma) taahhütleri iyidir
• Sık sık (bir gün içinde çoklu) ve erken ('çalışma' adımlarını kaydet)
• her işlemden sonra itin (sabit sürücüleriniz çökerse / otobüsün size çarpması durumunda).
• her zaman önce dallarda çalışır
• mümkünse sadece master için çalışma kodunda birleştirme
• master birleşmeden önce wipleri ezmek için git interaktif rebase

Asıl mesele ve belki de dokunduğunuz konu, temelde çalışan ve iş için şiddetle ihtiyaç duyulan bir özelliğe sahip olduğunuz (ve dolayısıyla 'usta' olması gereken) ancak bazı başarısız testler yapmanızdır. Buradaki seçeneklerden biri, şimdilik ilerlemenizi sağlayan bekleyen bir test yapmak olabilir. Bununla birlikte, test hiçbir zaman sabitlenemeyeceği için tehlike altındadır ve diğerlerini test etmek yerine basitçe 'beklemede olan' kırık testler için bir model oluşturabilir.

Başka bir seçenek, şubeyi geçici olarak kullanmak ve dağıtmak olacaktır. Bu, bazı durumlarda yardımcı olabilir, ancak genellikle önerilmemektedir ve sürdürülebilir değildir.

Belki de en iyi seçenek, temel olarak yazılım geliştirmeye daha profesyonel bir yaklaşım benimsemek ve gerçekten herhangi bir taahhüt edilmiş kod için çalışma testleri gerektiriyor. Bu, çoğu insanın hayal ettiği kodlamanın değil, sıklıkla yazılım geliştirmenin 'zor' kısmıdır. Daha iyi bir yaklaşım, muhtemelen çevik gelişim sırasında daha iyi başlangıç ​​tahminleri, kaynak tahsisi, öncelik belirleme, vb. Artı gerektirecektir; bunlar hem ortaya çıktıklarında hem de işaretleme seansları sırasında sorunları çözmek için yeterli zaman ve yeterli disiplinin kullanılmasını gerektirir.

'Yapılmış olanın' ne anlama geldiğine odaklanın, kod anlamına gelir VE testler yazılır, yeniden düzenlenir ve çalışır. "Çoğunlukla yapıldı, sadece yazma / düzeltme / refactor testleri yazmanız gerekiyor, sonra yapılmadı" gibi yorumlar duyuyorsanız, böyle bir şey yapılmadı. Teknik olarak tamamlanmadan bir özellik yapıldığını söylemek, genç programcıların en yaygın hatalarından biridir.

Herhangi bir taahhüdün değeri, bozuk veya değil, kodun bir sunucuya atanmasıdır. Profesyonel ortamlarda, bu sunucu güvenli, yedekli ve yedeklemeler çalışıyor. Bütün gün çalışırsam, taahhüt, yerel makineme ne olursa olsun, kodumun hayatta kalmasını sağlamanın bir şeklidir. Sabit diskler ölür. Dizüstü bilgisayarlar kaybolur veya çalınır. Bina yanmış olsa bile depo sunucusunun yedekleri kullanılabilir.

Bunu bu şekilde düşün. Bir geliştirici olarak, yaptığınız en rahatsız edici şeylerden biri, ekibinizdeki diğer geliştiricilerin görevleri üzerinde çalışmasını engellemektir.

Yalnızca çalışma kodunu işleme felsefesi, depodaki aynı tek bagajda çalışan geliştirme ekiplerinden gelir. Şu anda delilik görünebilir, ancak 10 yıl önce, bu normal çalışma şekliydi. İstikrarlı bir sürüm oluşturmak istediğinizde bir dal görünür, ancak bir dalda çalışan bir geliştiricinin yeni bir özellik uygulamak için düşüncesi neredeyse hiç duyulmamıştır.

Ortamınız, taahhütlerinizin diğer geliştiricileri derhal etkilemeyeceği anlamına gelirse, sık sık taahhütte bulunun. kodunuzda size daha fazla güvenlik sağlar, bir kod hatasını geri almayı kolaylaştırır ve birçok kaynak kontrol sistemi size (tümü olmasa da) taahhüt edilen koda bazı kod koruması sağlar.

Şimdi, diğer geliştiricilerle paylaşılan şubelerle birleştirme işlemlerinin işe yaradığından ve bu seviyeye getirdiğiniz herhangi bir kodun derlendiğinden emin olmak, tüm ünite testlerini ve diğer takım bazlı akıl kontrollerini geçemez… barda bira almaya devam ...

Sürüm kontrolünüzle nasıl çalışacağınız konusunda dogmatik olmaya başlamadan önce, sürüm kontrolüyle neden çalıştığınızı düşünmeye değer .

Sürüm kontrolüne geçilmesi, ileride başvurmak üzere kodunuzun durumunu dondurur - diğer her şey bunun dışında kalmaktadır. Farklılıklara bakmak ve yamalar yapmak sadece anlık görüntüler arasında kodun nasıl değiştiğini görmek demektir. Dallar ve etiketler, yalnızca anlık görüntüleri düzenlemenin yoludur. Kodun diğer geliştiricilerle paylaşılması, belirli bir anlık görüntüye bakmalarına izin verir.

Ne zaman taahhüt etmelisin? Makul bir olasılık olduğunda gelecekte kodunuzun durumuna (veya bir değişikliği açıklayan taahhüt mesajına) bakacaksınız.

Git, fotoğraflarınızı nasıl organize edeceğiniz konusunda size büyük bir esneklik sağlar. Merkezi bir depo yoktur, böylece durumunuzu 'ana' depoya zorlamadan kodunuzu diğer cihazlarla paylaşabilirsiniz. Bir dizi durumun ayrıntılarını ana kodun anlatımından izole etmek için dalları kolayca oluşturabilir, birleştirebilir ve silebilirsiniz. Şu andaki gelişmenizi takip etmenize yardımcı olmak için yerel olarak taahhütte bulunabilirsiniz ve ardından başkalarının görmesi için zorlamadan önce her şeyi tek bir taahhütte toplayabilirsiniz. Belirli revizyonları daha sonra kolayca bulabilecekleri şekilde etiketleyebilirsiniz.

KISS . Küçük bir projenin geliştirilmesinin ilk aşamalarında tek bir geliştirici için en iyisi, on yıllık, kritik bir sistemde çalışan yüz geliştiriciniz olduğunda yapmanız gerekenden tamamen farklı olacaktır. Herhangi bir yazılım geliştirme sürecinde, başkalarının size yapmasını söylediği için gereksiz eserler yaratmaktan kaçınmalısınız .

Dalları Oluştur / Bırak

Bir derleme dalına asla kasıtlı olarak bozuk kod vermemelisiniz. Sürekli entegrasyon altında olan veya serbest bırakılan ya da günlük inşa edilen herhangi bir şube her zaman potansiyel olarak serbest bırakılabilir bir durumda olmalıdır.

Diğer Şubeler: Genellikle Devleti Koruyun

Özel veya özel dallar için hedefler genellikle farklıdır. Sık sık check-in yapılması (çalışıyor olsun veya olmasın) istenebilir. Genel olarak, mevcut duruma geri almak için ihtiyaç duyacağınız herhangi bir zamanı yapmak isteyeceksiniz.

Kaydedilen durumun önemli bir fayda sağladığı bu örnekleri göz önünde bulundurun:

• Global bir arama ve değiştirme işleminden hemen önce bir taahhütte bulunabilirsiniz, böylece işler ters giderse ağacınızı tek bir işlemde geri alabilirsiniz.
• Karmaşık bir kod parçasını yeniden gözden geçirirken bir dizi geçici işlem gerçekleştirebilirsiniz, böylece işlem sırasında bir şeyi kırarsanız ikiye bölebilir veya geri sarabilirsiniz.
• İstediğiniz zaman geçerli çalışma ağacının durumuna geri dönerken deneysel bir şey denemek istediğinizde bir taahhütte bulunabilir, yeni bir şube açabilir veya bir etiket oluşturabilirsiniz.

Bazı kırık kod tabanlarını kullanmak, yerel olduğu sürece tamamdır.

Neden?

• Taahhüdünüzü gelişiminizde bir tasarruf noktası olarak kullanmak çok önemlidir.
• Size ürünü geliştirirken kullanılan düşünce kalıplarını gösterir.
• Bu işbirliğini sonu yok .

Bununla birlikte, bir programcı ekibi olduğunda, programlama evinin felsefesi her şeyden önemlidir ve bireysel davranış davranışlarının yerini alır. Bazı programlama sistemleri, tüm ilerlemeleri kaydetmeye karar verirken, diğerleri yalnızca bir özelliği çözen kodları işlemeye karar verir. Bu durumda, yapılan bir taahhüdün değeri ( yazılım yönetimi bakış açısından maliyet ) korkunçtur:

1. daha fazla özellik için kullanılan zaman şimdi hataları düzeltmek için harcanıyor
2. gelişme kesintisi karşılanmadı ...
3. ürün zamanında sevk edilmez

Etkilerini üstel bir şekilde eriten bir şirkete katlanarak bu üçe diğer noktalar da eklenebilir ... tabii ki, bu kötü alışkanlığın kötü kodlama taahhüdünün bir etkisi olmalıdır.

Bozuk kod vermenin uygun olduğunu sanmıyorum.

Olursa ne olur

• Acil bir düzeltme gerekiyor. Kod tabanı bozuk durumda. Geri almak, düzeltmek ve dağıtmak zorundasınız.

• Başka biri aynı kodda çalışmaya başlamış ve kodunuzu bozduğunuzu bilmiyor. Değişikliklerinin bir şeyleri bozduğunu düşünerek 'kırmızı ringa balığı' peşinde koşuyor olabilirler.

• Şirketten ayrılmaya, tatile gitmeye veya herhangi bir sebeple işe gelememeye karar veriyorsunuz. Meslektaşlarınız neyin kırıldığını ve niçin kırıldı halde bulunduğunu bulmak için derin kazmak zorunda kalacaklar.

• Birisi 'bozuk kodunu' konuşlandırıyor mu? Kişisel verilerle veya ödeme sağlayıcınızla çalışıyorsanız, bu bir oyun bitti olabilir.

@WarrenT Cevapla

Herkesin bir özellik dalında çalıştığı ideal bir dünyada, çalışma dışı kod işlemek işe yarayabilir. Büyük projeler üzerinde çalıştım ve o zaman bile birden fazla kişinin tek bir özellik dalında çalışması gereken durumlar vardı. İnsanların ana şubeye 'çalışmadığını' belirttiklerini de gördüm çünkü serbest bırakma haftaları uzaktı ve ertesi gün düzeltmeyi planladılar. Tüm bunlar bir felakete adaydır ve her ne pahasına olursa olsun kaçınılması gerektiğine kuvvetle inanıyorum.

Çalışmayan kod işlemenin uygun olup olmadığını belirlemenize yardımcı olacak bazı sorular:

1. Fazla mı çalışıyorsun?
2. Takım arkadaşların sürekli yapıyı bozuyor mu?
3. Kod tabanınız dağınık mı ve görünüşte daha kötüsü olamaz mı?

Yukarıdakilerden herhangi birine evet derseniz, evet işe yaramaz kod vermenizde sorun yoktur.

En kısa sürede düzeltmeyi unutmayın, geçerli birim testleriyle örtün ve yapıyı bozduğum için özür dileyin.