Prototip ve üretim seviyesi çözümü arasındaki fark nedir?

Bu soru tamamen öğrenmek ve teknik anlayışımı arttırmak içindir. Mükemmel bir çözüm olmadığını biliyorum ve bu sorunun hiç bitmeyen bir çözüm listesi var ama bence her mimarın demo ve canlı bir proje arasındaki farkı anlaması çok önemli.

Geçmişte .Net'te birçok demo çözümü oluşturdum. Şimdi bir üretim düzeyindeki web çözümünü mimar olarak kullanıyorum ve bu yüzden bir demoyu üretim düzeyi bir çözüme dönüştürmek için ne gerektiğini çok yüksek bir seviyede sormak istedim. Anladığım kadarıyla, bu gerekli olacaktır (müşterilerin gereksinimlerini işlevsel olarak uygulamak dışında):

1. Her yöntemi birim test etme
2. ~% 100 kod kapsamının sağlanması
3. Tüm istisnaları ve olası nokta kesimlerini günlüğe kaydetme - AOP ile mümkün
4. Arayüz tasarım deseni kullanarak, bağımlılık enjeksiyonu, muhtemelen spring.net gibi bir çerçeve kullanarak
5. Enstrümantasyon için performans sayaçlarını ve profilerlerini kullanma
6. Uygun güvenlik uygulanıyor - örn. Windows kimlik doğrulaması (istemci tarafından isteniyorsa).
7. Her yöntemde işlem yönetimi
8. Yeni çözüm dağıtımından önce web uygulama dosyalarının yedeklenmesi

Başka?

Sorum daha işlevsel / belgeleme yerine teknik tarafı ile ilgili çünkü aksi takdirde başka bir yola gideceğiz :-)

Teşekkür ederim.

Bence en önemli fark, bir prototipin amacının:
1. Bir sorunun belirli bir şekilde çözülebileceğini kanıtlamak VEYA
2. Müşteriye / yönetime ürünün nasıl görüneceği ve hissedileceği hakkında bir fikir vermek

oysa canlı bir sistemin amacı:
1. Belli bir sorunu çözmek / bir sorunu çözmek.

İkisinin amaçlarının tamamen farklı olduğuna dikkat edin .
Bu nedenle, bence canlı bir sistem geliştirmeden önce bir prototip atılmalıdır .

Bunun nedeni, bir prototipin, sorunuzda haklı olarak işaret ettiğiniz (test, performans, güvenlik ve çok daha fazlası gibi) herhangi bir husus olmaksızın bir araya getirilen genellikle 'hızlı ve kirli' bir proje olmasıdır.
Yani yeni, uygun bir projeye başlamaktan, kötü bir projeyi daha iyi hale getirmekten daha iyi olur.

Gereksinimlerinize bağlı olarak, bunların hepsi gerekli değildir veya daha fazlası gerekebilir. Ne demek istediğimi biliyorsanız;) Birim testi ve kod kapsamı iyi şeylerdir, ancak sürecin diğer bölümlerine nasıl gittiğinize bağlı olarak gerekli olmayabilir. Bazıları, performans profillemesinden daha önemli olanın iyi belgelenmiş bir kod veya bir eğitim kılavuzu olduğunu söyleyebilir. Değişir!

Teknik tarafa baktığınızın farkındayım ama umarım benim açımdan anlayacaksınız, teknik olmayan tarafa bağlı olarak değişir. Ya da en azından öyle olmalı.

Enstrümantasyon için performans sayaçları ve profilerlerin kullanılması uygun olabilir, ancak aşırı derecede aşırı olabilir. Gerekli olmayabilir.

Burada eksik olan şey, projenin bağlamını, kapsamını ve iş gereksinimlerini hesaba katmıyor.

Bağlam ve kapsamla ifade etmek gerekirse - bir işletme tarafından dahili olarak kullanılacak bir şey mi yaratıyorsunuz? Müşteri karşılama? Son kullanıcılar tarafından mı kullanılıyor? Aslında Not Defteri'nin cazip bir versiyonu mu yoksa sıfırdan yeni bir RDBMS mi? Eklenmesi gereken, baktığınız projeye göre büyük ölçüde (büyük ölçüde!) Değişecektir.

İş gereksinimlerine göre, yazılımın kullanım durumlarını değil, proje yönetimi / üretim sürecinin gereksinimlerini kastediyorum. Bir üretim projesi için bunların hepsine ihtiyacınız olduğunda ısrar ederseniz, maliyet buna göre yansıtılacaktır (çok yüksek). Bu, bütçenin üzerinde, geç olduğu veya gelişmeye başlaması için yeşil ışık bile verilmediği anlamına gelebilir.

Şu anda sabit bir kriter setine sahip olmaktan daha iyi bir üretim / geliştirme çerçevesi, yüksek görünürlük ve düzenli sürümlere sahip olmak daha önemli olabilir, böylece kalite bu şekilde değerlendirilebilir. Dahil olan hiç kimse kod kapsamı hakkında bir saçmalık vermeyebilir.

