Yazılımınız sahipsiz mi kaldı? Mevcut projeyi devralmanın yol haritası

Pek çok işletmenin bir noktada yaşadığı bir durum: Web sitesini, uygulamayı ya da şirket içi yazılımı yapan ekip ya da kişi artık destek vermiyor. Bir hata çıktığında kimse müdahale edemiyor, küçük bir değişiklik için bile kime başvurulacağı bilinmiyor. Sistem çalışıyor gibi görünse de her gün biraz daha riskli hale geliyor. Bu yazıda sahipsiz kalmış bir yazılımı devralmanın adımlarını anlatıyoruz.

Sahipsiz yazılımın riskleri

• Güvenlik: Güncellenmeyen yazılım ve sunucular, zamanla bilinen açıklara karşı savunmasız kalıyor.
• Kesinti: Sunucu, alan adı ya da sertifika süresi dolduğunda site bir gün hiç açılmayabiliyor.
• Veri kaybı: Yedeklerin alınıp alınmadığı, alınıyorsa nerede durduğu bilinmiyor.
• Büyüyememe: Yeni bir özellik eklemek ya da başka bir sistemle bağlantı kurmak mümkün olmuyor.

1. Erişimleri toplamak

İlk iş, sisteme dair bütün anahtarları bir araya getirmek. Çoğu zaman en uzun süren adım bu:

• Alan adının kayıtlı olduğu hesap,
• Sunucu ya da barındırma hesabı,
• Kaynak kodun bulunduğu yer (kod deposu ya da sunucudaki dosyalar),
• Veritabanı erişimi,
• Kullanılan üçüncü parti servislerin hesapları (e-posta, SMS, ödeme, harita vb.).

Bu hesapların hangilerinin işletmenin, hangilerinin önceki ekibin adına açıldığını tespit etmek önemli. Sizin adınıza olmayan hesapların devri ilk sıradaki iş.

2. Altyapı incelemesi

Kodun nerede, nasıl çalıştığını anlamak için altyapı inceleniyor:

• Sunucunun işletim sistemi ve yazılımları güncel mi?
• SSL sertifikası ve alan adının süresi ne zaman doluyor?
• Yedekleme var mı, yedekten geri dönülebiliyor mu?
• Site ve servisler izleniyor mu, bir kesinti olduğunda haberiniz oluyor mu?

3. Kod incelemesi

Ardından kodun kendisine bakılıyor. Amaç kusur aramak değil, sistemin ne durumda olduğunu dürüstçe ortaya koymak:

• Kod okunur ve düzenli mi, yoksa her değişiklik yeni bir hataya mı yol açıyor?
• Kullanılan kütüphaneler ve çatılar hâlâ destekleniyor mu?
• Bilinen güvenlik açıkları var mı?
• Belgelendirme var mı, yoksa bilgi yalnızca önceki geliştiricinin kafasında mıydı?

4. Rapor ve karar: devam mı, yeniden yazmak mı?

İnceleme sonunda bir rapor çıkıyor ve iki yoldan biri öneriliyor:

• Üzerine devam etmek: Kod ve altyapı makul durumdaysa önce acil riskler (güncellemeler, yedekleme, güvenlik açıkları) gideriliyor, ardından geliştirmeye devam ediliyor. Çoğu durumda en hızlı ve en ekonomik yol bu.
• Yeniden yazmak: Kod artık desteklenmeyen teknolojilere dayanıyorsa, her değişiklik yeni sorunlar doğuruyorsa ya da güvenlik açıkları yapısal düzeydeyse, eski sistem çalışmaya devam ederken yenisini adım adım kurmak daha sağlıklı olabiliyor.

Hangi yolun seçileceği, maliyet ve risk karşılaştırmasıyla birlikte gerekçeli olarak sunulmalı. "Her şeyi baştan yazalım" önerisi, gerekçesi açıklanmadan kabul edilmemeli.

5. Belgelendirme ve bakım

Devralma sürecinin en önemli kazanımı, sistemin artık tek bir kişiye bağlı olmaması. Bu yüzden:

• Neyin nasıl çalıştığı yazılı hale getiriliyor,
• Erişimler işletmenin kontrolünde toplanıyor,
• Güncelleme, yedekleme ve izleme düzenli bir bakım planına bağlanıyor.

Aynı durumu tekrar yaşamamak için

Yeni bir yazılım projesine başlarken şu konuları baştan netleştirmek, ileride aynı sorunu yaşamamanın en iyi yolu:

• Alan adı, sunucu ve servis hesapları kimin adına açılacak?
• Kaynak kod ve teknik belgeler talep edildiğinde devredilebilecek mi?
• Yayın sonrası destek ve bakım nasıl sağlanacak?

Özel yazılım ve entegrasyon hizmetimizde başka ekiplerden kalan projeleri devralıyor; önce kodu ve altyapıyı inceleyip durumunu açıkça raporluyoruz. Sisteminizi anlatın, nereden başlamak gerektiğini birlikte belirleyelim.

Projeyi yapan firmadan ayrılma tarafını, yani alan adı, sunucu ve kaynak kodun nasıl geri alınacağını web sitesi yapan firmadan ayrılmak yazımızda anlattık.

Özel yazılımın ne olduğunu ve ne zaman gerektiğini özel yazılım geliştirme nedir? yazımızda anlattık.