Yalnız bir projede özellik sürünmesini nasıl önleyebilirim?

Bu yüzden 2011'de ve 2012'ye kadar üzerinde çalıştığım bir programım var, ancak son sürüm Aralık 2011'de yapıldı . Ben aktif olarak üzerinde çalışıyorum, ama özellik sürünme çirkin başını cezbetti ve şimdi bitmemiş özellikleri ton ile doludur.

Kötü yanı, bir özelliği uygularken, yeni bir özellik içeri giriyor. Gelecekte özellik sürünmesini önlemek için ne yapabilirim ki bir yıldan fazla bir süre içinde bir sürüm yayınlayabilirim ?

Proje iOS'a dayanıyor ve her iOS sürüm güncellemesinin etrafında yayınlar yapıyordu, ancak sonuncusu 5.1 (2011) ile geri döndü. Bu sürekli serbest bırakma döngüsünü geri alabilmek istiyorum, ancak çok zor olduğu kanıtlandı.

Deneyimlerime göre, yapmak istediğiniz şeyin önüne geçmeyen bir geliştirme ve bırakma kadansınız varsa en kolayı budur. İşte böyle yaptım:

1. Özellikleri bir yere not edin ve üzerinde ne kadar çalışmak istediğinizi ve kullanıcıya ne kadar fayda sağlayacağını düşündüğünüzü yansıtan bir puan verin (bunun için gerçek kullanıcılarla bağlantı kurmak mümkün olabilir). Sonra onları bu sırayla yazın.
2. Bir özelliği check-in / itmeden önce, kararlı ve konuşlandırılabilir bir yapıya sahip olduğunuzdan emin olun (bunu kolaylaştırmak için bir CI sistemini düşünün).

Bu şekilde, isterseniz her özellikten sonra bir sürüm gönderebilirsiniz ... veya bir sürümün olmasını istediğiniz değeri sunan bir toplamayı bekleyebilirsiniz.

Not:

• Bir özelliğe asla üzerinde çalıştığınız özellikten daha yüksek bir öncelik verilemez (veya çalışabilir, ancak üzerinde çalıştığınız özelliği kesintiye uğratamaz). Sıradaki gelebilir ama şimdi asla . Bu, şu andan sonrakine gittiğinizde, isterseniz bir sürüm derleme kesme fırsatına sahip olacağınız anlamına gelir.

Cevap trite ve sık sık imkansız: ek özellikler eklemeyi reddet.

Daha derinlemesine, cevap, yeni bir özelliğin özellik sürünme bölmesine düşmesini sağlayan şeyin ne olduğuna iniyor? Sürünme özelliklerinin, işlevselliklerinin sadece projenin amaçlanan kullanımına teğet olmasına ve sürünen özelliklerin gereksiz değil, yararlı olduğuna rağmen, bir projeye eklenen özellikler olduğunu varsayarsak, cevap onları ayırmaktır. , ancak ilgili araçlar. Dik araçları oluşturma ve bunları birbirine yapıştırma Unix felsefesini kullanın.

Proje yönetimi açısından, cevap karşılaştırılabilir. Bir sonraki sürüme ne kadar zaman ayırmak istediğinize karar verin ve bir son tarih belirleyin. Özellikleri tahmin edin ve son tarihi yapacak kadar kesin. Kendinizden başka paydaşlar varsa, kendileri için en önemli olanı seçmelerini sağlayın.

Programlama hakkında iyi bir genel bakış Joel on Software üzerinde bulunabilir:

http://www.joelonsoftware.com/articles/fog0000000245.html

Gelişimdeki en önemli derslerden biri, ne zaman duracağını bilmek.

Tipik olarak, bir geliştirici bir özellik ekler. Bu da daha fazla fikre ilham veriyor. Böylece daha fazla özellik eklenir. Dediğiniz gibi, bir projenin buharlı yazılım haline gelme yollarından biri. Geliştirici projeyi asla 'bitmiş' olarak görmez, bu yüzden asla serbest bırakılmaz.

Almak istediğiniz alışkanlık 'bitmiş' bir proje olarak bir sürüm / versiyon olarak düşünmeyi bırakmaktır. Bunun yerine, kalkınmaya uzun vadeli bir süreç olarak bakın. Sürümleri, bir gün programın nasıl olacağını umduğunuz yol boyunca kilometre taşları olarak düşünün . Böylece, bir sürüm / sürüm sadece uzun vadeli süreçte bir anlık görüntüdür ... iyi yuvarlanmış ve test edilmiş bir anlık görüntü.

Pratik tarafta yapabileceğiniz şey, oturmak ve bir sonraki sürümünüzü belirtmektir. Çok kapsamlı olması gerekmiyor. Bir sonraki sürüm için gerekli olduğunu düşündüğünüz 3-5 yeni önemli işlevsellik parçasını yazın . ( gerçek özellik sayısı, uygulamanın düzeltilmesine bağlı olarak hata düzeltmelerini veya küçük GUI değişikliklerini hesaba katmadan değişebilir ). Başka fikirlerle karşılaşırsanız, sorun değil ... bir sonraki notta not alın ve uygulayın. Bu 3-5 öğeyi tamamladığınızda, sürümünüz beta için hazırdır.

Yeni bir uygulamaya başladığımda, genellikle uygulamanın son 'vizyonunu' düşünürüm. Bu benim için, uygulamanın 3 sürümünde istediğim şey. Bu kıyaslama ile, sağlam sürüm 1'i ne yapacağım hakkında bir fikrim var - sadece temel bilgiler.

Özet:

Her sürümün projenin bitmiş 'vizyonu' olması gerekmez. Bu vizyon için sadece bir kilometre taşı.

Bazı fikirler için bir dal oluşturmanın ucuz olduğu bir sürüm kontrol sistemi kullanın ve onu yayın yolunuzdan uzak tutun. Örneğin git, bazı fikirleri "sonra" uzatabilirsiniz git stash. Daha sonra bu depoları inceleyebilir ve kiraz, ilginç görünen herhangi bir sırayla seçebilir.

Daha büyük özellikler için gerçek bir dal yapın (böylece birden fazla işlem yapabilirsiniz). Vakaya göre: çöp toplayıcısına kuşaksal destek eklemek istediğimde, bir şube yaptım. Stashes dikkat dağıtan küçük şeyleri çok iyi yakalar. Büyük özellikler depo olarak başlayabilir, sonra dallara dönüşebilir ve sonunda hazır olduklarında birleşebilir.

Zarflar ve şubeler ile fikirlerinizi değerlendirebilir, önceliklendirebilir ve yönetilen bir ekip projesi gibi solo projenizin sürümleri için bir kapsam oluşturabilirsiniz.

Bak, bir fikir edindiğinde , bir yere gitmeli ve en iyisi kod : repo. Sürünen özellikler, iyi fikirleri unutmaktan daha iyidir. Ancak, elbette, tüm özelliklerinizi aynı ana hatta kaydırırsanız, kullanıcıların kullanmamaları konusunda uyarılması gereken yarı mamul şeylerle dolu düzensiz sürümleri kesmediğiniz sürece, gecikmeli yayınlamayı geciktirir.