Yarım Kalan Mobil Uygulamayı Devralma ve Kurtarma Rehberi
Yarım kalan mobil uygulamayı devralırken kod, hesap, backend, mağaza, güvenlik ve teknik borcu inceleyin; kurtarma, refactor veya yeniden yazımı seçin.
Kısa cevap: Önce projeyi değil, kanıtları devralın
Yarım kalan mobil uygulamayı devralma sürecinin ilk işi yeni özellik geliştirmek değildir. Kaynak kodun derlenebildiğini, canlı sistemin hangi hesaplardaki hangi servislere bağlı olduğunu, kullanıcı verisinin nerede bulunduğunu ve mağazadaki sürümün hangi commit’ten üretildiğini kanıtlamaktır. Bu fotoğraf çıkarılmadan verilen “kaldığımız yerden devam” sözü hem müşteri hem yeni ekip için tehlikelidir; görünmeyen teknik borç takvim içinde patlar.
Devralma her zaman yeniden yazma anlamına gelmez. İyi durumda fakat belgesiz bir proje kısa bir stabilizasyonla sürdürülebilir. Bazı projelerde mobil arayüz korunurken backend ayrıştırılır; bazılarında kritik veri ve tasarım korunup istemci yeniden kurulur. Doğru seçenek, önceki ekibe dair kanaatten değil çalıştırılabilirlik, güvenlik, değiştirilebilirlik ve ticari öncelik kanıtlarından çıkar.
Hangi durumlarda devralma analizi gerekir?
Önceki geliştiriciye ulaşılamaması en görünür senaryodur; ancak tek neden değildir. Teslim tarihleri sürekli kayıyor, her düzeltme başka işlevi bozuyor, uygulama yalnızca bir geliştiricinin bilgisayarında çalışıyor, mağaza hesabı ajansın üzerinde duruyor veya yatırım incelemesi için teknik envanter isteniyorsa devir hazırlığı gerekir. İç ekip kurmak isteyen şirket de mevcut ajansla sorun yaşamasa bile aynı analizi yapabilir.
Yayındaki uygulamada bakım durduysa durum daha hassastır. Yeni işletim sistemi veya mağaza gereksinimi yaklaşırken build alınamaması, push sertifikasının kime ait olduğunun bilinmemesi ve backend yedeklerinin doğrulanmaması süre baskısı yaratır. Bu durumda ilk hedef yeni tasarım değil, hizmet sürekliliği ve erişim güvenliğidir.
“Yüzde 80 tamam” neden ölçü değildir?
Bir projede ekranların çoğu çizilmiş olabilir; fakat kayıt, ödeme veya veri senkronizasyonu uçtan uca çalışmıyorsa ticari değerin küçük bölümü tamamlanmıştır. Demo verisiyle açılan ana sayfa, gerçek API hatalarını ve yetki kurallarını gizleyebilir. Benzer şekilde mağazaya yüklenmiş test paketi; yönetim panelinin, veri yedeğinin veya hesap silme akışının hazır olduğunu göstermez.
Tamamlanma, kabul senaryolarıyla ölçülmelidir. Her kritik akış için ön koşul, test verisi, beklenen sonuç, hata davranışı ve desteklenen platform yazılır. Temiz cihazda kurulum, yeni kullanıcı, mevcut kullanıcı, zayıf ağ, oturum süresi dolması, uygulamanın arka plandan dönmesi ve dış servis hatası denenir. İşleyen senaryolar, kısmen çalışanlar ve engellenenler raporda ayrılır.
Devralma karar matrisi
| Seçenek | Seçimi destekleyen kanıt | Dikkat edilmesi gereken |
|---|---|---|
| Olduğu gibi sürdür | Build tekrarlanabilir, mimari anlaşılır, kritik akışlar sağlam | Gizli teknik borcu backlog’da görünür tutmak |
| Önce stabilize et | Ürün değeri var, fakat hata/izleme/test açığı yüksek | Yeni özellik tarihini stabilizasyondan ayırmak |
| Hedefli refactor | Belirli modül değişimi sürekli engelliyor | Refactor sınırı ve geriye uyumluluk testi |
| Kademeli yeniden yaz | İş modeli doğru, mevcut temel sürdürülemez | Eski ve yeni sistemin birlikte çalışma dönemi |
| Kontrollü durdur | İş değeri doğrulanmamış veya erişim/hak riski çözülemiyor | Veri, hesap ve marka varlıklarını güvenle korumak |
Bu seçenekler birbirini dışlamayabilir. Örneğin sipariş akışı stabilize edilirken yeni kampanya modülü ayrı servis olarak geliştirilebilir. Ancak aynı anda hem tüm teknik borcu temizleyip hem sabit tarihte çok sayıda özellik çıkarma hedefi gerçekçi değildir. Karar matrisi, hangi kullanıcı değerinin önce korunacağını görünür kılar.
Veri odası: İlk istenecek varlıklar
Devralma başlamadan müşteri erişebildiği varlıkları tek listede toplar. Kaynak kod depoları, tasarım dosyaları, API belgeleri, veritabanı şeması ve yedekler temel gruptur. App Store Connect, Apple Developer, Play Console, Firebase, bulut, alan adı, DNS, e-posta/SMS, ödeme, analitik, çökme izleme ve destek sistemleri hesap grubunu oluşturur. Her erişim için sahip, rol, kurtarma yöntemi ve fatura sorumlusu yazılır.
Sözleşme, teklif, fatura, lisans ve önceki teslim tutanakları da teknik incelemeye bağlam sağlar. Bu belgeler hangi kodun kullanılabileceği konusunda hukuk danışmanına veri sunar. Yeni ekip hak sahipliği yorumu yapmamalı; belirsiz veya lisanssız varlığı risk olarak işaretlemelidir. Üretim kullanıcı verisi analiz amacıyla geliştirici bilgisayarına kopyalanmamalı; mümkünse maskeli test verisi ve kontrollü erişim kullanılmalıdır.
İstenen bir varlığın bulunmaması incelemeyi durdurmak zorunda değildir, fakat güven seviyesini etkiler. Örneğin tasarım dosyası yoksa mevcut ekranlar referans alınabilir; Android imza süreci belirsizse Play App Signing ve upload key durumu ayrıca doğrulanır. “Yok” ile “henüz erişemedik” ayrı işaretlenmelidir.
Teknik inceleme katmanları
İlk katman yeniden üretilebilir build’dir. Desteklenen araç ve SDK sürümleri belgelenir; bağımlılıklar kurulur; iOS ve Android paketleri temiz ortamda üretilir. Sabit disk yolu, kişisel paket deposu, süresi dolmuş sertifika veya kayıp ortam dosyası engelleri kaydedilir. Üretilen paketin mağazadaki uygulama kimliği ve imza düzeniyle ilişkisi doğrulanır.
İkinci katman kod ve mimaridir. Modül sınırları, durum yönetimi, ağ katmanı, hata işleme, bağımlılık güncelliği, test kapsamı ve kod içinde gizli anahtar aranır. Kodun güzel olup olmadığına dair öznel puan yerine değişiklik riski ölçülür: Yeni bir alan eklemek kaç farklı dosyada iş kuralı kopyalamayı gerektiriyor? API hatası tek noktada mı yönetiliyor? Ortamlar ayrılabiliyor mu?
Üçüncü katman backend ve veridir. API kimlik doğrulama, rol yetkisi, veri modeli, göçler, cron görevleri, dosya depolama, kuyruklar, yedekleme ve loglama incelenir. Mobil arayüz güvenli görünse bile sunucu farklı kullanıcının verisini döndürebilir. Bu nedenle OWASP MASVS mobil istemci için, ilişkili backend ise uygun sunucu güvenliği kontrolleriyle değerlendirilmelidir.
Dördüncü katman üründür. Kritik kullanıcı akışları, tasarımla uygulamanın farkı, eksik içerik, yönetim paneli ve operasyon adımları görülür. Teknik olarak çalışan özellik iş kuralını yanlış uyguluyorsa korunması avantaj değildir. Mevcut backlog, kullanıcı yorumu ve analitik varsa gerçek ihtiyaçla karşılaştırılır.
Güvenlik ve erişim devri
Eski ekipten gelen ortak parolaları aynen kullanmaya devam etmek devralma değildir. Önce yetkili hesaplar envantere alınır, müşteri sahipliği doğrulanır, gereksiz kullanıcılar kaldırılır ve kritik hesaplarda çok faktörlü doğrulama açılır. API, veritabanı, bulut ve üçüncü taraf anahtarları kontrollü rotasyon planıyla yenilenir. Anahtarı aniden değiştirmek canlı servisi kesebileceği için bağımlılık haritası çıkarılmadan işlem yapılmaz.
Kod deposunun aktarılması da dikkat ister. GitHub’ın repository transfer dokümanı, issues, pull request ve bazı ayarların taşınabildiğini; fakat organizasyon ve paket koşullarının kontrol edilmesi gerektiğini gösterir. Mümkünse müşteri organizasyonunda roller yeniden kurulur, branch koruması ve gizli değer politikası uygulanır.
Kişisel veri bulunan projede eski ekibin erişiminin kaldırılması kayıt altına alınmalıdır. Veri sorumlusu ve veri işleyen ilişkisi, saklama ve olay bildirimi hukuk/uyum tarafıyla değerlendirilir. KVKK’nın veri güvenliğine ilişkin yükümlülükler sayfası uygun teknik ve idari tedbir sorumluluğunu açıklar.
Mağaza ve uygulama kimliği devri
Uygulama müşterinin hesabında değilse yeni paket yayınlamadan önce transfer seçeneği değerlendirilir. Apple’ın uygulama transferi genel görünümü aktarım sırasında uygulamanın Bundle ID’sini, yorum ve puanlarını koruyabildiğini; belirli bağlı özellikler için ek işlem gerektiğini açıklar. Google Play’in uygulama transfer rehberi kullanıcı, istatistik ve liste bilgilerinin yanı sıra transfer edilmeyen rapor, test grubu ve bağlantı ayarlarına dikkat çeker.
Bu nedenle mağaza transferi tek bir form doldurma işi olarak fiyatlanmamalıdır. Abonelik, ödeme profili, Firebase/Analytics, oyun hizmetleri, push, Associated Domains, Sign in with Apple, CloudKit veya diğer bağlı servislerin proje özelinde matrisi çıkarılır. Transfer mümkün değilse yeni listeleme seçeneğinin kullanıcı, yorum, abonelik ve marka etkisi ticari karar vericilere açıklanır.
Maliyet ve süreyi etkileyen faktörler
Devralma maliyetini mevcut kod satırı değil belirsizlik ve kritik yol belirler. Tüm erişimlerin hazır olması, temiz build, test ortamı ve bilgili bir eski ekip riski azaltır. Kaynak kodun farklı kopyalarda bulunması, canlı veritabanı şemasının depoyla uyuşmaması, eski framework, özel native eklenti ve belgesiz ERP entegrasyonu inceleme ve stabilizasyonu büyütür.
Yayındaki kullanıcı sayısı ve kesinti toleransı göç yöntemini etkiler. Sıfır kesintiye yakın hedef, paralel ortam, veri eşleme, geri dönüş ve daha kapsamlı test gerektirir. Regülasyon, ödeme, sağlık veya konum gibi hassas alanlarda güvenlik ve uyum doğrulaması artar. Tasarım yenileme ile teknik kurtarmayı aynı faza koymak da takvimi uzatır; önce çalışabilir temel, sonra deneyim dönüşümü daha ölçülebilir olabilir.
İnceleme öncesi sabit toplam fiyat isteyen müşteri genellikle iki sonuçtan biriyle karşılaşır: tedarikçi büyük risk payı ekler ya da çok sayıda varsayım/hariç yazar. Daha karşılaştırılabilir model; kapsamı belirli teknik inceleme, ardından seçenek bazlı yol haritası ve faz teklifidir. Her seçenek korunacak modülleri, kaldırılacak teknik borcu, bağımlılıkları ve kabul kriterlerini gösterir.
Devralma raporunda beklenen teslimatlar
- Varlık ve hesap envanteri; sahiplik, rol ve eksik erişimler
- Temiz build sonucu, kurulum engelleri ve sürüm/commit eşlemesi
- Kritik kullanıcı akışlarının çalışır, kısmi ve engelli durum tablosu
- Mimari harita; mobil, backend, veri ve dış servis bağımlılıkları
- Güvenlik, gizli değer, lisans ve kişisel veri risk kaydı
- Hata, teknik borç ve güncellik bulgularının etki/olasılık önceliği
- Stabilize, hedefli refactor ve yeniden yazma seçeneklerinin karşılaştırması
- İlk uygulama fazı için kapsam, varsayım, kabul ve geçiş planı
Raporun amacı eski ekibi suçlamak değildir. Bulgular tekrar üretilebilir kanıta bağlanmalı; “kod kötü” yerine “ödeme modülü için otomatik test yok, aynı iş kuralı üç yerde farklı uygulanıyor ve değişiklik P1 regresyon riski taşıyor” denmelidir. Kanıt dili, yatırım kararını kişisel tartışmadan çıkarır.
Riskler ve kırmızı bayraklar
İnceleme yapmadan kesin teslim tarihi veren ekip, bilinmeyeni ya görmezden gelir ya da sonradan değişiklik olarak sunar. Eski uygulamayı çalıştıramadığı halde yalnızca ekran görüntüsü üzerinden teklif vermek, canlı veritabanında yedeksiz göç yapmak, üretim sırlarını ortak mesaj grubunda istemek ve hukuki hakkı doğrulanmamış kodu kopyalamak ciddi uyarılardır.
Diğer risk, yeniden yazmayı teknik prestij projesine çevirmektir. Mevcut kod kusurlu olsa da çalışan ödeme, veri veya mağaza kimliği değerli olabilir. Yeni sistemin bu değeri hangi aşamada devralacağı, paralel çalışma ve geri dönüş planı olmadan büyük patlama yöntemi seçilmemelidir. Tam tersi olarak batık maliyet duygusuyla sürdürülemez kodu sonsuza kadar yamamak da ürün hızını tüketir.
Teklif ve sözleşme kontrol listesi
- İlk faz analiz mi, stabilizasyon mu; çıktısı ve sınırı açık mı?
- İnceleme için gereken depo, hesap, test verisi ve yetkiler listeli mi?
- Üretim erişimi en az yetki, kayıt ve gizlilik koşuluyla mı veriliyor?
- Bulgular kanıt, etki ve öneriyle raporlanacak mı?
- Mevcut kodun kullanım hakkı ve üçüncü taraf lisansları kim tarafından doğrulanacak?
- Korunacak, refactor edilecek ve yeniden yazılacak modüller kabul sonrası mı seçilecek?
- Veri yedeği, göç provası, doğrulama ve geri dönüş planı var mı?
- App Store/Play transferi ile bağlı servisler kapsamda mı?
- Yeni özellikler stabilizasyon başarısından ayrı kilometre taşına mı bağlı?
- Teknik borç ve bilinen hatalar kabul belgesine eklenecek mi?
- Devralan ekibin kaynak kod, doküman ve hesap teslim yükümlülüğü baştan yazılı mı?
- Eski ve yeni ekibin sınırlı geçiş görüşmesi mümkünse görevleri tanımlı mı?
Aşamalı kurtarma süreci
Aşama sıfırda canlı sistemi koruma altına alınır: erişimler kaydedilir, doğrulanmış yedek alınır, değişiklik dondurma gerekip gerekmediği belirlenir ve kritik olay iletişimi kurulur. Sonra veri odası tamamlanır. Hiçbir dosya silinmez veya anahtar plansız döndürülmez; geri dönüş imkânı korunur.
Birinci aşamada build ve çalışma tabanı kurulur. En küçük kod değişikliği test ortamına çıkarılır, yayın hattı doğrulanır ve mağaza paketleriyle kimlik ilişkisi kontrol edilir. İkinci aşamada kritik iş akışları stabilize edilir; güvenlik açığı, veri kaybı ve yayın engeli önce gelir. Bu sırada yeni özellikler yalnızca kurtarma hedefini bozmayacaksa alınır.
Üçüncü aşamada kanıta dayalı ürün yol haritası başlar. Refactor veya yeniden yazma küçük modül sınırlarıyla yürütülür, her adımda eski davranışla karşılaştırma ve geri dönüş tutulur. İzleme, test ve dokümantasyon teslim tanımının parçası olur. Böylece yeni ekip bir sonraki “devralınamaz proje”yi üretmez.
Sonuç: Devralmanın başarısı, geçmişi silmeden kontrolü geri almaktır
Yarım kalan mobil uygulamayı kurtarmak için en değerli ilk çıktı yeni ekran değil, güvenilir durum fotoğrafıdır. MobiCraft’a başvururken erişebildiğiniz depo, test paketi, mağaza hesabı, backend ve sözleşme varlıklarını listeleyin; eksikleri saklamanız gerekmez. Önce çalışan ve korunabilir parçaları, kritik riskleri ve gerçek bağımlılıkları görünür yapalım. Ardından işletmeniz için sürdürme, stabilize etme, refactor veya kademeli yeniden yazma seçeneklerinden kanıtı en güçlü olanı seçelim.