Yarım kalmış yazılım projesi nasıl devralınır? Adım adım denetim planı
C.E.O. Bee Mühendislik13 dk okuma
Yarım kalmış yazılım projesini devralırken önce kaybolabilecek şeyleri güvene alın: depo, barındırma, alan adı, veritabanı ve üçüncü taraf hesaplarına erişim. Ardından aşamalı bir denetim planı uygulayın: temiz makinede kurulum, yedekten geri yükleme, güvenlik ve veri sağlığı, özellik envanteri. Karar, yedi boyutlu 0–2 puanlı bir matrisle devam, kısmi yeniden yazım ya da sıfırdan başlama olarak verilir ve gerekçesiyle yazıya dökülür. Süre; kodun, belgelerin, erişimlerin ve platformların durumuna bağlıdır ve yazılı teklifte yer alır.
İlk 48 saat: erişimleri ve kanıtları güvene alın
Yarım kalmış yazılım projesini devralırken ilk refleks, kodun ne durumda olduğuna bakmaktır. Daha acil olan, kaybolabilecek şeyleri güvene almaktır: bir hesaba erişim, bir alan adı, bir veritabanı kopyası. Kodu değerlendirmek bir hafta bekleyebilir; bir alan adının eski geliştiricinin hesabında kalması beklemez. Projeniz özel yazılım kapsamında yazılmış olsun ya da olmasın, sıra aynıdır. Aşağıdaki liste bir şablondur; süreyi projenin büyüklüğü belirler.
- Kaynak kod deposu. Kimin hesabında? Depo sizin kuruluşunuza yönetici olarak eklenmeli ya da tüm dalları ve etiketleriyle bir kopyası alınmalı:
git clone --mirror <adres>. - Barındırma ve sunucu. Hesabın sahibi, faturanın kime kesildiği, yönetici erişimi ve sunucu anahtarları.
- Alan adı ve DNS. Alan adının kayıt şirketindeki hesabı kimin? DNS'i kim yönetiyor? Alan adı eski geliştiricinin hesabındaysa sitenizin ve e-postanızın erişimi ona bağlı kalır; bu, listenin en acil maddesidir.
- Mağaza hesapları. Apple ve Google geliştirici hesabı kimin adına? İki mağazanın da devir yolu var: Apple'da uygulama devri, devreden hesabın sahibi tarafından başlatılır ve alıcı hesap sahibi kabul eder; devirden önce TestFlight beta testleri kapatılmalı ve Xcode Cloud verileri kaldırılmalı, otomatik yenilenen abonelik varsa uygulamaya özel bir paylaşılan anahtar (shared secret) üretilip alıcıyla paylaşılmalıdır (Apple). Google Play'de iki geliştirici hesabı da kayıtlı ve etkin olmalı, hedef hesabın kayıt işlem kimliği gerekir ve destek ekibi talebi iki iş günü içinde yanıtlar; kullanıcılar, puanlar ve mağaza girişi uygulamayla taşınır; toplu dışa aktarım, satış ve kazanç raporları ile test grupları taşınmaz (Google). Hesabın tamamını devretmek ise yedi günlük bir güvenlik beklemesi içerir ve hesap sahibi erişimini kaybetmişse kendi başına yürütülemez (Google).
- Üçüncü taraf hesaplar. Ödeme sağlayıcısı, e-posta ve SMS servisi, analitik, harita, bildirim, yapay zeka API'leri, hata izleme.
- Veritabanı. Nerede duruyor, kimin hesabında, erişim bilgisi kimde? Tam bir döküm alın.
- E-posta. Alan adına bağlı e-posta hesapları ve gönderim servisi.
- Yedek ve ardından anahtar değişimi. Önce her şeyin yedeğini alın, sonra eriştiğiniz her anahtarı, parolayı ve belirteci değiştirin: eski geliştiricinin ve eski araçların bildiği her sır artık güvenli sayılamaz. Bir sır sızmışsa ya da sızmış olabilirse önce iptal edilip yenilenir: OWASP, ele geçirilmiş olabilecek sırların güvenli biçimde iptal edilmesini söyler (OWASP). Yalnızca geçmişten silmek bunun yerine geçmez.
- Belgeler. Sözleşme, teklif, fatura ve ödeme kayıtları, teslim tutanakları, yazışmalar. Kapsama ve devre ilişkin iddialarınızı bu belgelerle desteklersiniz.
Eski ekipten istenecekler
Eski ekip ulaşılabilir durumdaysa aşağıdaki listeyi yazılı isteyin ve yanıtları saklayın. Ulaşılamıyorsa her satır, elinizde olmayanın ne anlama geldiğini gösteren bir risk satırıdır.
| Öğe | Neden gerekli? | Yoksa ne olur? |
|---|---|---|
| Kaynak kod (tüm dallar ve geçmiş) | Her şeyin temeli | Elinizde yalnızca çalışan sürüm kalır; değişiklik yapılamaz |
| Veritabanı dökümü ve şema | Veri ve veri modeli | Canlı veriye bağımlı kalırsınız, yeniden kurulum yapılamaz |
| Ortam değişkenleri listesi (adlar; değerler güvenli kanaldan) | Uygulama hangi servislere bağlanıyor, hangi ayarla çalışıyor? | Kurulum tahmine dayanır |
| Dağıtım betikleri ve altyapı tanımı | Sistem nasıl yayınlanıyor, nasıl yeniden kurulur? | Her yayın ve felaket kurtarma bir keşif işine döner |
| Tasarım dosyaları | Ekranların ve markanın kaynağı | Arayüz yeniden çizilir |
| API belgeleri ve entegrasyon bilgileri | Dış sistemlerle konuşma biçimi | Entegrasyonlar tersine mühendislikle çözülür |
| Hesap sahiplikleri ve yönetici erişimleri | Kontrolün kimde olduğu | Hesaplar eski ekibin elinde kalır |
| Açık işler ve bilinen hatalar listesi | Nerede kalındığı | Özellik envanterini sıfırdan çıkarmak gerekir |
| Kurulum ve çalıştırma notları | Bilgi sürekliliği | Temiz makinede kurulum, deneme yanılmaya dönüşür |
Talebinizi yazılı yapın ve yanıtı saklayın; yanıt gelmezse hukuki seçenekler için sözleşmeyi bir avukata gösterin.
Neden yarım kaldı? Denetime hangi gözle bakılır
Aynı görünen iki yarım kalmış yazılım projesi farklı nedenlerle yarım kalmış olabilir ve neden, denetimde neye bakacağınızı değiştirir. Tablodaki hiçbir satır bir hüküm değildir; her biri bir başlangıç sorusudur.
| Olası neden | Denetimde öne çıkan soru | Karara etkisi |
|---|---|---|
| Kapsam büyüdü, bütçe ya da süre bitti | Sözleşmedeki kapsam ile bugünkü özellik envanteri arasındaki fark ne? | Kod sağlam olabilir; asıl iş kapsamı yeniden kesmektir |
| Geliştirici ya da ekip ortadan kayboldu | Hangi bilgi yalnızca onlardaydı (erişim, ortam, belge)? Temiz kurulum çalışıyor mu? | Kurulabilirlik ve bilgi sürekliliği puanları belirleyici olur |
| Teknik bir engele takıldı (performans, entegrasyon) | Engel mimari bir sınır mı, çözülebilir bir hata mı? | Engel yapısalsa kısmi yeniden yazım gündeme gelir |
| "Bitti" denmiş ama çalışmıyor ya da kalitesiz | Kabul ölçütü yazılı mıydı? Test ve güvenlik durumu ne? | Test ve güvenlik puanları ağırlık kazanır; kanıtlar hukuki bir değerlendirmede de gerekebilir |
| Firma kapandı ya da iş el değiştirdi | Hesap ve kod hakları kimde kaldı? | Mülkiyet ve erişim, teknik karardan önce çözülür |
Denetim: aşamalı plan
Plan bir şablondur ve aşamalara bölünmüştür; denetim planında gün ya da hafta sayısı vermiyoruz. Her aşamanın süresi kodun, belgelerin, erişimlerin ve platformların durumuna göre değişir ve yazılı teklifte yer alır.
| Aşama | Yapılacak | Çıktı |
|---|---|---|
| 1. Envanter ve kurulum | Envanter (depo, ortamlar, hesaplar, üçüncü taraflar). Temiz makinede sıfırdan kurulum: klonlayın, bağımlılıkları yükleyin, derleyin, çalıştırın, testleri koşun. Yedekten geri yükleme. Bağımlılık ve güvenlik taraması: npm audit --omit=dev, depo geçmişinde sır taraması (git log --all -S"sk_live_"). |
Envanter tablosu; kurulum adımları belgesi (ihtiyaç duyduğunuz her el işi yazılır); "kuruluyor mu, kurulmuyor mu" kararı; açık listesi |
| 2. Kod ve veri sağlığı | Kod ve veri sağlığı: mimari, test kapsamı ve anlamlılığı, karmaşıklık, veri modeli, sırlar, performans. Sözleşme ve kapsam ile mevcut durumun karşılaştırması: özellik envanteri. | Kod ve veri bulguları; özellik envanteri ("var ve çalışıyor", "var ama yarım", "yok") |
| 3. Karar | Karar matrisi puanlaması ve seçenek taslakları. | Puanlı matris; her seçenek için kapsam ve risk notu |
| 4. Rapor | Yazılı rapor ve yeni kapsam önerisi; devam seçildiyse ilk iş paketleri. | Rapor (iskeleti aşağıda); kapsam taslağı |
Kod ve veri sağlığı: ne aranır, hangi komutla başlanır
İkinci aşama, en çok ölçülebilir kanıt toplanan aşamadır. Aşağıdaki başlangıç noktaları Git ve Node.js tabanlı projeler için örnektir; diğer teknolojilerin karşılıkları vardır.
| Bakılan şey | Neden bakılır? | Başlangıç noktası |
|---|---|---|
| Kimin ve ne zaman yazdığı | Kod bir kişiye mi bağlı, uzun bir sessizlik var mı? | git shortlog -sn --all ve git log -1 --format=%cd |
| En çok değişen dosyalar | Sürekli değişen dosyalar sorunlu ya da fazla sorumluluk yüklenmiş yerlerdir | Aşağıdaki ilk komut |
| En büyük dosyalar | Mantık birkaç dev dosyada mı toplanmış? | Aşağıdaki ikinci komut |
| Bağımlılıkların yaşı | Ne kadar geride kalınmış? | npm outdated |
| Bilinen açıklar | Üretimdeki paketlerde yüksek ya da kritik açık var mı? | npm audit --omit=dev |
| Sızmış sırlar | Depo geçmişinde canlı anahtar var mı? | git log --all --oneline -S"sk_live_" |
| Veri modeli | Kısıt, ilişki, indeks ve geçişler yerinde mi? | Şemayı dışa aktarıp okuyun: pg_dump --schema-only |
| Testler | Çalışıyor mu, bir kural bozulunca kırılıyor mu? | Testleri koşun; bir kuralı bilerek bozup sonucu görün |
# en çok değişen dosyalar
git log --name-only --pretty=format: | sed '/^$/d' | sort | uniq -c | sort -rn | head
# en büyük kaynak dosyalar
find . -name "*.js" -not -path "./node_modules/*" -not -path "./.git/*" -print0 | xargs -0 wc -l | sort -rn | head
Bu sayılar tek başına hüküm vermez; hangi yere daha dikkatli bakılacağını söyler.
Üç ayrıntı planın değerini belirler.
Temiz makinede kurulum. Bir projenin "çalıştığını" yalnızca bir kişinin bilgisayarında çalışması kanıtlamaz. Kurulum sırasında ihtiyaç duyduğunuz her belgesiz el adımı, bilgi sürekliliği borcudur ve rapora girer. Bu adım, 15 maddelik üretime hazırlık denetimindeki komutlarla birlikte kullanılabilir.
Özellik envanteri, "yüzde kaç bitti" değildir. Yarım kalmış bir yazılımın yüzde kaçının bittiğini söylemek kolaydır ve yanıltıcıdır: bitmiş görünen kısmın ardından kalan iş, baştakinden pahalı çıkabilir. Bunun yerine her özelliğin durumunu ölçülebilir bir etiketle yazın: çalışıyor, yarım, yok.
Testsiz koda dokunmadan önce. Test yazılmamış kodu değiştirmeden önce, onun şu anki davranışını olduğu gibi kaydeden "karakterizasyon testleri" yazılır; amaç kodun ne yapması gerektiğini değil, ne yaptığını sabitlemektir (Feathers).
Karar matrisi
Karar matrisi yönlendirir, hüküm vermez. Yedi boyutun her birine 0, 1 ya da 2 puan verilir (toplam 0–14).
| Boyut | 0 puan | 1 puan | 2 puan |
|---|---|---|---|
| Kurulabilirlik | Temiz makinede kurulmuyor ya da eski geliştiriciden bilgi gerekiyor | Kuruluyor ama belgesiz el adımları var | Belgeye bakarak tek seferde kuruluyor |
| Test ve yapı | Test yok, kod karışık | Kısmi test, tutarsız yapı | Kritik akışlarda anlamlı testler, okunabilir katmanlar |
| Güvenlik | Sızmış sır, yetki açığı ya da bilinen kritik açık | Düzeltilebilir küçük açıklar | Temel kontroller (kimlik, yetki, sırlar, girdi doğrulama) geçti |
| Veri modeli | Tutarsız, kısıtsız, taşınması riskli | Eksikler var ama dönüştürülebilir | Tutarlı ve genişletilebilir |
| Mimari uyumu | Yeni kapsam mevcut yapıya sığmıyor | Büyük uyarlamayla sığar | Sığıyor |
| Belge | Yok | Dağınık | Kurulum ve mimari belgeli |
| Bilgi sürekliliği | Kodu bilen kimse yok, eski ekibe ulaşılamıyor | Kısmen ulaşılabilir | Bilgi belgede ya da elde olan ekipte |
Karar bandı (öneri, standart değil): 11–14 puan devam; 6–10 puan kısmi yeniden yazım (zayıf katmanlar yenilenir, sağlam olanlar korunur); 0–5 puan sıfırdan başlama (ekranlar, akış ve öğrenilenler korunur, kod değil). Güvenlik ya da veri modeli sıfır alıyorsa toplam ne olursa olsun o katmanın yeniden kurulması gerekir.
Üç kararın pratikte ne anlama geldiği şöyle özetlenebilir.
| Karar | Korunan | Yenilenen | Tipik sinyal | Dikkat edilecek |
|---|---|---|---|---|
| Devam | Kod, veri modeli ve yapının büyük kısmı | Eksik özellikler ve küçük düzeltmeler | Kurulabilir; güvenlik ve veri modeli en az 1 puanda | İlerlerken test ekleyin |
| Kısmi yeniden yazım | Sağlam katmanlar (örneğin veri modeli ya da arayüz) | Zayıf katmanlar (örneğin yetkilendirme ya da ödeme) | Bazı boyutlar 0, bazıları 2 | Katman sınırlarını belirleyin; geçişi kademeli yapın |
| Sıfırdan başlama | Ekranlar, akış, öğrenilenler; veri taşınarak | Kod | Çoğu boyut 0; kurulmuyor, güvenlik ya da veri modeli temelden sorunlu | Eski sistem çalışıyorsa paralel yürütün; bir veri taşıma planı yazın |
Matris iki uç görüşün arasında yol bulmaya yardım eder. Joel Spolsky, çalışan kodu baştan yazmanın stratejik bir hata olabileceğini savundu, çünkü eski kod yıllarca sınanmış hata düzeltmelerini taşır (Spolsky). Martin Fowler'ın "boğucu asma" yaklaşımı ise eski sistemi tek hamlede değiştirmek yerine yenisini yanına kurup işlevi kademeli taşımayı önerir (Fowler). Bazen sıfırdan yazmak doğrudur; denetim bunu da söyler. Kural yoktur, gerekçeli bir karar vardır.
Karardan sonra: yeni kapsamı kesmek
Karar "devam" ya da "kısmi yeniden yazım" çıkarsa özellik envanteri, yeni kapsamın ham maddesidir. Her özelliği üç kutudan birine koyun: şimdi, sonra, hiç. "Hiç" kutusu boşsa kapsam henüz kesilmemiştir. Eski kapsamın tamamını tek seferde bitirmeye çalışmak, aynı yarım kalma riskini yeniden kurar. MVP geliştirme sayfamızda anlattığımız kapsam kesme yöntemi burada da işe yarar: tek ana akış, sınanacak tek hipotez ve başarıyı neyle ölçeceğiniz. Yeni kapsamı yazıya dökerken yazılım teklifi nasıl okunur yazısındaki kapsam belgesi (SOW) şablonu da başlangıç iskeleti olarak kullanılabilir.
Rapor iskeleti
Denetimin çıktısı yazılı bir rapordur. Aşağıdaki on başlık, hem sizin hem sonraki ekibin okuyabileceği bir iskelet sunar.
- Özet ve karar önerisi (bir sayfa)
- Kapsam ve yöntem: ne incelendi, ne incelenmedi
- Erişim ve sahiplik envanteri
- Kurulum sonucu (temiz makine)
- Özellik envanteri: sözleşme ile mevcut durum
- Güvenlik ve veri bulguları, önem sırasıyla
- Kod ve mimari değerlendirmesi
- Karar matrisi ve puanların gerekçesi
- Seçenekler: devam, kısmi yeniden yazım, sıfırdan; her biri için kapsam, risk ve bağımlılıklar
- Önerilen yeni kapsam ve sonraki adımlar
Rapora yüzde ve süre tahmini yerine ölçülebilir durumlar ve gerekçeler yazın.
Mülkiyet ve hukuki notlar
Bu bölüm hukuki danışmanlık değildir; yalnızca hangi soruların sorulması gerektiğini gösterir. Sözleşmeyi bir avukata okutun.
- Kod hakları. Kodu eline geçirmek, o kod üzerindeki haklara sahip olmakla aynı şey olmayabilir. 5846 sayılı Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi, mali haklara dair sözleşme ve tasarrufların yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşuyor (mevzuat.gov.tr). Eski ekiple yaptığınız sözleşmede devir yazılı mı?
- Hesaplar. Geliştirici hesapları, depo ve barındırma hesapları kimin adına? Mağaza devri için yukarıdaki resmî yollar var; hesap eski ekibin elindeyse süreç uzayabilir.
- Lisanslar. Üçüncü taraf kütüphanelerin ve servislerin lisansları ve sözleşmeleri, kodun devrinden ayrı olarak gözden geçirilmelidir.
- Kişisel veri. Kullanıcı verisi eski ekibin sistemlerinde kalmış olabilir. 6698 sayılı Kanun'un 12. maddesine göre veri sorumlusu gerekli tedbirleri almakla yükümlüdür ve verilerin kendi adına başka biri tarafından işlenmesi halinde onunla birlikte sorumludur (mevzuat.gov.tr). Verinin yeni ekibe geçişini yazılı bir düzene bağlayın.
Maliyet nasıl modellenir?
Yazılım projesi devralma maliyeti tek bir kalem değildir. Makul bir yapı, önce sabit kapsamlı bir denetim, ardından denetimin çıktısına dayanan kapsam bazlı bir projedir; çünkü denetimden önce neyin kurtarılacağını bilmeden verilen bir proje fiyatı tahmindir. Denetimin kendi maliyetini belirleyen şeyler kodun büyüklüğü, belge ve erişim durumu, entegrasyon ve platform sayısı (web, iOS, Android) ve verinin hacmidir. Bu yazıda rakam vermiyoruz. Fiyatı belirleyen kalemlerin genel dökümü için özel yazılım geliştirme sayfasındaki "Fiyat neye bağlı?" tablosuna bakabilirsiniz. Yarım kalan şey bir mobil uygulamaysa teklifte görmeniz gereken kalemler mobil uygulama maliyeti yazısında.
Sonraki adım
Ana sayfamızda yazdığımız gibi bir fikir, bir ihtiyaç ya da yarım kalmış bir proje ile gelebilirsiniz; size en uygun yerden başlıyoruz. Elinizde ne olduğunu birlikte konuşur, nereden devam edileceğini yazılı teklife döker; yöntem ve süre elinizdeki duruma göre değişir ve teklifte yer alır. Projenizi anlatın ya da önce özel yazılım geliştirme sayfamızı okuyun.
Sık sorulan sorular
Eski geliştirici kodu vermiyorsa ne yapmalıyım?
Önce sözleşmenize ve ödeme kayıtlarınıza bakın: ne teslim edilmesi gerekiyordu? Talebinizi yazılı yapın ve yanıtı saklayın; hukuki seçenekler için sözleşmeyi bir avukata gösterin. Barındırma hesabı sizdeyse sunucudaki çalışan sürümün ve veritabanının bir kopyasını almak mümkün olabilir; bu, elinizdeki en güncel gerçektir ama kaynak kodun yerini tutmaz. Böyle bir kopyayı kullanmadan önce sözleşmenizdeki hak ve lisans maddelerine bakın.
Devralma maliyeti neye bağlı?
Kodun büyüklüğüne, belge ve erişim durumuna, entegrasyon ve platform sayısına, veri hacmine ve yeni kapsamın büyüklüğüne. Bu yazıda rakam vermiyoruz; önce kapsamı sabit bir denetim yapmak ve ardından kapsam bazlı bir teklif almak, fiyatı tahminden çıkarır.
Denetim ne kadar sürer?
Bu yazıdaki denetim planı aşamalara bölünmüş bir şablondur ve süre içermez. Gerçek süre kodun büyüklüğüne, belge ve erişim durumuna, platform sayısına ve entegrasyonlara bağlıdır. Bizde yöntem ve süre elinizdeki duruma göre değişir ve yazılı teklifte yer alır.
Başka firmanın yazdığı kodun üzerinde çalışır mısınız?
Ana sayfamızda "yarım kalmış bir proje" ile gelebileceğinizi yazıyoruz. Elinizde ne olduğunu birlikte konuşur, üzerine kurmanın mı yoksa yeniden başlamanın mı doğru olduğuna gerekçesini yazarak karar veririz. Yöntem ve süre elinizdeki duruma göre değişir.
Sıfırdan yazmak mı gerekir?
Bazen evet. Karar matrisi buna yardım eder: güvenlik ya da veri modeli sıfır alıyorsa o katman yeniden kurulur; ekranlar, akış ve öğrenilenler çoğu zaman korunabilir. Karar, gerekçesiyle birlikte yazılı olmalıdır.
Kaynaklar
Aşağıdaki sayfalar 24 Ekim 2026'da açılıp okundu. Mağaza kuralları zamanla değişebilir; işlem yapmadan önce resmî sayfaları yeniden açın.
- Apple: App Transfer genel bakış · Google Play: uygulamaları başka bir geliştirici hesabına devretme · Google Play: geliştirici hesabı sahipliğini devretme
- OWASP Secrets Management Cheat Sheet · npm audit
- Michael Feathers, Characterization Testing · Joel Spolsky, Things You Should Never Do, Part I · Martin Fowler, Strangler Fig Application
- 5846 sayılı Fikir ve Sanat Eserleri Kanunu, mevzuat.gov.tr · 6698 sayılı Kişisel Verilerin Korunması Kanunu, mevzuat.gov.tr
Bu yazı genel bilgi içindir; hukuki danışmanlık değildir.
— İlgili hizmetÖzel Yazılım Geliştirme