İzleyici Madde İşaretlerini kullanmak için bazı iyi kriterler nelerdir?

Son zamanlarda Pragmatik Programcı'yı ilk kez okuyordum ve Tracer Bullets konseptine rastladım. Geçmişte bu modele göre kodladığımı fark ettim ve beynimde "çevik" olarak çalıştığım şekilde dosyaladım.

Geçmişte nerede kullandıklarına sadece bir örnek veriyorlar. Durumun İzleyici Mermileri için iyi bir aday olduğu tespit edilme şekli

Birçok bilinmeyen ve birçok farklı ortam vardı ve hiç kimse GUI'nin nasıl davranması gerektiğinden emin değildi.

Bu tür, özellikle bir çit fonu için tipik bir iş uygulaması hattında (örnek olarak) teknik olmayan kişilerle çalışırken çok sayıda projenin başlangıcı gibi görünüyor.

Onu kullandım çünkü gerçekten ne denildiğini bilmeden ya da bana açıklamasını yapmadan doğru hissettirdi. Herkesin bir odaya girmesini denediğimde ve her şeyi (veya en azından bazı şeyleri) ön plana çıkarırsam bunun tam bir felaket olacağını biliyordum, ama yine de bu tür bir şey ...

Herkes bu modelin ne zaman gidilebileceği konusunda daha somut kriterler bulabilir mi?

Sadece küçük bir işlevsellik alt kümesiyle doğru yolda olup olmadığınız hakkında fikir edinebileceğiniz bir projeniz olması gerekir. Genellikle bu, temel GUI tasarımı gibi şeyler için mümkündür, ancak sonuçların bilinmediği şeylerle zordur - örneğin bir veri madenciliği uygulaması tasarlıyorsanız ve aracın şekli verilerinizde ne tür desenlerin oluştuğuna bağlı olacaktır.

Ayrıca, birçok kez yineleme yapabileceğiniz bir durumda olmanız gerekir. Bu, zaman ve geliştirmeye mal olur (ve çevik geliştirme süreçlerine abone olursanız elbette faydalı olabilir), ancak kullanıcılara maruz kalma açısından maliyet daha zordur. Çok fazla tasarım gösterirseniz ve geri bildiriminizin kalitesi düşerse, kullanıcılar hızla tükenecek. Yani ya büyük bir kullanıcı havuzuna ihtiyacınız var ya da (mikro) sürümlerinizi dikkatlice seçmek için.

Bir İzleyici Bullet yaklaşımının ne kadar yararlı olduğunu belirleyen sadece tek bir temel faktör olduğunu söyleyebilirim: uygulamanın mimarisi ve tasarımındaki belirsizliklerin sayısı ve kapsamı.

Tekniğin (sadece olmasa da) birincil amacı bu tür belirsizlikleri gidermek olduğundan, mimariniz veya tasarımınız yoksa ya da tasarımla ilgili değilse, bundan çok faydalanamazsınız. Hiçbir mimari kısıtlaması olmayan bir yeşil alan projesi, bir İzleyici Mermisi ile başlamak neredeyse yapılacak tek şeydir, ancak uygulamak için bazı yeni özelliklere sahip olgun bir proje için muhtemelen bir zaman kaybı olacaktır ( gereksinimlerle ilgili belirsizlikler olabilir, bunları temizlemek daha genel çevik veya yinelemeli gelişim alanıdır).

Ship It! Kitabında Tracer Bullet geliştirme kavramıyla karşılaştım . , pragmatik programcılar tarafından düzenlenmiştir .

Sanırım sorunuzda Pragmatik Programcı: Journeyman'dan Master'a kitabından bahsediyorsunuz . Bunu okumadım ve orada TBD'nin nasıl sunulduğunu bilmiyorum. In Gemi It! , TBD'ye ayrılmış bir bölüm (20 sayfa) vardır. Özellikle, somut bir örnekle deneyimlerinden bahsediyorlar: bir biyoteknoloji şirketi için veri madenciliği uygulaması. Temel olarak, (TBD kullanılarak tasarlanan) güzel soyutlama katmanlarına sahip olmanın, her bir katmanı parselleştirerek performans darboğazlarını tek tek kaldırmasına yardımcı olduklarını açıklıyorlar.

Bana göre, TBD iki şeydir:

• Sistem nesnelerini yalıtarak bir yazılım mimarisi oluşturun ve geliştiricilerin bu sistem nesneleri arasındaki arabirimleri tanımlamak için işbirliği yapmasına izin verin
• Mimarinin sürdürülebilir olduğundan emin olmak için sahte nesneleri kullanın (mimariyi erken test edin)

Bence ilk nokta ne olursa olsun bir yazılımı tasarlamak için çok iyi bir yol. İkinci nokta interresting: Uygulamada işe yaramayan bir başlangıç ​​mimarisi nedeniyle bir projenin tamamen yeniden yazılmasını önleyebilir.