Yarım kalan bir yazılım projesini kurtarmanın sırası şudur: önce erişimi güvenceye alın (kod deposu, sunucu, alan adı, mağaza hesapları), sonra bağımsız bir ekibe kod denetimi yaptırın, en son da devam mı yeniden yazım mı kararını denetim sonucuna göre verin. En sık yapılan hata, ilk iş olarak yeni bir firmadan “kalan kısmı bitirme” teklifi istemektir; kodun ne durumda olduğunu kimse bilmeden verilen her fiyat tahminden ibarettir. Bu yazıda bir projeyi devralırken bizim de izlediğimiz adımları sırasıyla anlatıyoruz.
Yazılım projesi neden yarım kalır?
Devraldığımız projelerde sebep nadiren tek bir kötü niyettir. Çoğunlukla birkaç sorun üst üste biner: kapsam yazılı olmadığı için iş sürekli büyür, sabit fiyatlı teklif bu büyümeyi taşıyamaz ve geliştirici zarar ettiği projeden yavaşça uzaklaşır. Projeyi tek kişinin bildiği durumlarda o kişinin başka işe geçmesi yeterlidir. Bazen de teknik temel o kadar zayıftır ki her yeni özellik iki eskisini bozar ve ekip ilerleyemez hâle gelir. Sebebi bilmek önemlidir, çünkü yeni ekiple aynı tuzağa düşmemenin yolu oradan geçer.
İlk 48 saatte neyi güvenceye almalısınız?
İlişki henüz tamamen kopmadıysa, teknik tartışmaya girmeden önce şu erişimleri kendi adınıza alın. İlişki gerginse bunları tek bir yazılı talep olarak, liste hâlinde isteyin:
- Kaynak kod deposu: GitHub, GitLab ya da Bitbucket üzerinde sahip (owner) yetkisi. Yalnızca zip dosyası yetmez; commit geçmişi kodun nasıl evrildiğini gösterir.
- Sunucu ve bulut hesapları: hosting paneli, bulut sağlayıcısı, veritabanı ve yedekler. Faturanın kimin kartından ödendiğine de bakın.
- Alan adı ve DNS: alan adı kayıt firmasındaki hesap sizin adınıza olmalı.
- Mağaza hesapları: App Store Connect ve Google Play Console. Uygulama geliştiricinin kendi hesabındaysa transfer süreci ayrıca planlanır.
- Üçüncü taraf servisler: ödeme altyapısı, SMS, e-posta, harita ve bildirim servislerinin anahtarları.
- Ortam değişkenleri, kurulum notları ve varsa tasarım dosyaları.
Kod sizde ama sunucu, alan adı ve mağaza hesabı başkasındaysa projeye sahip değilsiniz, yalnızca bir kopyasına sahipsiniz.
Erişimleri aldıktan sonra tüm parolaları ve API anahtarlarını değiştirin. Bu bir suçlama değil, standart bir devir adımıdır. Sözleşmenizde kaynak kodun ve mali hakların devri yazıyorsa bu talep çok daha kolay ilerler; bu maddelerin neden baştan konması gerektiğini yazılım geliştirme sözleşmesi yazımızda ayrıntılı anlattık. Bu yazı hukuki danışmanlık değildir; anlaşmazlık varsa bir avukata danışın.
Kod denetimi nasıl yapılır?
Kod denetimi, yeni ekibin projeyi gerçekten çalıştırıp içine bakmasıdır. Sunum ya da ekran görüntüsü üzerinden yapılan değerlendirme denetim sayılmaz. İyi bir denetim şu soruları yazılı olarak cevaplar:
- Proje sıfır bir bilgisayarda, dokümana bakarak kurulup çalıştırılabiliyor mu?
- Hangi özellikler gerçekten çalışıyor, hangileri yalnızca ekranda var?
- Kullanılan kütüphane ve çatı sürümleri güncel mi, desteği bitmiş bileşen var mı?
- Veritabanı yapısı mantıklı mı, canlıda gerçek veri var mı ve bu veri nasıl korunacak?
- Güvenlik açısından bariz açık var mı: koda gömülü parolalar, korumasız API uçları, yetki kontrolü olmayan ekranlar?
- Test, hata kaydı ve otomatik yayın düzeni var mı?
Denetimin çıktısı, her modül için “sağlam, düzeltilebilir, yeniden yazılmalı” gibi net bir sınıflandırmadır. Bu sınıflandırma aslında projenin teknik borç haritasıdır ve bir sonraki kararın tek dayanağıdır. Kaç günde biteceği projenin boyutuna bağlıdır; burada önemli olan, denetimin ayrı ve sınırlı bir iş olarak fiyatlanmasıdır. Böylece devam teklifine bağlanmadan durumu öğrenmiş olursunuz.
Devam mı, yeniden yazım mı?
Yeni gelen her ekibin içgüdüsü yeniden yazmaktır, çünkü başkasının kodunu okumak kendi kodunu yazmaktan zordur. Bu yüzden bu kararı duyguyla değil, denetim sonucuyla verin. Kaba bir kural olarak: veri modeli sağlam ve sorunlar tek tek modüllerde ise mevcut kodla devam etmek neredeyse her zaman daha hızlıdır. Veri modeli çürükse, temel çatı desteği bitmiş bir sürümdeyse ya da hiçbir değişiklik bir yeri bozmadan yapılamıyorsa yeniden yazım daha az risklidir.
Çoğu zaman doğru cevap ikisinin arasındadır: çalışan kısımlar korunur, en sorunlu modül önce yeniden yazılır, gerisi zamanla iyileştirilir. Canlıda kullanıcı ve veri varsa sistemi bir gecede değiştirmek yerine parça parça taşımak daha güvenlidir; bu konuda eski sistemden veri göçü yazısındaki adımlar burada da geçerlidir.
Yeni ekiple devir teslim nasıl olmalı?
Yeni ekiple ilk sözleşmeyi küçük tutun: denetim artı ilk kritik düzeltmeler. Bu, hem ekibin nasıl çalıştığını görmenizi sağlar hem de ilk projeye tekrar her şeyi bağlamanızı engeller. Kalan iş için yazılı bir kapsam, kabul kriterleri ve kilometre taşlarına bölünmüş ödeme planı isteyin. Kod deposu ilk günden sizin hesabınızda kalsın, yeni ekip oraya katkı versin. Firma seçerken hangi soruları soracağınızı kurumsal yazılım firması seçimi yazımızda topladık.
Aynı hikâyenin tekrar yaşanmaması için devirle birlikte üç alışkanlık kazanın: her sürümde güncellenen kısa bir kurulum dokümanı, hataların görülebildiği bir hata izleme ve loglama düzeni ve projeyi en az iki kişinin bildiği bir ekip yapısı.
Sonuç
Yarım kalan bir yazılım projesi çoğu zaman sanıldığı kadar kayıp değildir, ama kurtarmanın sırası önemlidir: önce erişim, sonra denetim, en son karar. Fiyatı denetimden önce konuşmayın, yeniden yazımı denetim göstermeden kabul etmeyin. Elinizde yarım kalmış bir proje varsa özel yazılım ekibimiz önce durumu inceleyip yazılı bir değerlendirme çıkarır; ardından isterseniz teklif alabilirsiniz.