Geliştiricisi ayrılmış, eski ajansla yollarınızın ayrıldığı ya da kimsenin dokunmaya cesaret edemediği bir yazılımı yeni bir ekibe devretmek mümkündür. Ama bu iş "kodu verin, devam edelim" kadar kısa değildir. Sağlıklı bir devralma; erişimlerin toplanması, yazılımın mevcut durumunun çıkarılması ve risklerin önceliklendirilmesiyle başlar. Yazılım bakım ve destek sürecinin ilk adımı, neyi devraldığınızı bilmektir.
Kısaca
- Devralmanın ilk işi erişimleri toplamak: kaynak kod, sunucu, alan adı, veritabanı, üçüncü taraf hesapları.
- Ardından mevcut durum incelemesi yapılır: sürümler, güvenlik, yedekler, belgeler, entegrasyonlar.
- Teknik borç, yazılımın iç kalitesindeki sorunların her yeni değişikliği yavaşlatmasıdır; hepsini birden ödemek gerekmez.
- Bakım (güncelleme, güvenlik, yedek) ile geliştirme (yeni özellik) ayrı planlanmalıdır.
- Yeniden yazmak çoğu zaman ilk akla gelen ama en riskli seçenektir; önce yazılımı güvenli hale getirip adım adım iyileştirmek genellikle daha güvenlidir.
Hangi durumlarda yazılım devralınır?
- Yazılımı geliştiren kişi ya da firma artık destek vermiyor.
- Destek veriliyor ama yavaş, pahalı ya da öngörülemez.
- Yazılım çalışıyor ama kimse yeni özellik eklemeye cesaret edemiyor.
- Sunucu, dil ya da framework sürümü eskidiği için güvenlik riski oluştu.
- İşletme büyüdü; yazılımın da büyümesi gerekiyor.
Bu durumların hepsinde amaç aynıdır: Yazılımı yeniden kontrol edilebilir hale getirmek.
Adım 1: Erişimleri toplayın
Devralmanın en kritik ve en çok ihmal edilen adımı budur. Kod ne kadar iyi olursa olsun, erişimler eksikse yeni ekip yazılımı güvenle değiştiremez. Şunların işletmenin adına ve sizin kontrolünüzde olduğundan emin olun:
| Erişim | Neden önemli? |
|---|---|
| Kaynak kod deposu (Git vb.) | Kodun güncel ve eksiksiz hali; değişiklik geçmişi |
| Sunucu / barındırma paneli | Yazılımın çalıştığı ortam |
| Alan adı yönetimi | Sitenin ve e-postanın yönlendirmeleri |
| Veritabanı | İşletmenizin asıl varlığı olan veri |
| Yedekler | Bir sorun anında geri dönebilmek |
| Üçüncü taraf hesapları | SMS, WhatsApp, e-posta, ödeme, harita, muhasebe API'leri |
| Lisanslar | Ücretli eklenti, tema ya da kütüphane lisansları |
| Mağaza hesapları (mobil uygulama varsa) | Uygulamanın güncellenebilmesi |
Ne yazık ki sık rastlanan bir sorun, bu hesapların eski geliştiricinin kişisel hesabında açılmış olmasıdır. Ayrılık dostane olsa bile hesapların devri zaman alabilir. Bu yüzden erişim devri, teknik incelemeden önce başlamalıdır. Kaynak kod ve hakların sözleşmede nasıl ele alınması gerektiğini Özel Yazılım Nedir? yazımızda anlattık.
Adım 2: Mevcut durumu çıkarın
Erişimler toplandıktan sonra yazılımın bir "sağlık raporu" hazırlanır. Bu inceleme şu sorulara cevap arar:
- Kod deposundaki sürüm, canlıda çalışanla aynı mı? Zaman zaman canlı sunucuda, depoda olmayan değişiklikler bulunur.
- Hangi dil, framework ve kütüphane sürümleri kullanılıyor? Bunlar hâlâ güvenlik güncellemesi alıyor mu?
- Yedekler alınıyor mu ve geri yüklenebiliyor mu? Hiç denenmemiş bir yedek, yedek sayılmaz.
- Belgeler var mı? Kurulum adımları, veritabanı yapısı, entegrasyonların nasıl çalıştığı.
- Test var mı? Değişiklik yapıldığında bir şeyin bozulup bozulmadığını gösteren otomatik testler.
- Hangi dış sistemlere bağlı? Her entegrasyonun kimlik bilgileri, sınırları ve hata davranışı. Entegrasyonların mantığını API Entegrasyonu Nedir? yazımızda ele aldık.
- Bilinen hatalar ve kullanıcı şikâyetleri neler? Ekibin "şuna dokunmayın" dediği yerler genellikle en önemli bulgulardır.
Sürüm desteği neden bu kadar önemli?
Yazılımın üzerinde çalıştığı dil ve framework'lerin de bir ömrü vardır. Örneğin PHP'nin resmî destek politikasına göre her ana sürüm iki yıl aktif destek, ardından iki yıl yalnız güvenlik desteği alır. Aralık 2025 itibarıyla PHP 7.4 ve 8.0 artık güvenlik güncellemesi almıyor; PHP 8.1'in güvenlik desteği 31 Aralık 2025'te sona eriyor. Yani bu sürümlerden birinde çalışan bir yazılımda yeni bulunan açıklar artık resmî olarak kapatılmayacaktır.
Ancak sürüm yükseltme, kodda değişiklik gerektirebilir. Bu yüzden devralma incelemesinde "hangi sürümdeyiz, nereye geçmemiz gerekiyor, bu ne kadar iş?" sorusu mutlaka cevaplanmalıdır.
Teknik borç nedir ve ne yapmalı?
Teknik borç (technical debt), Ward Cunningham'ın ortaya attığı bir benzetmedir. Martin Fowler'ın anlatımıyla, yazılımın iç kalitesindeki sorunlar (karışık yapı, tekrar eden kod, eksik testler) yeni bir özelliği eklemeyi zorlaştırır. Bu ekstra emek, borcun faizi gibidir. Kodu düzeltmek ise anaparayı ödemektir.
Fowler'ın önemli bir uyarısı vardır: Bu faiz yalnızca o koda dokunduğunuzda ödenir. Bu yüzden teknik borcun tamamını bir anda ödemek gerekmez. Genellikle sık değiştirilen bölümlerden başlamak, hiç dokunulmayan ve sorunsuz çalışan bölümleri ise olduğu gibi bırakmak en mantıklı yoldur.
Pratikte teknik borç şöyle önceliklendirilebilir:
- Hemen: Güvenlik açıkları, desteği biten sürümler, çalışmayan yedekler.
- Kısa vadede: Sık değiştirilen ve her değişiklikte hata çıkaran bölümler.
- Fırsat buldukça: Yeni özellik eklenirken dokunulan bölümlerin iyileştirilmesi.
- Dokunmayın: Sorunsuz çalışan ve değişmesi gerekmeyen bölümler.
Yeniden yazmak mı, iyileştirmek mi?
Eski bir yazılımı devralan ekiplerin ilk tepkisi çoğu zaman "bunu baştan yazalım" olur. Bazen gerçekten doğru karar budur: teknoloji tamamen desteksiz kalmışsa ya da yazılım işin bugünkü haline hiç uymuyorsa. Ama yeniden yazmanın riskleri de büyüktür:
- Eski yazılımın yıllar içinde biriktirdiği, belgelenmemiş kurallar kaybolabilir.
- Yeni yazılım bitene kadar eskisinin bakımı yine gerekir; iki sistem birden yönetilir.
- Süre ve bütçe tahmini, sıfırdan bir projeye göre daha belirsizdir.
Çoğu durumda daha güvenli yol şudur: Önce yazılımı güvenli ve izlenebilir hale getirmek, ardından en sorunlu bölümleri adım adım yenilemek. Bu yaklaşım, işinizi durdurmadan ilerlemeyi sağlar.
Bakım ile geliştirme arasındaki fark
| Bakım | Geliştirme | |
|---|---|---|
| Amaç | Yazılımın güvenli ve çalışır kalması | Yazılıma yeni yetenek eklemek |
| İçerik | Güncellemeler, güvenlik yamaları, yedek kontrolü, izleme, hata düzeltme | Yeni ekran, rapor, entegrasyon, kural |
| Planlama | Düzenli, sürekli | İhtiyaca göre, proje ya da aşama olarak |
| Ertelenirse | Risk birikir, teknik borç büyür | Fırsat kaçar ama sistem çalışmaya devam eder |
İkisini aynı bütçe kaleminde tutmak, bakımın sürekli yeni özellik isteklerinin gölgesinde kalmasına yol açar. Bu nedenle ikisini ayrı planlamak daha sağlıklıdır. Web siteleri tarafındaki karşılığı için Web Sitesi Bakımı Neden Gerekli? yazımıza bakabilirsiniz.
İlk 30 gün için örnek plan
- 1. hafta: Erişimlerin devri, canlı ortamın ve kod deposunun eşleştirilmesi, tam yedek.
- 2. hafta: Mevcut durum incelemesi; sürümler, güvenlik, entegrasyonlar, bilinen hatalar.
- 3. hafta: Bulguların önceliklendirilmesi ve size yazılı rapor; acil güvenlik işleri.
- 4. hafta: Bakım planının başlatılması ve ilk geliştirme aşamasının kapsamı.
Bu bir şablondur; yazılımın büyüklüğüne göre süreler değişir. Önemli olan sıradır: önce erişim ve yedek, sonra değişiklik.
Bizim deneyimimiz
Yazılım hizmetlerimiz arasında mevcut yazılımlara destek de yer alıyor. Mevcut bir sistemi devralırken ilk iş olarak erişimleri ve yedekleri güvenceye alıyor, değişiklikleri doğrudan canlı ortamda değil, önce bir kopya üzerinde deniyoruz. WordPress tabanlı sitelerde bu kopyayı All-in-One WP Migration ile yerel ortama alıp orada çalışıyor, sonra canlıya taşıyoruz.
Kendi sitemizin altyapısından bir örnek: LiteSpeed Cache'teki "Konuk İyileştirme" (guest optimization) özelliği, JavaScript'i ilk etkileşime kadar geciktirip menü ve formları bozabiliyor; bu yüzden bu özelliği kapalı tutuyoruz. Devralınan sistemlerde de benzer şekilde, bir sorunun kaynağı kodda değil bir ayarda olabilir. Bu yüzden incelemeye kod kadar yapılandırmayı da dahil ediyoruz.
Sık sorulan sorular
Kaynak kod elimizde yoksa yazılım devralınabilir mi?
Zorlaşır. Web tabanlı yazılımlarda kod çoğu zaman sunucuda durduğu için sunucu erişimiyle alınabilir. Ancak derlenmiş uygulamalarda (ör. mobil uygulamalar) kaynak kod olmadan anlamlı geliştirme yapmak çoğu zaman mümkün değildir. Önce eski geliştiriciyle kod ve hesap devrini konuşmak gerekir.
Devralma incelemesi ne kadar sürer?
Yazılımın büyüklüğüne, belgelerin durumuna ve erişimlerin ne kadar hızlı devredildiğine bağlıdır. Küçük bir panel ile çok sayıda entegrasyonu olan bir sistem aynı sürede incelenemez. Her iki durumda da inceleme sonunda yazılı bir rapor almanızı öneririz.
Eski ekip kodu kötü yazmış, her şey baştan mı yazılmalı?
Her zaman değil. "Kötü görünen" kod bazen yıllar içinde biriken, belgelenmemiş iş kurallarını taşır. Önce yazılımın neyi neden yaptığını anlamak, sonra bölüm bölüm iyileştirmek çoğu zaman daha güvenli ve öngörülebilirdir.
Bakım yaptırmazsak ne olur?
Yazılım bir süre çalışmaya devam eder. Ama desteği biten sürümlerde güvenlik açıkları kapanmaz, bağlı olduğu dış servisler değiştikçe entegrasyonlar bozulabilir ve teknik borç büyür. Sorun genellikle en ihtiyaç duyduğunuz anda ortaya çıkar.
Sonuç
Mevcut bir yazılımı devralmak; erişimleri toplamak, durumu dürüstçe ortaya koymak ve riskleri sırayla ele almakla başarılı olur. Teknik borcun hepsini birden ödemek gerekmez; önemli olan sık dokunulan ve riskli bölümlerden başlamaktır. Geliştiricisinden destek alamadığınız bir yazılımınız varsa Yazılım ve Dijital Çözümler sayfamıza göz atabilir ya da bizimle iletişime geçebilirsiniz.
