Bilgisayarımdaki /home/mustafa/dev/projects dizini bir dijital mezarlık gibi. İçinde 2012’den kalma, yarım bırakılmış PHP scriptlerinden tutun, 2021’de “bu kesin tutar” dediğim ama sadece 3 kişinin (biri annem) kullandığı Golang backend’lerine kadar her şey var. 20 yıllık saha tecrübem bana şunu öğretti: Bir projeyi başlatmak heyecan verici, büyütmek zor, ama fişini çekmek gerçek bir profesyonellik göstergesi.
Çoğu zaman duygusal bağ kuruyoruz. “Oraya 3 hafta sonumu gömdüm,” “O PostgreSQL şemasını tasarlamak için sabahladım,” ya da “Domain çok jenerik, bir gün lazım olur” gibi bahanelerle kendimizi kandırıyoruz. Gerçekte ise o proje sadece docker stats çıktısında boşuna yer kaplayan 120 MB RAM ve her yıl kredi kartından çekilen 15 dolarlık bir domain ücretinden ibaret. Bugün, kendi projelerimde uyguladığım “öldürme kriterlerini” ve teknik temizlik sürecimi anlatacağım.
Altyapı Maliyeti ve “Idle” Çalışan Kaynaklar
Bir yan ürünün (side project) maliyeti sadece para değildir; zihinsel yükü paradan çok daha pahalıdır. Kendi VPS’imde çalışan küçük bir finansal hesaplayıcı vardı. Günde topu topu 5-10 kişi giriyordu ama arkada çalışan bir PostgreSQL instance, bir Redis ve bir de Nginx reverse proxy vardı. Bir gün top komutuyla baktığımda, bu projenin boşta dururken bile sistem kaynaklarının %15’ini sömürdüğünü gördüm.
Özellikle Docker konteynerleri “nasılsa izole” diyerek her şeyi dolduruyoruz. Ancak her bir systemd unit’i veya Docker konteyneri, log yazıyor, journald üzerinde yer kaplıyor ve kernel seviyesinde context switching yükü yaratıyor. Geçen yıl, artık trafik almayan 4 farklı küçük projeyi kapattığımda, sunucudaki Load Average değerinin 0.85’ten 0.12’ye düştüğünü gördüm. Bu, ana işim olan ve gerçek para kazandıran uygulamalar için daha stabil bir ortam demekti.
# Boşta yatan projeleri tespit etmek için kullandığım basit bir izleme yöntemi
# Son 30 günde Nginx loglarında istek almayan upstream'leri buluyorum
grep "14/Apr/2026" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nrEğer bir proje son 3 ayda organik bir büyüme göstermediyse ve teknik olarak “maintenance mode” bile değil, bildiğin “terk edilmiş” durumdaysa, o VPS maliyetini hak etmiyordur. Ben artık 10 dolarlık bir sunucuda 20 tane “belki” projesi tutmak yerine, 2 tane “çalışan” projeye yatırım yapıyorum.
Bağımlılık Cehennemi ve Kodun Çürümesi (Bit Rot)
Kod yazıldığı gün tazedir, ertesi gün bayatlamaya başlar. Bir yan ürünümü (bir Android spam engelleyici uygulamasıydı) 6 ay boyunca güncellemedim. Geçen hafta bir bug fix için projeyi açtığımda, Gradle versiyonunun artık desteklenmediğini, kullandığım 3 farklı kütüphanenin “deprecated” olduğunu ve API seviyesinin Play Store standartlarının altında kaldığını gördüm.
İşte “fişten çekme” kararının en net verildiği an budur: Maintenance (Bakım) maliyeti, geliştirme maliyetini geçtiği an. Eğer basit bir text değişikliği yapmak için 4 saatlik bir dependency hell içine giriyorsanız, o proje artık sizin için bir değer değil, bir ayaktır. Projeyi ayağa kaldırmak için npm install yazdığınızda çıkan 45 tane critical vulnerability uyarısı, size “beni artık göm” diyen bir mesajdır.
Kendi sistemlerimde, özellikle Python tabanlı backend projelerinde, pip freeze çıktısının zamanla ne kadar kirlendiğini görüyorum. Bir noktadan sonra requirements.txt dosyasındaki sürümler arasındaki uyumsuzluk, projeyi bir “dokunulmaz” haline getiriyor. Dokunmaya korktuğunuz kod, ölü koddur.
Domain Yenileme Tuzağı: “Bir Gün Lazım Olur”
Hepimizin bir “domain mezarlığı” var, biliyorum. 2018’de “akıllı tarım otomasyonu” yaparım diye aldığım domaini 2024’e kadar her yıl yeniledim. Toplamda 90 dolar ödemişim ama ortada ne bir sensör var ne de bir satır kod. Domain yenileme maili geldiğinde o anki adrenalinle “bu sene kesin yapacağım” diyoruz.
Benim artık bir kuralım var: Eğer domainin altında çalışan bir index.html bile yoksa ve son 1 yılda o domain üzerine tek bir commit atmadıysam, yenileme mailini gördüğüm an “Auto-renew” butonunu kapatıyorum. Domaini bırakmak, projeyi kafada bitirmenin en somut adımıdır.
VPS maliyetlerini optimize etme yazımda da bahsettiğim gibi, gereksiz her asset (varlık), zihninizde bir “tamamlanmamış iş” klasörü açar. Bu klasörler ne kadar çoksa, asıl odaklanmanız gereken işlere o kadar az RAM (beyin gücü) ayırırsınız.
| Kriter | Ölüm Kararı (Kill) | Yaşat (Keep) |
|---|---|---|
| Trafik | Son 90 gün < 100 tekil ziyaretçi | Düzenli artış veya stabil kitle |
| Güvenlik | Unpatched CVE’ler, eski kernel modülleri | Güncel bağımlılıklar |
| Maliyet | Aylık > $10 (hiç kazanç yoksa) | Gelir > Gider veya yüksek öğrenme değeri |
| Motivasyon | Kodunu açmaya korkuyorsun | Yeni özellik eklemek için sabırsızsın |
Fişten Çekme Protokolü: Güvenli İmha
Bir projeyi kapatmaya karar verdiğimde, “delete” tuşuna basıp geçmiyorum. 20 yıllık sistemci refleksi işte, her zaman bir “exit strategy” (çıkış stratejisi) olmalı. Bir gün o koddaki bir algoritma veya o veritabanındaki 3-5 satır veri lazım olabilir.
Uyguladığım standart “Kill Protocol” şu şekilde:
- Veritabanı Dump: PostgreSQL kullanıyorsam
pg_dumpile şemayı ve veriyi alırım. Veri küçükse JSON olarak da export ederim ki ileride başka bir dille (mesela FastAPI yerine Go ile) bir şey yaparsam parse etmesi kolay olsun. - Statik Arşiv: Eğer bir web sitesiyse,
wget --mirrorile sitenin statik bir kopyasını alırım. En azından “neye benziyordu” diye bakmak için. - Code Archive: Proje klasörünü
tar.gzyapıp S3 üzerinde çok ucuz bir “Glacier” bucket’ına veya fiziksel bir harici diske atarım. GitHub’da “Archived” işaretlerim. - Cleanup: Sunucudaki
systemdunit’ini silerim, Docker imajlarınıdocker rmiile temizlerim ve Nginx konfigürasyonunu kaldırırım.
# PostgreSQL yedeği alıp sıkıştırma örneği
pg_dump -U mustafa_user -h localhost my_dead_project_db | gzip > my_dead_project_db_$(date +%Y%m%d).sql.gz
# Docker sistem temizliği (dikkatli kullanın)
docker system prune -a --volumesBu süreçten sonra gelen o hafifleme hissi paha biçilemez. Sunucuda fazladan 400 MB RAM açılması, diskteki %85 doluluk oranının %60’a düşmesi size yeni ve daha mantıklı projeler için alan açar.
Kurumsal Yazılım Bakış Açısı ve “Opportunity Cost”
Bir üretim ERP’si geliştirirken gördüğüm en büyük hata, “her modül her zaman çalışmalı” takıntısıydı. Bazı raporlar vardı ki, 5 yıl önce bir müdür istemiş, müdür işten ayrılmış ama o rapor her gece 03:00’te SQL sunucusunu yorarak çalışmaya devam ediyordu. Side project’lerde de aynı hatayı yapıyoruz.
“Opportunity Cost” (Fırsat Maliyeti) kavramını iyi anlamak lazım. Ölü bir projeyi ayakta tutmak için harcadığınız her saat, aslında potansiyeli olan yeni bir fikirden çaldığınız zamandır. Eğer bir uretim planlama algoritması üzerinde çalışıyorsam ve eski bir “hava durumu botu” hata verdiği için alarm çalıyorsa, o botu tamir etmek benim için bir zaman kaybıdır.
Bir keresinde kendi yan ürünümün backend’inde bir memory leak (bellek sızıntısı) oluşmuştu. Her 12 saatte bir OOM-killer devreye girip süreci öldürüyordu. Ben de üşendiğim için her 6 saatte bir restart atan bir cron job yazmıştım. İşte bu, bir projeyi fişten çekmeniz gerektiğinin teknik kanıtıdır. Sorunu çözmek yerine etrafından dolanmaya başladıysanız, o proje artık sizin için bir yük haline gelmiştir.
Mezarlıktan Çıkarılan Dersler
Kapatılan her proje bir başarısızlık değil, bir veri noktasıdır. Android tarafında geliştirdiğim o spam engelleyiciyi kapattığımda şunu öğrendim: “Mobil tarafta native bridge kurmak çok maliyetli, bir dahaki sefere daha basit bir mimari seçmeliyim.” Veya bir finansal hesaplayıcımı kapattığımda: “İnsanlar karmaşık formlar yerine tek tıkla sonuç görmek istiyor.”
Side project çöplüğünüzü temizlemekten korkmayın. O çöplük aslında sizin tecrübe kütüphanenizdir. Sadece tozlu rafları boşaltmanız gerekiyor ki yeni kitaplara yer açılsın. Ben her 6 ayda bir “Project Audit” (Proje Denetimi) yapıyorum. Eğer bir proje benim uykumdan, cebimden veya asıl işimden çalıyorsa, onunla vedalaşıyorum.
Sonuçta, 20 yıldır bu sektördeyim ve gördüğüm en başarılı insanlar, neyi yapacaklarını bilenlerden ziyade, neyi yapmaktan vazgeçeceklerini bilenlerdi. Sunucunuzdaki o atıl docker-compose.yml dosyasına bir bakın; belki de bugün onun son günüdür.
Bir sonraki yazıda, bu temizlikten sonra kazandığımız kaynaklarla nasıl daha efektif “production-ready” sistemler kurduğumuzu anlatacağım.