Lemidea · Yayın:
| Görünen sorun | İlk inceleme | Kabul örneği |
|---|---|---|
| Girişten sonra ekran boş | Oturum ve veri isteği | Yeni kullanıcı kendi ekranına ulaşır |
| Kayıt bazen iki kez oluşuyor | Tekrar gönderim ve yazma işlemi | Aynı istek ikinci kayıt açmaz |
| Önizleme çalışıyor, yayın çalışmıyor | Üretim ayarları ve yönlendirmeler | Gizli pencerede kritik akış tamamlanır |
| Kimin hangi veriyi gördüğü belirsiz | Sunucu tarafındaki erişim kuralları | A kullanıcısı B'nin kaydını alamaz |
1. Sorunu bir cümle ve bir örneğe indirin
“Uygulama bozuk” yerine “yeni hesap açan kullanıcı ilk kaydını kaydedemiyor” demek incelemeyi hızlandırır. Beklediğiniz davranışı, yaptığınız adımları ve aldığınız sonucu yazın. Ekran görüntüsü veya kısa kayıt yardımcı olabilir; kişisel bilgileri gizleyin. Sorunu ne zaman ilk gördüğünüzü ve öncesinde hangi değişikliğin yapıldığını da ekleyin.
İlk sürümde mutlaka çalışması gereken üç işi seçin. Örneğin giriş, bir talep oluşturma ve yalnız kendi taleplerini görme. Renk seçici veya yeni bir rapor ekranı bu işleri engellemiyorsa sonraya kalabilir. Birbiriyle ilgisiz sorunları tek büyük istekte değiştirmek, hangisinin düzeldiğini anlamayı zorlaştırır.
2. Kodun ve hesapların kontrolünü netleştirin
Lovable'ın GitHub bağlantısı projeyi depoyla eşitlemek ve kod üzerinde başka araçlarla çalışmak için bir yol sunar. Ancak kodun depoda olması, veritabanı, dosya depolama ve alan adı erişimlerinin de devredildiği anlamına gelmez. Bu kaynakları ayrı bir envanterde listeleyin: hesap sahibi kim, erişim hangi yetkiyle veriliyor, erişim gerektiğinde nasıl geri alınır?
İnceleme başlamadan önce mevcut kodun sürümünü ve geri dönülebilecek noktayı belirleyin. Veritabanında değişiklik gerekiyorsa yalnız kod yedeğine güvenmeyin; verinin yedeklenmesi ve geri yüklenmesi ayrıca ele alınmalıdır. İlk görüşmede hesap parolası veya canlı müşteri verisi paylaşmak gerekmez. Önce sorunu ve gereken erişimin kapsamını belirlemek yeterlidir.
Kaynak: Lovable — GitHub ile eşitleme ↗
3. Ekrandan veritabanına kadar izleyin
Kaydet düğmesinin yeşil görünmesi, kaydın saklandığını kanıtlamaz. Test verisiyle bir işlem yapıp sayfayı yenileyin, ardından aynı hesabın yeni oturumunda sonucu kontrol edin. Böylece yalnız ekranda tutulan geçici bilgi ile kalıcı kaydı ayırabilirsiniz. Başarısız ağ isteğinde kullanıcıya ne söylendiğine de bakın.
Kabul listesine eksik alan, bağlantı kesintisi, tekrar tıklama ve süresi dolmuş oturum ekleyin. Bunlar farklı ürünlerde tekrar eden gerçek kullanım durumlarıdır. Örneğin sunucu kaydı oluşturduğu halde tarayıcı yanıtı alamadıysa ikinci gönderim yeni kayıt açmamalıdır. Düzeltmeyi önce bu küçük senaryoda doğrulayıp sonra diğer ekranlara taşıyın.
4. Görünmeyen düğmeyi erişim kontrolü sanmayın
Bir yönetim düğmesini gizlemek tek başına veriyi korumaz. Test için iki ayrı normal kullanıcı oluşturun ve birinin diğerinin kaydına erişemediğini sunucu tarafında doğrulayın. Gizli anahtarların tarayıcı paketine girmediğini kontrol edin. Bu denemeleri gerçek müşteri kayıtlarıyla yapmayın.
Lovable'ın güvenlik araçları bazı yaygın sorunları incelemeye yardımcı olur. Belgelerde bu kontrollerin tüm güvenlik ihtiyaçlarını kapsamadığı da açıklanır. Tarayıcıda uyarı görünmemesi, uygulamanın tüm iş kuralları ve erişim senaryolarının doğru olduğu anlamına gelmez. Belirlenen bulguların uygulama üzerindeki etkisini ayrıca doğrulayın.
5. Yayını ayrı bir teslim olarak ele alın
Önizlemede çalışan proje ile ziyaretçinin açtığı yayın adresi aynı koşullara sahip olmayabilir. Lovable'ın yayın akışını ve kullanılan arka uç ayarlarını kontrol edin. Giriş dönüş adresleri, ortam ayarları ve varsa ödeme sisteminin test/gerçek ortam ayrımı doğru olmalıdır. Kod değişikliklerinin hangi işlemle yayına çıktığı teslim notunda açıkça yazılmalı.
Kabulü geliştiricinin açık oturumuyla sınırlamayın. Gizli pencerede yeni hesap ve telefonda kritik işlem denenmeli; hata durumunda bilgi kaybı olmamalıdır. Yayına geçişten sonra geri dönüş yolunu koruyun. Kod sürümünü geri almak veri değişikliklerini kendiliğinden geri almaz; bu nedenle her iki taraf için ayrı bir plan gerekir.
Kaynak: Lovable — proje yayınlama ↗
6. Baştan yazma kararını inceleme sonrasına bırakın
Sorun birkaç bağlantı veya erişim kuralındaysa tüm uygulamayı değiştirmek gereksiz olabilir. Önce mevcut yapının ne kadarının işe yaradığını gösteren bir inceleme listesi çıkarın. Liste her madde için beklenen davranışı, önerilen düzeltmeyi ve tamamlandığını nasıl anlayacağınızı içersin. Böylece belirsiz bir “bitirelim” işi, sınırları belli bir teslimata dönüşür.
Lemidea'ya yazarken uygulamanın amacı, çalışmayan tek bir akış, kullanılan hizmetler ve yayın hedefi yeterli bir başlangıçtır. Önce inceleme kapsamını, ardından düzeltmeleri konuşuruz. Mevcut kodu görmeden bütün projeye süre veya fiyat sözü vermek yerine, tamamlanabilir bir ilk adım belirleriz. Aşağıdaki brief rehberi bunu birkaç cümleyle hazırlamanıza yardımcı olabilir.
Kaynaklar ve hazırlanış
Bu içerik yapay zekâ desteğiyle hazırlanmıştır. Lovable özellikleri aşağıdaki resmî belgelerle karşılaştırılmıştır. Kontrol listesi Lemidea'nın önerdiği inceleme yaklaşımıdır; müşteri projesi sonucu veya otomatik güvenlik garantisi değildir.
Araç özellikleri ve sağlayıcı koşulları değişebilir. Kaynak kontrolü: .
Altı kontrol noktası ve sentetik kabul örnekleri içerir. Belirli bir Lovable projesinde uygulanmış denetim olarak sunulmaz.
