Yarım Kalan Yazılım Projesi Nasıl Kurtarılır?
Yarım kalan bir yazılım projesini devralmadan önce erişimler, code audit, veri yapısı ve kritik kullanıcı akışları nasıl kontrol edilmeli? Devam etme, kısmi yeniden yazma veya sıfırdan geliştirme kararını adım adım ele alıyoruz.
İçindekiler
Yarım kalan bir yazılım projesinde ilk refleks genelde “baştan yazalım” olur. Ama bu karar çoğu zaman erken verilir. Önce elinizde ne olduğunu, hangi parçaların çalıştığını ve projenin neden durduğunu görmek gerekir.
Kaynak kodun sizde olması tek başına yeterli değildir. Repo erişimi, veritabanı, sunucu, domain, üçüncü taraf servisler, mobil mağaza hesapları ve deployment süreci de kontrolünüzde olmalıdır.
İlk iş: erişimleri ve yedekleri güvenceye alın
Yeni ekip kod yazmaya başlamadan önce şu varlıkları toplamalıdır:
- Kaynak kod repository erişimi ve commit geçmişi
- Güncel veritabanı yedeği
- Sunucu ve cloud hesapları
- Domain ve DNS erişimi
- App Store ve Google Play hesapları
- Ödeme, e-posta, SMS ve diğer servis hesapları
- API anahtarları ve environment variable'lar
- Figma, dokümantasyon ve mevcut issue listeleri
Bu aşama atlanırsa teknik devralma tamamlanmış sayılmaz. GitHub repository transferini destekliyor, ancak transfer sonrasında yetkilerin ayrıca kontrol edilmesi gerekiyor. GitHub'ın resmi dokümantasyonunda süreç ayrıntılı biçimde anlatılıyor.
Baştan yazmadan önce code audit yapın
Eski kod karmaşık görünüyorsa sıfırdan geliştirme cazip gelebilir. Fakat çalışan iş kurallarını, entegrasyonları ve daha önce çözülmüş problemleri de kaybedebilirsiniz.
Bu yüzden önce kısa bir teknik inceleme yapılmalı. Amaç kodu puanlamak değil, şu soruya cevap vermektir:
Bu sistem güvenli ve sürdürülebilir biçimde geliştirilmeye devam edebilir mi?
İncelemede en az şu alanlara bakılmalı:
| Alan | Bakılması gerekenler |
|---|---|
| Kurulum | Proje temiz bir ortamda çalışıyor mu? |
| Kod yapısı | Kritik modüller anlaşılır ve değiştirilebilir mi? |
| Veri | Şema, migration ve yedekleme düzenli mi? |
| Test | Kritik akışları koruyan testler var mı? |
| Deployment | Canlıya çıkış tekrar edilebilir mi? |
| Güvenlik | Eski paketler, açık secret'lar veya yetki sorunları var mı? |
Güvenlik tarafında OWASP ASVS gibi standartlar, incelemenin yalnızca kişisel yoruma dayanmasını engeller.
Devam mı, kısmi yeniden yazım mı?
Audit sonrasında karar genelde üç seçenekten birine çıkar:
| Durum | Yaklaşım |
|---|---|
| Kod çalışıyor, veri modeli sağlam, sorun birkaç modülde | Mevcut sistem üzerinde devam |
| Çekirdek sağlam ama bazı bölümler sürdürülemez | Kısmi yeniden yazım |
| Temel mimari, veri modeli veya güvenlik yapısı ciddi sorunlu | Yeniden geliştirmeyi değerlendirme |
Burada “projenin yüzde kaçı bitti?” sorusu yanıltıcı olabilir. 30 ekranın 25'i tamamlanmış olabilir, ama ödeme, sipariş veya kullanıcı doğrulama çalışmıyorsa ürün gerçekte bitmeye yakın değildir.
Daha doğru soru şudur: Kritik kullanıcı akışlarının kaçı gerçekten çalışıyor?
İlk hafta nasıl ilerlenmeli?
Yeni ekibin ilk günlerde feature geliştirmesi yerine belirsizliği azaltması daha sağlıklıdır.
- Erişimler, sunucular, servisler ve veritabanı envanterlenir.
- Güncel yedek alınır ve mevcut sistem kayıt altına alınır.
- Proje temiz ortamda ayağa kaldırılır.
- Kritik kullanıcı akışları test edilir.
- Canlıya çıkışı engelleyen riskler listelenir.
- İlk stabil sürümün kapsamı küçültülür.
Bu aşamanın sonunda amaç hemen tarih vermek değil, neyin yapılacağını ve hangi risklerin önce çözülmesi gerektiğini netleştirmektir.
Eski ekipten ne istemelisiniz?
Devir sırasında talepleri maddeli vermek işleri kolaylaştırır:
- Repository erişimi veya transferi
- Production ve staging bilgileri
- Veritabanı yedeği
- Domain ve DNS erişimi
- CI/CD ayarları
- Mobil mağaza hesapları
- Üçüncü taraf servis hesapları
- Figma ve tasarım dosyaları
- API dokümantasyonu
- Bilinen bug ve eksik özellik listesi
Repository devri tek başına yeterli değildir. Ürünün gerçekten devredilmiş sayılması için kritik hesapların da ürün sahibinin kontrolünde olması gerekir.
Kişisel veri varsa erişimleri yeniden düzenleyin
Sistem müşteri veya çalışan verisi içeriyorsa eski hesapların yetkileri, production erişimleri ve secret'lar ayrıca gözden geçirilmelidir.
KVKK, veri güvenliği için alınacak teknik ve idari tedbirlerin işlenen verinin riskine göre belirlenmesi gerektiğini vurguluyor. KVKK'nın veri güvenliği yükümlülükleri sayfası bu konuda temel referanslardan biridir.
Yeni ekibe sorulacak 5 soru
- İlk hafta hangi teknik kontrolleri yapacaksınız?
- Mevcut kodu devam ettirme veya yeniden yazma kararını neye göre vereceksiniz?
- Canlı sistemi bozmadan nasıl test edeceksiniz?
- İlk stabil sürümün kapsamını nasıl belirleyeceksiniz?
- Siz projeden ayrılırsanız başka bir ekip sistemi kolayca devralabilir mi?
Son soru önemlidir. İyi bir kurtarma işi yalnızca projeyi ayağa kaldırmaz, ürünü tekrar devredilebilir hale getirir.
Sonuç
Yarım kalan projelerde doğru başlangıç yeni özellik eklemek değildir. Önce erişimler, veri, kod kalitesi, deployment ve kritik kullanıcı akışları birlikte incelenmelidir.
Bazen mevcut sistemle devam etmek en doğru çözümdür. Bazen yalnızca birkaç modülün yeniden yazılması gerekir. Bazı projelerde ise sıfırdan geliştirme gerçekten daha mantıklıdır. Bu kararın tahminle değil, kısa ve net bir teknik audit sonrasında verilmesi gerekir.
Mevcut bir sistemi devralma, stabil hale getirme ve geliştirmeye devam etme süreci hakkında yazılım geliştirme hizmetimizi inceleyebilirsiniz. Elinizde yarım kalmış veya başka bir ekipten devralmak istediğiniz bir yazılım varsa, Vectorium ile iletişime geçerek mevcut yapının teknik durumunu birlikte değerlendirebilirsiniz.