10.000 Notluk Bir Kasayı Nasıl Temizlersin? PKM Refactoring Rehberi

Binlerce not biriktiğinde ilk refleks şudur:

“Hafta sonu oturup hepsini düzenleyeceğim.”

Bu plan genellikle iki nedenle başarısız olur:

1. kapsam çok büyüktür,
2. temizlik sırasında yeni sistem de henüz doğrulanmamıştır.

Obsidian topluluğunda 1.000, 10.000 ve 12.000+ notluk kasalarla ilgili aynı problem tekrar tekrar görülüyor: farklı dönemlerden klasörler, etiketler, importlar, yarım şablonlar ve kullanılmayan eklentiler üst üste biniyor. Bunlar topluluk deneyimidir, performans için evrensel eşik değildir. 10.000 sayısı burada “büyük ve heterojen kasa”yı temsil ediyor.

0. Önce geri dönüş yolu oluştur

Refactor başlamadan:

• kasanın tam kopyasını al,
• mümkünse sürümleme kullan,
• medya dosyalarını dahil et,
• sync ile backup'ı karıştırma.

Refactoring veri kaybı riski taşıyan işlemdir. Geri alma yolu yoksa başlama.

1. Kasayı ölç, hemen taşımaya başlama

İlk envanter:

• toplam Markdown dosyası,
• ek dosyaları,
• en büyük klasörler,
• kullanılmayan plugin'ler,
• orphan notlar,
• boş/çok kısa notlar,
• tekrarlanan dosya adları,
• eski import klasörleri.

Ama amaç her metriği optimize etmek değildir. Problem nerede yoğunlaşıyor onu bulmaktır.

2. Yeni sistemi yalnız aktif iş üzerinde dene

Yeni klasör, metadata veya naming standardını 10.000 nota uygulama.

Bir aktif proje seç ve 20–50 notta dene.

İki hafta sonra şu sorulara cevap ver:

• daha hızlı yakalıyor musun,
• aradığını daha hızlı buluyor musun,
• not nereye gidecek sorusu azaldı mı,
• sistemi bakım yapmadan kullanabiliyor musun?

Cevap hayırsa tüm kasa göçünden önce sistemi değiştir.

3. Eski dünyayı tarihli arşive taşı

En güvenli desenlerden biri:

**Archive-2026-10-05/**

Eski yapıyı olduğu gibi burada tut.

Bu hamlenin avantajı:

• geçmiş kaybolmaz,
• yeni sistem temiz başlar,
• eski notları tek tek sınıflandırma zorunluluğu kalkar.

Topluluk tartışmalarında sık verilen pratik tavsiye de budur: arşivi olduğu gibi tut, ihtiyaç oldukça değerli notları yeni sisteme taşı.

4. Demand-driven migration kullan

Bir eski nota yeniden ihtiyaç duyduğunda:

1. aç,
2. hâlâ değerli mi kontrol et,
3. gerekirse güncelle,
4. yeni naming/metadata standardına getir,
5. yeni sisteme taşı,
6. eski kaydı silmek yerine bir süre arşivde bırak.

Böylece migration önceliğini geçmişteki not sayısı değil, bugünkü kullanım belirler.

5. Her kısa not çöp değildir

“100 karakterden kısa = sil” gibi otomasyonlar tehlikelidir.

Kısa bir not:

• önemli bir karar,
• kaynak referansı,
• tek cümlelik güçlü iddia

olabilir.

Temizlikte içerik anlamını sadece dosya boyuyla ölçme.

Daha iyi sinyaller:

• uzun süredir hiç açılmamış,
• hiçbir linki yok,
• kaynak belirsiz,
• aynı içeriğin daha güncel kopyası var,
• aktif sistemde hiçbir role sahip değil.

6. Plugin ve medya borcunu ayrı ele al

Kasa yavaşsa sorun not sayısı olmayabilir.

• büyük görseller,
• PDF arşivi,
• indeksleme,
• ağır plugin'ler,
• bozuk dosya adları

performansı etkileyebilir.

İçerik refactor'u ile performans refactor'unu aynı operasyon sanma. Önce hangi katmanın problem çıkardığını ölç.

7. Başarı metriği “temiz graph” değildir

Refactor bittikten sonra şunları ölç:

• yeni not yakalama süresi,
• bilinen notu bulma süresi,
• haftalık bakım süresi,
• aktif orphan sayısı,
• “nereye koyacağım?” kararlarının sıklığı.

Kasada 8.000 eski arşiv notu durabilir ve sistem yine de sağlıklı olabilir.

[[Not iflasının]] çözümü geçmişteki her şeyi mükemmel hale getirmek değil, yeni borç üretmeyen bir çalışma kuralı kurmaktır.

Büyük PKM kasası müze değildir. Refactoring'in amacı bütün eserleri yeniden etiketlemek değil, **aktif çalışma yolunu yeniden açmaktır**.