İlginçtir ki, 1, 2, 4 ve 7 numaralı noktaların prototipinizin tasarımı sırasında zaten yapılması gerektiğini düşünüyorum, ancak her sınıftaki her yöntemi test etmeniz gerektiğini düşünmüyorum . Get / set yöntemlerinin doğru davranıp davranmadığını değil, kritik kodu test edin.

Güvenliğinizin büyük bir sorun olduğu başvurunuzun amacına bağlı olarak, 6. nokta prototipte gerçekleştirmeniz için yeterince kritik olabilir. Uygulamanın amacına bağlı olarak, performansın anahtar olduğu nokta, 5. nokta kritik olabilir ... Ne demek istediğimi biliyorsun. Kanımca, kritik kabul edilirlerse prototipte 3, 5 ve 6. noktaların gerekli olabileceğidir (8. nokta üretim uygulamaları için gerçekten geçerlidir)

Düzenleme: Bence benim prototip sjhonny tamamen farklı görünüyor çünkü ben prototip gelecekteki gelişmeler temel / kabuk / iskelet olarak kabul ima, bu yüzden benim için prototip atılmak değildir.

Daha önce bahsedilenlere ek olarak, bir üretim projesinde aşağıdakilere ihtiyacınız vardır (diğerleri arasında):

0-Bir uygulama yöntemi seçin

1-Başlıca gereklilikleri sonuçlandırmak ve yayınlamak (kullanım örnekleri, vb. Dahil)

2-Mimariyi doğru yapın

3-Doğru araçları seçin

4-Performans için tasarım veritabanı

5-Sınıf tasarımınızı ve iş akışı tasarımınızı üretin

6-Desteklenen veritabanlarını / veri kaynaklarını / özet akışlarını entegre etmek için bir strateji belirlemek ve uygulamak

7-Güvenlik gereksinimlerini tanımlayın ve uygulayın

8-Fiziksel uygulama için düzenleme (Sunucular, bağlantı, lisanslar vb.)

9-Depolama gereksinimlerini planlayın ve performans ölçülerini belirleyin

10-Tüm eserleri üretin ve üretim ortamına kurun

11-Testi

12-Nihai çözüm sunun ve geri bildirim uygulayın

Üretim kalitesi çözümlerinin en önemli özelliği bence sağlamlıktır .

Ne olursa olsun, çözüm durumu mantıklı bir şekilde ele alır, bilmesi gerekenleri bildirir ve devam eder (hata kurtarılabilirse).

İki tür prototip vardır:

• "Temizlenen" ve üretim kodu haline gelen hızlı ve kirli "konsept kanıtı" uygulamaları. "Temizlik" aşaması ya bir kabus olma eğilimindedir ya da gerçekten "halının altındaki sorunları süpürme" aşamasıdır ve büyük teknik borçlara yol açar.

• "Mockup" prototipleri veya "tel kafesler". Bunlar, kağıt ve kalem UI çizimleri veya bir araya getirilen etkileşimli maketler olabilir, hatta bu tür şeyleri birbirine nasıl uyduğunun arkasında çok fazla düşünmeden hızlı bir şekilde bir araya getirebilirsiniz. Sahte veri kullanmalı, gerçek mimari vb. Olmamalıdır. Mesele, paydaşlara sistemin nasıl olacağına dair bir fikir vermeleri, böylece gereksinimlerinizi iyileştirebilmenizdir, ancak nihai çözümünüzün bir parçası olarak KULLANILAMAZ. .

İkinci türü tercih ederim. Onlar atılır, çünkü gerçekten bir seçenek yoktur.

Ben demosuz bir proje gibi inşa diyorum, ama şimdi tasarımından demo öğrendiklerini dahil edebilirsiniz. Üretime başladığınızda bile ilk kodlama kötü olabilir. Yine de çoğunu yeniden düzenlemeniz gerekecek.

Ele alınması gereken asıl sorun zamana karşı çıkmanızdır. Karar vericiler demoda çalışmaya devam etmenizi istediğinde, uygulamanın çoğunun hazır olduğu izlenimi altındadırlar, bu yüzden uzun sürmez. Başkalarının, aşırı gerçekçi maketler yerine neden müşterilere eskiz göstermeyi tercih ettikleri konusunda bu mantığı kullandıklarını duydum. Demo koduna dikkat edin çünkü hiç düşünmediğiniz ve muhtemelen bu süreçte belgelemediğiniz sorunları keşfetmiş olabilir. Şimdi bunları dikkate almalısınız (Aşırı basitleştirilmiş, ancak evet, veritabanına örneğin erişilemeyebilir.).

Tüm prototipler ve demolar eşit yaratılmaz. Kodun tamamı değersiz olabilir veya bazı bölümler çok iyi yapılmış olabilir. Bir demo olması fark etmez. Sadece bir legacay uygulaması atmak ve baştan başlamak değil mi? Unuttum sordum.