Hızlı ana sürüm kötü tasarımın bir kanıtı mı?

Birkaç ay önce genç programcı olarak işe başladım. Üzerinde çalıştığımız sistem ~ 2 yıldır üretimde. Sistemin ya da tasarımın dilenmesiyle ilgilenmedim.

Fark ettiğim bir şey, sistem ana sürümünün zaten 11.YZ Form diğer sistemler ve kütüphanelerle çalışma deneyimimi oluşturması, bu kadar hızlı bir ürün çarpma büyük sürümünü gördüğümü hatırlamıyorum. 1.XY'de yıllardır var olan ve hala özellikler ve hata düzeltmeleri alan ürünler var .

Anlamsal sürüm oluşturmanın doğru kullanıldığını varsayarsak , sistemin neredeyse her dört ayda bir büyük kırılma değişiklikleri yaptığı için kötü tasarlandığını gösterir mi?

Anlamsal sürüm oluşturmanın doğru kullanıldığını varsayarsak, sistemin neredeyse her dört ayda bir büyük kırılma değişiklikleri yaptığı için kötü tasarlandığını gösterir mi?

Şart değil.

Yorumlarda bunun dahili bir API olduğunu belirttiniz. API kodunu kırmak kötüdür, çünkü herkesin kodunu kırıyorsunuz. Ancak dahili bir API için "herkes" sadece "siz" dir ve bu tür API değişikliklerini kendinizle mükemmel bir şekilde koordine edebilirsiniz, bu nedenle genellikle API değişiklikleriyle ilişkili ağrı çok daha kötüdür.

Ayrıca, ortalama büyük ölçüde yanıltıcı olabilir: belki de erken gelişimin ilk birkaç gününde 11 API değişikliği yaptılar ve o zamandan beri 4 yıldır istikrarlılardı? SemVer yapar izin Eğer büyük sayı 0 ise büyük sayısını artırmadan kırılma değişiklik yapma, ama değil zorlamak sizi. Belki prototipleme / keşif aşamalarında bile 0. günden itibaren SemVer kullanmaya başladılar?

Kısa cevap

Hayır

Uzun cevap

"Bazen bir sayı sadece bir sayıdır"

Mevcut çılgın dünyada "anlamsal versiyonlama", "rasyonellik", "mantık" unutun

Chrome neden sürüm numaralarını bu kadar hızlı topluyor?

"sürüm" numaraları, diğer geliştiricilerin bunları kullanma biçimini kamuoyuna uyandırmak için Ana Sürümler değil, şube noktaları için Kilometre Taşları olarak kullanılır. Ve bu, büyük bir etkinlik yapmak için birçok yeni özelliği bir araya getiren, zaman zaman gerçekleşen bir olay yerine, hazır veya hazır olmayan özelliklerle devam eden bir geliştirme akışıdır.

Anlamsal sürümleme kullanılırken, hangi değişikliklerin "büyük" ve "küçük" olarak kabul edileceğine karar verilmesi gerekmektedir. Sürüm numarasını çarpmanın veya çarpmamasının çeşitli nedenleri vardır.

Geriye dönük uyumluluk vaatleri olan sistemler, çoğu veya daha az ezoterik köşe durumunda geriye dönük bir uyumluluk kırılması olduğu için çoğu güncelleme ile büyük sürüm numarasını çarpabilir. Aynı sistemler neredeyse süresiz olarak 1.xy'ye yapışabilir, çünkü geriye dönük uyumluluğa çok fazla çaba harcanır ve hiçbir bağımlı sistemi asla kırmaya çalışmaz. Sürüm numaralandırmaya yönelik her iki yaklaşım da "muhafazakar" olarak kabul edilebilir, ancak her ikisi de derin bir altta yatan sorunun işareti olabilir.

Diğer zamanlarda, ana sürüm numarasını değiştirmenin mantıklı olduğu bir sürüm programınız (müşterilere gönderilen üç aylık güncelleme CD'lerini düşünün), böylece "Sürüm 3.4 / 16 Ekim" yerine "Sürüm 11.0" yazıyor. Günümüzde, giderek daha fazla yazılım kısa aralıklarla piyasaya sürülüyor, bu da sürüm programlarını belirli bir versiyonlama şemasına bağlı kalmak için daha az bir neden haline getiriyor. Bunu, iç BT'ye çeyreklik (genellikle bir pazar) yalnızca bir günlük kesinti süresi sağlayan büyük depo sistemlerinde gördüm. Bu gün dağıtım günüdür ve her seferinde yeni bir ana sürümle işaretlenir.

Bazı programların son derece önemli olan harici bağımlılıkları vardır, çünkü kullanıcının her ikisini aynı anda güncellemesi gerekecektir. Yalnızca Word 2010 ve Word 2013 için başka bir Word ile çalışan bir Word eklentiniz varsa, ana sürüm numaralarınızı MS-Word ile eşitlemek isteyebilirsiniz. Burada, büyük sayılar çok önemlidir, çünkü bazı kullanıcılarınız normal güncelleme programınızın "arkasında" olacaktır, çünkü Word'ün en güncel sürümüne (veya güvendiğiniz başka bir şeye) güncellememişlerdir: SAP, Dynamics, vb).

Bazen, diğer dış faktörler sürüm numaralarını belirler. Mali yazılımınız varsa, vergi yasasına (1 Ocak'ta yürürlüğe girme eğilimi) karşılık gelen yıllık güncellemeler olabilir. Bu tür sistemlerin yılda bir kez tam olarak değişen büyük sürümleri olacaktır - bu güncelleme programı olduğu için değil, bunun müşteri için önemli olduğu için: 2016 vergilerinizi yaparsanız, 2016 vergi kanununa güncellenen programınız daha iyi olur.

Sonunda, sürüm numaraları o kadar çok faktöre bağlıdır - genellikle bir alana özgüdür - tek başına sayı size kod tabanınızın durumu hakkında hiçbir şey söylemez . Dağıtımların ne zaman, neden ve nasıl gerçekleştiğine ve bunun ne kadar sorunsuz gittiğine bakmak çok daha iyi bir yaklaşımdır. 10.000 müşteri için büyük bir güncelleme yapabilir ve birkaç telefon görüşmesi yapabilirsiniz - muhtemelen iyisinizdir. 10 müşteriye küçük bir yama eklerseniz ve bu nedenle fazla mesai yapmak zorunda kalırsanız, bir şeyler yanlış olabilir.

Sürüm numaralarının anlamı hakkındaki görüş birliği aslında major.minor.revision.buildnumber

Eğer büyük bir hızla yükselirse sadece geliştirici tüm bu yeni fikirlere sahip olabilir ve gerçekten çok çalışıyor olabilir.

Ancak iş dünyasında ana sürüm numarasını arttırmanın başka nedenleri olabilir. Sevmek

• Satışlar düştü, müşteriler / kullanıcılar yeni sürüme geçmeden önce büyük bir sonraki sürümü bekliyor.

• Sözleşme, müşterilerin küçük güncellemeler yapma hakkına sahip olduğunu söylüyor. Satıcı, bunlar için ücret alamaz, bu nedenle bazı küçük iyileştirmeler büyük bir ürün yükseltmesi olarak satılır.

• Rakip X oyunda biraz daha uzun sürdü, bu yüzden ana sürüm numaraları sizinkinden daha yüksek. Bu, geride kalıyormuş gibi görünmenizi sağlar, "yakalamanız" gerekir.