Bazen bir yazılımın taahhüt geçmişini kontrol ettiğimizde, gerçekten BÜYÜK olan birkaç taahhüt olduğunu görebiliriz - yüzlerce değiştirilmiş kaynak kod satırı (delta) ile 10 veya 20 dosyayı değiştirebilirler. Böyle bir BÜYÜK taahhüt için sıkça kullanılan bir terim olduğunu hatırlıyorum ama bu terimin ne olduğunu tam olarak hatırlayamıyorum. Biri bana yardım edebilir mi? Programcıların genellikle bu kadar BÜYÜK ve dev bir taahhütte bulunmak için kullandıkları terim nedir?

BTW, hep birlikte bir sürü değişiklik yapmak iyi bir uygulama mı?

GÜNCELLEME: İlham verici tartışma için teşekkür ederim çocuklar! Ama bence "kod bombası" aradığım terimdir.

(1) Ben Collins-Sussman : "..." bombaları kodla ". Yani, biri yazması aylar süren devasa yeni bir özelliği olan açık kaynak kodlu bir projeye göründüğünde ne yaparsınız? binlerce kod satırı? ... "

(2) Dan Fabulich : "Kod Bombası ya da: Büyük Fikirlere Sahip Acemi ... Bir kod bombası , kimsenin inceleyemeyeceği kadar büyük bir yamadır ."

(3) Google Yaz Kodu: Yönergeler : "Erken yapın, sık sık iş yapın ... Lütfen bütün gün çalışmayın ve sonra her şeyi tek bir kod bombaında itin . "log mesajında ​​özetlenmelidir."

(4) Jeff Atwood : "kod bombaları ... Kural # 30: Karanlık gitmeyin . ...

Muhtemelen buna kötü bir taahhüt diyoruz . :)

Kötü uygulama

Ve evet, olumsuz etkileri olduğu için bu genellikle kötü bir uygulama olarak kabul edilir :

• gözden geçirmeyi zorlaştırıyor ,
• o yapım zordur orijinal niyet işlemek kolay ve hızlı kavramak ,
• o yapım zor açıkça düzeltme kodu etkiledi nasıl ya bir sorunu gidermek için ,
• o yapım 's boyutu gürültü nedeniyle işlerlerse zor bilmek diğer olası ilgisiz değişikliklerin (örn küçük temizlikleri veya diğer görevleri) değil ot.

Kabul edilebilir Kılıflar

Ancak, büyük taahhütlerin tamamen kabul edilebilir olduğu durumlara sahip olabilirsiniz . Örneğin:

• zaman dalları arasında birleştirme ,
• ne zaman yeni kaynaklar ekleyerek başka sürüm bilgisi olmayan kod tabanı,
• ne zaman yerinde büyük özelliği değiştirilmesi Eğer artan gelişimi üzerinde daha iyi bir pencere böylece, daha doğrusu küçük onaylatabilirsiniz değişimin farklı bölümlerini ele sahip, bir dalda bunu ve sonra her şey geri birleştirme gerekir gerçi ( özellik ve bu yolla karşılaşılabilecek problemler),
• ne zaman bir API üstlenmeden birçok soyundan ve tüketici sınıfları etkileyen.

Bu yüzden, mümkün olduğunda, “cerrahi grev” -işbirliği türlerini tercih edin (ve bunları sorun izleyicinizdeki görev kimlikleriyle ilişkilendirin!). Geçerli bir nedeniniz varsa, devam edin.

Bunun dışında, aslında bilmiyorum ve büyük bir taahhüt için özel bir isim duyduğumu sanmıyorum. Bir canavar tesadüf mü? Bir yağ-taahhüt?

Güncelleme: David Cary'nin "kod bombası" terimini kullanan en önemli bilişim aktörlerine yanıtları (en önemlisi, Subversion'un orijinal yaratıcısı Collins-Sussman ). Bunun gibi (şimdiye kadar sık ​​sık duyduğumu söyleyemem).

