Hangi dApp geliştirme yolu ilk sürümünüze uyuyor?
Önce 3 kullanıcı işlemi: bir kişinin tamamlaması gereken yolu bize iletin. Doğru geliştirme yolunu seçmek için bunu kullanırız. Seçenekler arasında yeni bir ön yüz, mevcut akıllı sözleşmeler etrafında cüzdan entegrasyonu veya aktivite görünümleri için bir veri katmanı bulunur.
Neyin hazır olduğuna göre seçim yapın. Akıllı sözleşmeler mevcutsa, arayüzlerini ve ağ bilgilerini paylaşın. Değilse, ön yüz ve sözleşme bağımlılıklarını birlikte tanımlayabiliriz. İlk inceleme, kullanıcı işlemlerini, açık kararları ve kilometre taşı kontrollerini kaydeder.
| Geliştirme yolu | Şu durumda seçin | İlk kontrol |
|---|---|---|
| Ön yüz öncelikli | Ürün yolu net ve ekranların uygulanması gerekiyor | Kullanıcı işlemleri ve tasarım materyalleri |
| Cüzdan entegrasyonu | Akıllı sözleşmeler mevcut ve kullanıcıların onlarla etkileşime girmesi gerekiyor | Ağ, sözleşme arayüzü ve işlem durumları |
| Veri katmanı | Ekranların geçmiş, arama veya birleşik kayıtlara ihtiyacı var | Gerekli alanlar ve kaynakları |
Bir dApp her 3 yolu da birleştirebilir, ancak sıralama önemlidir. İlk kullanılabilir akışı engelleyebilecek bağımlılığı belirleriz. Ardından bu işi erken bir aşamaya koyarız. İlgili mühendislik için akıllı sözleşme geliştirme veya daha kapsamlı Web3 geliştirme teklifimizi karşılaştırın.
İşlem haritasından çalışan arayüze 3 geliştirme aşaması
3 aşama, ön yüz, cüzdan davranışı ve veri ihtiyaçlarını aynı ürün yolunda tutar. İlk olarak, kullanıcı işlemlerini onaylarız. Ardından, gerekli hizmetleri bağlarız. Son olarak, tamamlanan akışları üzerinde anlaşılan kriterlere göre kontrol ederiz.
- İşlemleri haritalayın: Kullanıcıların ne yaptığını, zincirin neyi işlediğini ve arayüzün neyi göstermesi gerektiğini listeleriz.
- Parçaları bağlayın: Ekranları, cüzdan isteklerini ve sözleşme okuma/yazma işlemlerini plana göre uygularız.
- Sonucu kontrol edin: Bekleyen, reddedilen ve tamamlanan işlem durumlarını inceleriz. Ayrıca gerekli veri görünümlerini de kontrol ederiz.
- Teslimata hazırlayın: Teslim edilen bileşenleri, bilinen bağımlılıkları ve sorumluluk noktalarını belgeleriz.
Her aşama size somut bir inceleme fırsatı sunar. Bir akış veya ekran hakkında yorum yapabilirsiniz. Genel bir ilerleme notuna güvenmeniz gerekmez. Ürünün ayrıca halka açık bir proje sitesine ihtiyacı varsa, mesajlaşmasını Web3 web sitesi geliştirme ile uyumlu hale getirin.
Çalışma ilerledikçe kararları görünür tutarız. Değişen bir sözleşme arayüzü veya kullanıcı işlemi, kabul kontrolüne karşı kaydedilir. Hangi işin planlandığı gibi kaldığını görebilirsiniz. Ayrıca uygulamaya devam etmeden önce hangi konuda yeni bir karar gerektiğini de tespit edebilirsiniz.
Uygulama öncesi ihtiyacımız olan 5 girdi
5 girdi, kullanıcı davranışı veya sözleşme hazırlığı hakkında tahmin yürütmeden geliştirmeyi haritalamamıza yardımcı olur. Elinizde olanı gönderin. Açık kararları net bir şekilde işaretleyin. Böylece onaylanmış gereksinimleri sorulardan ayırabiliriz.
- Kullanıcı yolu: Bir kişinin dApp'te tamamlaması gereken 3 ana işlem.
- Ağ: Ürünün kullanılması amaçlanan zincir veya ağlar.
- Sözleşme durumu: Mevcut adresler, arayüz dosyaları veya sözleşmelerin hala oluşturulmakta olduğuna dair bir not.
- Tasarım materyali: Varsa ekranlar, bir prototip, tasarım sistemi veya ön yüz deposu.
- Veri görünümleri: Her ekranın görüntülemesi gereken geçmiş, kayıtlar veya sözleşme değerleri.
Başlamak için kısa bir taslak yeterlidir. Token ile ilgili ürünler için dağıtım durumunu ve sözleşme ayrıntılarını ekleyin. Bu iş hala açıksa token oluşturma ve dağıtım bölümüne bakın. Kullanıcıların ayrıca ayrı bir cüzdan ürününe ihtiyacı varsa, gereksinimleri kripto cüzdan geliştirme ile karşılaştırın.
Bu girdiler, kilometre taşları üzerinde anlaşmadan önce engelleyicileri belirlememize yardımcı olur. Örneğin, bir ekran işlem geçmişine bağlı olabilir. Bu ekranın, geçmiş için tanımlanmış bir kaynağa ihtiyacı vardır.
İlk inceleme, bağımlılığı ve veri yoksa kullanıcıların görmesi gereken görünür durumu kaydeder. Taslağı göndermeden önce her teknik seçimi netleştirmeniz gerekmez.
İnceleme aralıkları bir dApp geliştirmesine nasıl uyuyor?
İnceleme aralıkları, keyfi takvim vaatlerini değil, çalışan ürün alanlarını takip eder. İlk kullanıcı akışı, cüzdan davranışı ve gerekli veri görünümleri için bir inceleme noktası belirleriz. Ardından sıralamayı bağımlılıklarınıza göre onaylarız.
| İnceleme aralığı | Neyi kontrol ederiz | Sizin gönderdiğiniz veya incelediğiniz |
|---|---|---|
| Akış incelemesi | dApp'teki ana rota | Kullanıcı işlemleri, metin ve ekran geri bildirimi |
| Cüzdan incelemesi | Bağlantı, ağ ve işlem durumları | Sözleşme arayüzü ve beklenen cüzdan davranışı |
| Veri incelemesi | Gerekli alanlar, geçmiş ve yükleme durumları | Örnek kayıtlar ve kaynak ayrıntıları |
| Teslimat incelemesi | Üzerinde anlaşılan bileşenler ve sorumluluk notları | Son yorumlar ve alıcı ekip iletişimi |
Yazılı plan, ilk inceleme aralığını ve hazırlık kontrollerini belirler. Belirli bir ekran, işlem durumu veya veri görünümü hakkında geri bildirim gönderebilirsiniz. Mobil bir arayüz için, Web3 mobil uygulama geliştirme aracılığıyla paylaşılan davranışı ayrıca haritalayabiliriz.
Varsayılan yanıt süremiz 1 iş günüdür. Çalışma, onaylanan ödemenin ardından 24 saat içinde başlar. Yazılı plan, inceleme temposunu belirler. Neyin hazır olduğunu ve hala hangi girdiye ihtiyacımız olduğunu görebilirsiniz.
Yayın öncesi: çözülmesi gereken 3 bağımlılık
3 bağımlılık son bir kontrolü hak eder: sözleşme davranışı, cüzdan yönetimi ve görüntülenen her veri görünümünün arkasındaki kaynak. Bunları kabul kontrollerinin yanına kaydederiz. Ekibiniz, teslimattan sonra dApp'in neye dayandığını görebilir.
- Sözleşme hazırlığı: Üzerinde anlaşılan kullanıcı işlemleri tarafından kullanılan arayüz ve ağ ayrıntılarını onaylayın.
- Cüzdan durumları: Ürünün reddedilen bir isteğe, ağ uyuşmazlığına veya bekleyen işleme verdiği yanıtı kontrol edin.
- Veri sahipliği: Her görünüm için kaynağı ve yayın sonrası kimin izleyeceğini belirleyin.
Cüzdan sağlayıcıları davranışlarını değiştirebilir. Harici indeksleme hizmetleri kesintiye uğrayabilir, eksik veriye sahip olabilir veya uyumluluk değişiklikleri yaşayabilir. Üzerinde anlaşılan entegrasyonu ve arayüz durumlarını doğrulayabiliriz, ancak bu üçüncü taraf koşullarını kontrol edemeyiz veya gelecekteki kullanılabilirliği vaat edemeyiz.
Son inceleme için, kontrol edilen akışları, veri görünümlerini ve kalan bağımlılıkları teslimat notlarına kaydederiz.
Ekibiniz, belirsiz bir tamamlama mesajı değil, bakımını yapabileceği pratik bir kayıt alır. Bize kullanıcı yolunuzu, ağı ve sözleşme durumunuzu gönderin. Bu 3 girdiyi inceleyecek ve incelemeden sonra yazılı bir teklifle döneceğiz.
Nasıl çalışır
- Kullanıcı yolunu gönderinAna işlemleri, hedef ağı ve mevcut sözleşme durumunu paylaşın. Varsa ekran, tasarım veya kodlarınızı ekleyin.
- Bağımlılıkları inceleyinCüzdan davranışını, veri ihtiyaçlarını ve sözleşme arayüzlerini kontrol ederiz. Kilometre taşları ve kabul kontrolleriyle birlikte yazılı bir plan alırsınız.
- Geliştirmeyi onaylayınHangi ön yüz, cüzdan ve indeksleme işinin ilk sürüme ait olduğu konusunda anlaşırız. Plan, dahil edilen işi onaylar.
- Geliştirin ve inceleyinÜzerinde anlaşılan ürün yolunu uygular ve ekranlar, işlem durumları ve veri görünümleri için inceleme noktaları gösteririz.
- Kontrol edin ve teslim alınTamamlanan akışları inceler ve teslim edilen bileşenler, bağımlılıklar ve sorumlulukları kapsayan teslimat notları alırsınız.
Sık sorulan sorular
dApp geliştirme talep etmeden önce ne göndermeliyim?
3 faydalı öğe, ana kullanıcı işlemleri, hedef ağ ve sözleşme durumudur. Varsa arayüz dosyalarını, adresleri, tasarımları veya örnek veri görünümlerini ekleyin. Bir karar hala açıksa, açıkça etiketleyin. Bunu bir gereklilik olarak değil, ilk inceleme sırasında bir soru olarak kaydederiz.
Ekibimizin halihazırda sahip olduğu sözleşmeler etrafında geliştirme yapabilir misiniz?
Mevcut sözleşmeler: evet, bunlar başlangıç noktası olabilir. Arayüz dosyalarını, adresleri ve ilgili ağları gönderin. Kullanıcıların yapması gereken işlemleri ekleyin. Ön yüzün bu sözleşmelerden nasıl okuduğunu veya onlara nasıl yazdığını inceleriz. Ardından, üzerinde anlaşılan ürün yolu için cüzdan durumlarını ve kabul kontrollerini belgeleriz.
Her dApp'in indekslemeye ihtiyacı var mı?
İndeksleme: hayır, her dApp için gerekli değildir. Yalnızca mevcut sözleşme değerlerine ihtiyaç duyan bir dApp, bunları doğrudan okuyabilir. Aranabilir geçmiş, birleşik kayıtlar veya aktivite görünümleri indeksleme gerektirebilir. Kullanıcılarınızın ihtiyaç duyduğu ekranlara ve veri alanlarına göre karar veririz. Ardından, geliştirme planında her görünümün kaynağını belirtiriz.
Bir dApp geliştirme süresini ne etkiler?
İnceleme aralıkları, sabit bir takvim vaadini değil, ürün alanlarını ve bağımlılıkları takip eder. Hazır sözleşmeleri olan bir ön yüz, kararlaştırılmamış kullanıcı akışları veya veri kaynakları olan bir geliştirmeden farklı bir çalışma gerektirir. Girdilerinizi inceledikten sonra kilometre taşlarını belirleriz. Ardından, üzerinde anlaşılan her kontrol noktasında neyin hazır olduğunu gösteririz.
Bir dApp birden fazla ağı destekleyebilir mi?
Birden fazla ağ: evet, her biri için sözleşmeler ve kullanıcı akışları net olduğunda mümkündür. Ağ listesini ve mevcut sözleşme ayrıntılarını gönderin. Hangi ekranların ve cüzdan durumlarının paylaşılabileceğini haritalarız. Ayrıca, uygulama planı üzerinde anlaşmadan önce nerede ayrı bir işlem yapılması gerektiğini belirleriz.
Son dApp teslimatı neleri içerir?
Teslimat: üzerinde anlaşılan uygulama bileşenleri ile bağımlılıklar ve sorumluluklar hakkında notlar. Ayrıca kontrol edilen kullanıcı akışlarını, cüzdan durumlarını ve veri görünümlerini kaydederiz. Ekibiniz nelerin incelendiğini görebilir. Kalan üçüncü taraf veya sözleşme bağımlılıkları, yayın sonrası takip için belirlenir.
Projenizi anlatın
Dört hızlı soruyu yanıtlayın, yöneticiniz bir saat içinde plan, zamanlama ve fiyat aralığı göndersin. Her şey gizli kalır.
Form yükleniyor…