Canlı bir mobil uygulamayı modernize etmek yenisini yapmaktan farklıdır: hiç güncelleme yapmayacak eski sürümlerde kullanıcılarınız, kötü bir sürümü saatler içinde cezalandıran mağaza yorumlarınız ve kontrol etmediğiniz cihazlarda veriniz vardır. İşe yarayan teknik kademelidir, mevcut kabuğun arkasında ekran ekran veya katman katman değiştirmek, yeniden yazılmış bir uygulama gönderip umut etmek değil.
Bu rehber modernizasyonun nasıl sıralanacağını, mevcut kullanıcıların nasıl korunacağını ve yeniden yazımın gerçekten ne zaman gerekçeli olduğunu kapsar.
Önemli noktalar
- Mevcut kullanıcı tabanına asla büyük patlama yeniden yazımı göndermeyin: Kademeli yayın, tek seferde tek alan.
- Eski sürümler cihazlarda yıllarca yaşar: Arka uç boyunca onlara hizmet etmelidir.
- Puanlar yavaş toparlanır: Kötü bir sürüm, kazandırdığı zamandan pahalıya gelir.
- Her şeyi aynı anda değiştirmeyin: Kullanıcılar yeni kodu affeder; yeri değişmiş bir düğme artı yeni hataları affetmez.
Önce başlangıç değerini belirleyin
Nereden başladığınızı bilmeden modernizasyonun işe yarayıp yaramadığını söyleyemezsiniz. Bir şey değiştirmeden önce çökmesiz oturum oranını, soğuk açılış süresini, uygulama boyutunu, son doksan günün ortalama puanını, kohort bazında elde tutmayı ve kurulu tabandaki sürüm dağılımını kaydedin.
Sonuncusu tüm planı belirler. Kullanıcılarınızın dörtte biri üç sürüm gerideyse, arka uçtaki her değişiklik ellerindekiyle uyumlu kalmalıdır, ve onlara ulaşmanın, zaten reddettikleri bir mağaza güncellemesi dışında yolu yoktur.
Kısıtı kaldıran en küçük şeyi seçin
| Durum | Yaklaşım |
|---|---|
| Yavaş veya çöküyor, yapı sağlam | Performans ve kararlılığı düzeltin; yeniden yazım yok |
| Çatı desteklenmiyor veya derlenmiyor | Davranışı aynı tutarak platform değiştirin |
| Bir alan yol haritasını engelliyor | O alanı mevcut gezinmenin arkasında yeniden inşa edin |
| İki yerel kod tabanı maliyette ayrışıyor | Ekran ekran çapraz platforma geçin |
| Hiçbir şey çalışmıyor ve kimse anlamıyor | Strangler yaklaşımıyla kademeli yeniden inşa |
Bunların her birinde içgüdü yeniden yazmaktır. Kanıt aksini söylüyor: yeniden inşa tipik olarak 18–36 ay sürerken aynı sistemi refactor etmek 6–12 aydır ve bir mobil yeniden yazım, yeni bir şey sunabilmek için yıllarca birikmiş davranışla eşitliğe ulaşmak zorundadır.
Kabuğun arkasında kademeli değiştirin
Her iki büyük çapraz platform çatısı da mevcut bir yerel uygulamaya gömülmeyi destekler; bu da ekran ekran göçü pratik kılar. Desen, arka uç sistemlerinde kullanılanla aynıdır: dış kabuğu sabit tutun, içindekini değiştirin, kullanıcıları yeni uygulamaya ancak kanıtlandıktan sonra yönlendirin.
Kendi içinde bütün, iyi anlaşılmış ve düşük riskli bir ekranla başlayın, en sancılı olanla değil, çünkü o genellikle en dolaşık olanıdır. Küçük bir yüzdeye gönderin, sayıları izleyin, sonra genişletin.
Avantaj zarafet değildir. Bir ekrandaki sorunun, herkes için bozuk bir uygulama yerine sınırlı bir geri alma olmasıdır.
Arka ucun eski istemcilere hizmet etmesini sağlayın
Eski uygulama sürümleri cihazlarda yıllarca kalır. Kullanıcılar otomatik güncellemeyi kapatır, cihazlar işletim sistemi güncellemesi almayı bırakır ve kurulu tabanınızın bir kısmı her zaman geride olur.
Bu, API'nin yeniler için gelişirken eski istemcilere de hizmet etmesi gerektiği anlamına gelir. Açıkça sürümleyin, bir sürümü kaldırmayı kimin hâlâ kullandığını gösteren telemetriyle bilinçli bir karar olarak ele alın ve bir mağaza sürümünün herkese ulaştığını asla varsaymayın.
Yoksa uzaktan yapılandırma ve zorunlu güncelleme yeteneğini erken kurun. Bozuk bir özelliği sunucu tarafından kapatabilmek veya belirli bir sürümün altındakilerden güncelleme isteyebilmek, bir krizi rahatsızlığa çeviren şeydir.
Yavaş yayın yapın ve doğru sayıları izleyin
Her iki mağaza da kademeli yayını destekler. Kullanın ve iptal kriterlerini başlamadan önce tanımlayın: eşiğin altına düşen çökmesiz oran, tek yıldızlı yorumlarda ani artış veya temel bir dönüşümde düşüş.
Sürüme ve cihaza göre çökmesiz oturumları, Android'de ANR oranını, soğuk açılışı ve temel yolculuğun tamamlanmasını izleyin. Mutlak bir standarda değil başlangıç değerine karşı karşılaştırın, %99,2'lik bir çökmesiz oran, %98,8'den başladıysanız iyidir ve %99,7'den başladıysanız endişe vericidir.
İlk net sinyalde durdurun. Sayılar "muhtemelen gürültü" diye kademeli yayını genişletmek, sınırlı bir sorunun bir yıl toparlamaya çalışacağınız bir puana dönüşme yoludur.
Yeniden tasarım ile yeniden geliştirmeyi aynı anda yapmayın
Kullanıcılar birebir aynı görünen yeniden yazılmış bir uygulamaya katlanır. Çalışan bir uygulamanın yeniden tasarımına katlanır. İkisine birden kötü tepki verir; çünkü her tanıdık olmayan öğe hata gibi, her gerçek hata da yeniden tasarım gibi görünür.
Bunları ayırın. Önce uygulamayı modernize edin, kararlılığı doğrulayın, sonra arayüzü kendi iletişimiyle kendi sürümü olarak değiştirin. Aynı anda yeniden tasarım kaçınılmazsa gezinme yapısını ve birincil eylemlerin yerini değiştirmeyin.
Cihazdaki veriyi koruyun
Kullanıcıların yerel verisi vardır: taslaklar, önbellek, tercihler, çevrimdışı kayıtlar. Bunu sessizce silen bir modernizasyon destek teması ve kaybedilmiş güven üretir ve tamamen önlenebilir.
Cihaz üstü göçü planlayın: eski depolama biçiminden ne okunuyor, nasıl dönüştürülüyor, dönüşüm başarısız olursa ne oluyor ve kullanıcı ne görüyor. Yalnızca en son sürümden değil birkaç eski sürümden yükselterek test edin.
Zaten kullananlara anlatın
Mevcut kullanıcılar bunu istemedi. Ciddi bir değişiklik için "performans iyileştirmeleri" diyen sürüm notları, sahip olduğunuz tek kanalı israf eder.
Neyin değiştiğini, neyin daha iyi olduğunu ve bir şeyin yeri değiştiyse nereye gittiğini söyleyin. Bir şey kaldırıldıysa söyleyin, kullanıcılar zaten fark eder ve kandırıldıklarını hissettiklerinde yorumlar, önceden bilgilendirildiklerinden çok daha serttir.
Başlangıç değerine karşı değerlendirin
Tamamlandıktan üç ay sonra başlangıçta kaydettiğiniz sayıları karşılaştırın: çökmesiz oran, açılış süresi, puan eğilimi, elde tutma ve küçük değişiklik teslim süresi.
Sonuncusu çoğu zaman asıl gerekçedir. Kullanıcıları etkilemeyen ama üç haftalık bir değişikliği iki günlük hale getiren bir modernizasyon başarılı olmuştur, hiçbir müşteri fark etmemiş olsa bile, ve önceden ölçmediyseniz unutulması en muhtemel sonuçtur.
İlgili rehberler
- Aynı konunun uzun hali şurada: Yapay Zeka İş Akışı Otomasyonu: Kullanım Alanları ve Riskler.
- İşin pahalıya gittiği yer şurada anlatılıyor: Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.
Kullanıcı Kaybetmeden Mevcut Mobil Uygulama Nasıl Modernize Edilir? yazısındaki eski sistem sorunları sıralı bir plan istiyorsa Modernizasyon Planınızı Konuşalım.
Ali Boran Gazel