Tam özellikli bir uygulama veya çıplak kemikler oluşturmalı ve sonra yavaşça özellikler eklemeli miyim?

Ben bir atölye planlama programı (çok kötü bir şekilde gerekli) oluşturmak ile BT görev yaptı bir üretim tesisinde çalışıyorum. Başkalarının deneyimlerine dayanarak, daha az zaman ayırıp kullanılabilir olan temel bir çerçeve oluşturmak ve daha sonra özellikler ekleyerek ya da kapıdan tam olarak uygulanmış bir çözüm oluşturarak işe başlamak daha iyi olur. Ben sadece yaklaşık bir yıldır geliştiriciyim ve bu boyutta uygulamaların ilk oluşturulmasında çok fazla tecrübem yok. Bir barebones uygulamasının, bazı dijital program türlerine duyulan aşırı ihtiyaç nedeniyle ilk gitmenin yolu olduğu fikrine doğru eğildim, ancak gerçekten sonra rastgele özellikler eklemenin biraz dağınık olabileceğinden endişe duyuyorum. Aynı durumda olsaydınız hangi yola doğru eğilirdiniz?

Deneyim kesinlikle küçük ve basit bir şey oluşturmaya ve mümkün olan en kısa sürede kullanıcılara ulaşmaya yönlendirir. Özellikler ve yetenekleri kullanıcılar tarafından istendiği şekilde ekleyin.

Şansları çok iyidir (kesin olarak sınırlıdır) istedikleri / istedikleri şeyin kendi üzerine inşa edeceğiniz şeye çok benzememeleri (eğer varsa).

Orijinal uygulamanıza ekledikçe dağınık hale geldiği sürece: Eh, bu yüzden Agile (ve en benzer metodolojiler) test ve yeniden düzenlemeye güçlü bir vurgu yapar. Yeniden düzenleme, kodu değişiklik yaptığınızda temizlemek anlamına gelir ve sağlam bir test paketi (her değişiklik yaptığınızda çalıştırdığınız), hataları tanıtırsanız / uyguladığınızda (neredeyse) hemen bildiğinizden emin olur, böylece bir şey bıraktığınızda kullanıcılarınızın gerçekten işe yaradığına dair makul bir güvenceniz vardır.

Uygulama hakkında ciddi olup olmadıkları hakkında herhangi bir fikriniz var mı, o zaman çerçeve vb. Oluşturmak istemeyebilirsiniz.

Ancak, bir denge bulmanız gerekir. Çevik geliştirme, bu aşamada uygulama için gerekenlere odaklanmanızı önerir, ancak bu, temel tasarımı ihmal ederek kendinizi sınırlamanız gerektiği anlamına gelmez. Kolayca geliyor olarak görülebilecek şeyler var (ve evet deneyim burada bir rol oynuyor) ve bu aşamada hayal edemediğiniz diğerleri (uygulamayı isteyen insanların da onları hayal edemediğinden eminim).

Zamanlama uygulaması ayrıntılarını bilmiyorum ama "randevu türü" yakında karşılaşacağınız bir şey olduğunu hayal edebiliyorum. Belki de insanlar bunu şimdi istemiyorlar, böyle bir işlevsellik beklemek mantıklı değil.

Bu duruma şöyle yaklaşırım: Randevu türlerini tutmak için veritabanında bir tablo oluşturarak altyapıyı (bahsettiğiniz çerçeve) kurarım, ancak türleri eklemek veya seçmek için arabirim oluşturmak için uğraşmazdım. Ben sert bir temel kod ve gerçek özellikleri ile devam ediyorum. Sonuçta, hiç kimse farklı tipte randevular eklemeyi istemedi.

Daha sonra, gelecekte insanlar size bu özelliği sorarak geri dönerse, yapıya sahipsiniz ve sadece orta / ön ucu inşa edersiniz.

Genellikle, başlangıçta tam bir program oluşturmak için yeterli bilgiye sahip değilsiniz. Test ve müşteri geri bildirimleri neredeyse her zaman ilk tasarımınızın teoride olduğu kadar iyi olmayan kısımlarını ortaya çıkarır.

Yani, sorun iyi anlaşılmıştır ve eğer mümkün başlangıçta tam bir programın yazılabilmesi için aksi takdirde sürekli kod üstlenmeden çünkü bu daha iyi ve sonuç baştan izledi katı bir tasarım gibi temiz olarak nadiren.

En azından, programınızın ihtiyaç duyabileceği özelliklerin türü hakkında çok düşünmenin önemli olduğunu düşünüyorum. Bu şekilde, bu özelliklerin mevcut yapıya kolayca eklenebileceği şekilde tasarlayabilirsiniz.

Kişisel deneyimden: MVP'nizi (Minimum Canlı Ürün) oluşturun ve daha sonra aldığınız geri bildirime dayanarak özellikler ekleyin. Tonlarca özellik elde etmek kolaydır ve kimsenin bunları kullanmasını sağlamaz.

Ayrıca, sorunu çözmek için kullandığınız kullanıcı deneyimi de önemlidir. Gerçek kullanıcılarınızla oluşturduğunuz iş akışını doğrulayın ve daha sonra başka özellikler eklemeye devam edin. Bu şekilde, inşa ettiğiniz temel değere odaklanabilirsiniz.