BTW, hep birlikte bir sürü değişiklik yapmak iyi bir uygulama mı?

Değişiklikleri uzun süre sürdürmek, çeşitli özellikler ve hata düzeltmeleri uygulamak ve daha sonra bunları gerçekleştirmek, bu büyük bir taahhüdün gerçekleşmesinin bir yoludur.

Bunun bir başka yolu da, bir yeniden düzenlemenin yaygın olarak kullanılan bir fonksiyonun imzasını değiştirmesi ve ardından tümünün değiştirilmesi gerekmesidir. Bu mutlaka fena değil ve geliştiricilerin bazı eşikleri geçme korkusuyla ilgili kodu temizlemekten kaçınmasını istemem.

Yani, sadece bir taahhütte dokunulan dosya sayısına bakmaktan daha fazlası var.

Duyduğum terim "tıknaz check-in" . Ve ben onların hayranı değilim. Bir projede makul bir adımda başka hiçbir şeyin kırılmamasını sağlayan küçük taahhütleri severim. Büyük taahhüt, genellikle, bunun gerçekleştiği andan itibaren bir süre boyunca yankılanan sorunlarla doludur.

Ben buna "tipik SVN taahhüdü" veya "yarın serbest bırakma günü taahhüdü" diyorum

SVN'yi sevdiğim kadarıyla, yerel taahhütler yapamadığım gerçeği yüzünden kapandım.

EDIT: genellikle taahhüt mesajında ​​"şeyler" ve "bira" kelimelerine sahiptir.

TEKRAR EDİT: Çok fazla değişiklik yapmak, mutlaka kötü bir uygulama olmasa da, mümkün olduğunca kaçınılmalıdır. Kısa ve özlü olan bir revizyon / taahhüdü gözden geçirmeyi daha kolay buluyorum. (iyi yazılmış bir mesajla eşleştirildi, kötü bir örnek için önceki düzenlememe bakın)

Bir "sıcak buharda kod dökümü". :-)

• İlk taahhüt - revizyon kontrolü altında olmayan proje SVN'ye atıldı
• refactoring - mimar, sınıf adlarını Şirin Adlandırma Sözleşmesi'nden / yerine Smurf Ading Convention olarak değiştirmeye ya da paket hiyerarşisinin kökünü değiştirmeye dair mükemmel bir fikir sahibi
• kod formatı - mimar kod girintisini 4 alandan 3 aralığa ya da satır sonunu Unix'ten Windows'a değiştirmeye karar verdi (ya da geri dön)
• Cuma günü taahhüt - Joe her zaman bütün hafta çalışmasını Cuma günleri saat 16: 30'da yapar.
• uuups taahhüt - Ted yanlışlıkla kök dizin silindi, bunu taahhüt etti ve şimdi bir kez daha tüm dosya hiyerarşisini SVN içine pompaladı

Genellikle birçok kişi, merkezi VCS'yi kullanarak büyük bir taahhütte bulunur, özellikle de sunucu iyi bir taahhüt politikası uygular. Taahhüt, tüm testleri geçmeli ve testler daha uzun sürmeli (birkaç saniyeden uzun). Dolayısıyla geliştiriciler, birden fazla kez işlem yapmak ve değişiklikleri birden fazla küçük komisyona bölmek için uzun süre beklemek istemezler.

Ve VCS'ye göre yeşil olan geliştiriciler, değişiklikleri çok sayıda küçük komisyona ayırmayı unutabilir. Yalnızca programı QA ekibine bıraktıklarında taahhüt vermeyi hatırlıyorlar. Daha da kötüsü, başkalarının buggy kodunu görmesini engellemek için, başarılı bir şekilde QA testini geçmeden taahhütte bulunmazlar. Son olarak, gerçekten "büyük" bir taahhüt üreten çıkış ikili dosyaları, geçici dosyalar ve linker çıktıları verdiklerini anlamadılar.