``

Normalizasyon neden gereklidir?

Normalizasyonun merkezinde fonksiyonel bağımlılık bulunur. Bir $X$ niteliği, $Y$ niteliğini tekil biçimde belirliyorsa bu ilişki $X \rightarrow Y$ şeklinde gösterilir. Örneğin MusteriID, müşterinin adını belirliyorsa:

Aynı müşteri adı her sipariş satırında saklanırsa gereksiz tekrar oluşur. Basit bir tekrar oranı şöyle düşünülebilir:

Bu oran büyüdükçe depolama maliyeti ve tutarsızlık ihtimali artar. Kötü tasarlanmış tablolar üç temel anomali üretir:

Birinci Normal Form: 1NF

Bir tablo 1NF düzeyindeyse her hücre atomik, yani bölünemez tek bir değer taşır. Tek hücrede Klavye, Fare, Monitör gibi bir ürün listesi bulunmamalıdır. Ayrıca satırlar birincil anahtarla ayırt edilmelidir.

CREATE TABLE SiparisKalemi (
    SiparisID INT,
    UrunID INT,
    Adet INT NOT NULL,
    PRIMARY KEY (SiparisID, UrunID)
);

Bu yapı her sipariş-ürün eşleşmesini ayrı satırda tutarak sorgulamayı ve doğrulamayı kolaylaştırır.

İkinci Normal Form: 2NF

2NF için tablo önce 1NF olmalı ve anahtar olmayan her sütun, bileşik anahtarın tamamına bağımlı olmalıdır. Yukarıdaki tabloda anahtar (SiparisID, UrunID) ikilisidir. Eğer UrunAdi eklenirse yalnızca UrunID değerine bağlı olur:

Bu, kısmi bağımlılıktır. Çözüm ürün bilgisini ayırmaktır:

CREATE TABLE Urun (
    UrunID INT PRIMARY KEY,
    UrunAdi VARCHAR(100) NOT NULL,
    BirimFiyat DECIMAL(10, 2) NOT NULL
);

Böylece ürün adı bir kez saklanır; sipariş kalemleri ürüne yabancı anahtarla bağlanır. Tek sütunlu anahtara sahip 1NF tablolar ise kısmi bağımlılık barındıramadığından genellikle doğrudan 2NF koşulunu karşılar.

Üçüncü Normal Form: 3NF

3NF, tabloyu 2NF’ye taşıdıktan sonra geçişli bağımlılıkları kaldırır. Anahtar olmayan bir sütun başka bir anahtar olmayan sütunu belirlememelidir. Şu ilişkiyi düşünelim:

SehirAdi, müşteri anahtarına doğrudan değil SehirID üzerinden bağlıdır. Şehir adı müşteri tablosunda tutulursa binlerce kez tekrarlanabilir. Ayrı bir şehir tablosu daha güvenlidir:

CREATE TABLE Sehir (
    SehirID INT PRIMARY KEY,
    SehirAdi VARCHAR(80) UNIQUE NOT NULL
);

CREATE TABLE Musteri (
    MusteriID INT PRIMARY KEY,
    MusteriAdi VARCHAR(120) NOT NULL,
    SehirID INT REFERENCES Sehir(SehirID)
);

Formların kısa karşılaştırması

Normalizasyon depolamayı ve bütünlüğü iyileştirir; ancak çok sayıda tablo, raporlama sorgularında daha fazla JOIN gerektirebilir. Bu nedenle işlem ağırlıklı sistemlerde 3NF güçlü bir başlangıç noktasıyken, analitik sistemlerde performans amacıyla kontrollü denormalizasyon uygulanabilir. Altın kural şudur: Önce doğru modeli kur, ardından ölçüm yap ve yalnızca gerçek bir darboğaz varsa bilinçli tekrar ekle.

``

Yalnızlık ile yalnız olmak aynı şey değil

Yalnızlık, çevredeki insan sayısından çok, arzulanan ve deneyimlenen sosyal bağ arasındaki farktır. Basitleştirilmiş bir modelle bunu şöyle gösterebiliriz:

Burada $L$ hissedilen yalnızlığı, $B_a$ arzulanan bağ düzeyini, $B_d$ ise deneyimlenen bağ düzeyini temsil eder. Bir kişi kalabalık içinde bile anlaşılmadığını düşünüyorsa $B_d$ düşük kalabilir. Chatbot’lar tam bu noktada ilgi gösteren, tutarlı ve erişilebilir bir etkileşim sağlayarak deneyimlenen bağ hissini geçici olarak yükseltebilir.

Fakat bu formül önemli bir ayrıntıyı saklar: Her bağ aynı değildir. Bir yapay zekâ, empatiyi dilsel olarak simüle eder; duyguyu biyolojik ve öznel anlamda yaşadığı varsayılamaz. “Seni anlıyorum” cümlesi kullanıcıda gerçek bir rahatlama yaratabilir, ancak bu rahatlama karşılıklı insan deneyimiyle aynı kaynaktan gelmez.

Dijital arkadaşlık ve insan ilişkisi

Tablodaki farklar, chatbot’ların değersiz olduğunu değil, farklı bir ilişki türü sunduğunu gösterir. Dijital sohbet; prova alanı, günlük tutma aracı veya zor bir günün geçici desteği olabilir. Sorun, aracın bütün sosyal yaşamın yerine geçmeye başlamasıdır.

Rahatlatıcı döngü ne zaman kapanır?

Kullanıcı chatbot’la konuştukça kısa vadeli rahatlama yaşayabilir. Bu rahatlama dış dünyaya katılımı destekliyorsa olumlu bir geri bildirim oluşur. Tersine, insanlarla iletişim kurma isteğini azaltıyorsa izolasyon büyüyebilir:

Bu örnek modelde $I$ izolasyonu, $C$ kaçınma amacıyla kullanılan chatbot süresini, $S$ sağlıklı sosyal teması; $k$ ve $h$ ise kişiye göre değişen etkileri belirtir. Denklem klinik ölçüm değildir, ilişkinin yönünü düşünmek için kullanılan kavramsal bir araçtır.

Aşağıdaki Python örneği bu basit dinamiği görünür kılar:

isolation = 5.0
avoidance_effect = 0.12
social_effect = 0.35

weekly_data = [
    {"chatbot_avoidance": 4, "social_contact": 1},
    {"chatbot_avoidance": 3, "social_contact": 2},
    {"chatbot_avoidance": 2, "social_contact": 3},
]

for week, data in enumerate(weekly_data, start=1):
    isolation += avoidance_effect * data["chatbot_avoidance"]
    isolation -= social_effect * data["social_contact"]
    isolation = max(0, isolation)
    print(f"{week}. hafta: {isolation:.2f}")

Kod, chatbot kullanımını otomatik olarak zararlı saymaz; özellikle kaçınma amacıyla kullanılan süreyi ayrı değişken olarak ele alır. Sosyal temas arttıkça modeldeki izolasyon puanı düşer. Gerçek hayatta kişilik, kültür, ekonomik koşullar ve ruh sağlığı gibi çok daha fazla değişken bulunur.

Köprü mü, varış noktası mı?

Sağlıklı yaklaşım, chatbot’u insanlara açılan bir köprü olarak kullanmaktır: zor bir konuşmayı prova etmek, bir arkadaşınıza yazacağınız mesajı düzenlemek veya sosyal hedefler belirlemek buna örnektir. Sistemlerin de bağımlılığı teşvik etmeyen dil kullanması, “yalnızca bana ihtiyacın var” benzeri ifadelerden kaçınması ve kriz durumlarında profesyonel kaynaklara yönlendirmesi gerekir.

Dijital sohbet gerçek bir psikolojik etki yaratabilir; fakat karşılıklı sorumluluk, ortak anılar ve bedensel varlık içeren insan bağının tam karşılığı değildir. En iyi senaryoda yapay arkadaşlık yalnızlığın üzerine kapatılan bir kapı değil, dışarıya açılan güvenli bir pencere olur.

Kaynak Kod Bir Sözleşmedir

C, C++, Rust veya Java gibi dillerde kaynak kod çoğunlukla işlemcinin doğrudan uygulayacağı talimatlar listesi değildir. Dil standardı tarafından tanımlanan bir soyut makineye verilmiş tariftir. Compiler bu tarifi ara temsillere dönüştürür; sabitleri hesaplar, gereksiz işlemleri siler, döngüleri açar ve komutların sırasını değiştirebilir.

Bunu mümkün kılan temel yaklaşım as-if kuralıdır: Dışarıdan gözlemlenebilen davranış değişmiyorsa dönüşüm serbesttir. Basitleştirilmiş biçimiyle compiler şu hedefi arar:

Buradaki eşitlik, iki programın aynı komutları çalıştırmasını değil, tanımlı girdiler için aynı gözlemlenebilir sonucu üretmesini ifade eder. Aradaki yöntem tamamen farklı olabilir.

Bir Döngü Nereye Kaybolur?

Aşağıdaki C fonksiyonu, ilk n doğal sayının toplamını döngüyle hesaplıyor:

unsigned sum(unsigned n) {
    unsigned result = 0;

    for (unsigned i = 0; i < n; ++i) {
        result += i;
    }

    return result;
}

Optimize edilmemiş çıktıda toplama ve karşılaştırma komutlarını görmek mümkündür. Güçlü optimizasyonda compiler, döngünün matematiksel anlamını keşfedip onu şu ifadeye yaklaştırabilir:

Böylece $O(n)$ adımlık görünen iş, birkaç makine komutuna dönüşebilir. Kaynak koddaki döngü gerçektir; fakat çalışma zamanında var olmak zorunda değildir. Bu durum hata değil, sözleşmenin başarıyla uygulanmasıdır.

Güvenin Kırıldığı Yer: Tanımsız Davranış

Soyutlama katmanına duyulan güven, dil kurallarını bildiğimiz varsayımına dayanır. Özellikle C ve C++ dünyasındaki tanımsız davranış, compiler’a beklenmedik çıkarımlar yapma fırsatı verir:

int greater_after_increment(int x) {
    return x + 1 > x;
}

Matematikte bu ifade her zaman doğrudur. Ancak sabit genişlikte işaretli tamsayı taşabilir. C standardında signed overflow tanımsız olduğu için compiler, tanımlı bir programda taşma gerçekleşmeyeceğini varsayıp fonksiyonu doğrudan 1 döndürecek şekilde optimize edebilir.

Soyutlama Güveni Nasıl Şekillendirir?

Yüksek seviyeli diller bizi register tahsisinden ve komut zamanlamasından kurtarır. Bu özgürlük üretkenliği artırırken kontrol hissini azaltabilir. Debug derlemesinde çalışan, release derlemesinde bozulan kod genellikle compiler’ın “fazla akıllı” olmasından değil; programın gizli bir varsayımının optimizasyonla görünür hâle gelmesinden kaynaklanır.

Sağlıklı güven, compiler’ın hiçbir şeyi değiştirmeyeceğine inanmak değildir. Dil standardı, bellek modeli ve gözlemlenebilir davranış sınırlarını anlayarak compiler’ın hangi değişiklikleri yapabileceğini bilmektir. Assembly çıktısını incelemek, sanitizers kullanmak ve farklı optimizasyon seviyelerinde test yapmak bu zihinsel modeli güçlendirir.

Sonuçta compiler görünmez bir eldir; fakat mistik değildir. Kaynak kod niyet, dil standardı sözleşme, makine kodu ise pazarlık sonunda ortaya çıkan üründür. İyi programcı yalnızca kod yazmaz; hangi soyutlama katmanına neden güvendiğini de bilir.

``

Silmek neden her zaman yok etmek değildir?

Bir dosya, depolama aygıtında veri blokları ve bu blokların konumunu gösteren dosya sistemi kayıtlarından oluşur. Normal silme işleminde işletim sistemi genellikle blokları hemen temizlemek yerine ilgili alanı “yeniden kullanılabilir” olarak işaretler. Yeni veri yazılana kadar eski bitler yerinde kalabilir.

Basitleştirilmiş biçimde veri kalıcılığını şöyle düşünebiliriz:

Burada $P(B)$, veri bloklarının henüz üzerine yazılmamış olma olasılığını; $P(E)$ ise bu blokların doğru biçimde eşleştirilerek okunabilme olasılığını temsil eder. İki değer de sıfır değilse veri kurtarma ihtimali vardır.

İnsan hafızası ve dijital hafıza

İnsan unutması pasif bir veri kaybı değildir. Anılar zamanla yeniden yorumlanır, duygularla biçimlenir ve her hatırlamada bir ölçüde yeniden yazılır. Dijital sistemlerdeyse bir kopya, bağlamını kaybetse bile bit düzeyinde aynı kalabilir.

Bu fark, “hafıza” sözcüğünün bilgisayarlarda biraz yanıltıcı olduğunu gösterir. İnsan hafızası yaşayan bir anlatıdır; dijital hafıza ise çoğaltılabilen bir izdir.

Üzerine yazmak çözüm mü?

Manyetik disklerde dosya alanını rastgele baytlarla doldurmak eski veriyi erişilemez hâle getirebilir. Aşağıdaki Python örneği, bir dosyanın mevcut içeriği üzerine rastgele veri yazar ve ardından dosyayı kaldırır:

import os
from pathlib import Path

def overwrite_and_delete(path):
    target = Path(path)
    size = target.stat().st_size

    with target.open('r+b') as file:
        file.write(os.urandom(size))
        file.flush()
        os.fsync(file.fileno())

    target.unlink()

Kod, dosya boyutu kadar rastgele bayt üretir, bunları diske göndermeye çalışır ve son olarak dizin kaydını siler. Ancak bu yöntem SSD’lerde garanti sunmaz. Aşınma dengeleme mekanizması, yeni veriyi aynı fiziksel hücreler yerine başka hücrelere yazabilir. TRIM komutu da temizliği denetleyiciye bırakır. Bu nedenle modern aygıtlarda tam disk şifreleme ve şifreleme anahtarının güvenli biçimde yok edilmesi daha güvenilir bir yaklaşımdır.

Bulut çağında unutmanın paradoksu

Yerel diski temizlemek yalnızca bir kopyayı etkiler. Bulut yedekleri, e-posta ekleri, mesajlaşma uygulamaları, önbellekler, günlük kayıtları ve başka kullanıcıların cihazları verinin çoğalmış izlerini taşıyabilir. Kopya sayısı $n$ arttıkça, tüm kopyaların silinme olasılığı kabaca şöyle ifade edilebilir:

Her kopyanın başarıyla silinme olasılığı $p$ ise, $n$ büyüdükçe tam unutma zorlaşır. Dijital kalıcılık yalnızca donanımsal değil, aynı zamanda ağsal ve toplumsal bir problemdir.

Unutulma hakkı neden önemlidir?

İnsan, geçmişinden uzaklaşarak değişebilme hakkına sahiptir. Fakat arama motorları ve arşivler geçmişi sürekli bugüne çağırdığında kişi, eski hâlinin dijital gölgesine dönüşebilir. Bu yüzden unutulma hakkı sadece gizlilik değil, kimliğin zaman içinde yeniden kurulabilmesi meselesidir.

Sonuçta dijital dünyada silmek tek bir düğmeye basmak değil; bağlantıları, kopyaları, anahtarları ve fiziksel izleri yönetmektir. Bilgisayarlar kendiliğinden unutmaz. Belki de asıl soru, verinin silinip silinmediği değil, makinelerimize merhametli bir unutma yeteneğini nasıl öğreteceğimizdir.

Kod, yalnızca kod değildir

Bir geliştirici yazdığı koda zamanını, bilgisini ve problem çözme tarzını yatırır. Özellikle zor bir görev günlerce uğraştırmışsa ortaya çıkan çözüm psikolojik olarak “benim ürünüm” değil, “benden bir parça” gibi algılanabilir. Bu duruma psikolojik sahiplenme denir.

Beyin eleştiriyi değerlendirirken kabaca iki sinyali karşılaştırır:

Kodumuzla ne kadar güçlü özdeşleşirsek küçük bir yorumun yarattığı tehdit de o kadar büyür. Böylece “Bu değişken adı belirsiz” gibi sınırlı bir tespit, zihinsel bir kestirmeyle “İsimlendirme konusunda kötüyüm” sonucuna ulaşabilir.

İki sütun arasındaki fark teknik değil, bilişseldir. Solda değiştirilebilir bir çıktı; sağda ise sabit bir kimlik yargısı vardır.

Beyin neden savunmaya geçiyor?

Eleştiri, sosyal statümüzün veya gruptaki yerimizin tehdit edildiği hissini yaratabilir. Beyin bu durumda geri bildirimi öğrenme fırsatı olarak değil, saldırı olarak işlemeye başlar. Doğrulama yanlılığı da devreye girer: Yorumdaki yararlı kısmı aramak yerine eleştirmenin haksız olduğunu kanıtlayan ayrıntıları seçeriz.

Bu tepkiyi basitçe şöyle modelleyebiliriz:

Bu bilimsel bir ölçüm formülü değildir; ancak önemli bir ilişkiyi görünür kılar: Savunmacılık yükseldikçe geri bildirimden yararlanmak zorlaşır. Amaç egoyu tamamen yok etmek değil, merakı savunma refleksinden daha güçlü hâle getirmektir.

Yorum dili çatışmayı nasıl değiştirir?

Kod incelemesinde yalnızca içeriğin doğruluğu değil, sunuluş biçimi de önemlidir. Aşağıdaki yorum teknik olarak bir soruna işaret etse bile kişiyi hedef alır:

Bunu gereksiz yere karmaşık yazmışsın. Daha basit düşünmelisin.

Aynı gözlem, ortak hedefe ve gözlemlenebilir sonuca bağlanabilir:

Bu fonksiyon üç farklı sorumluluk taşıyor gibi görünüyor.
Test edilebilirliği artırmak için doğrulama ve kayıt işlemlerini
ayrı fonksiyonlara bölmeyi değerlendirebilir miyiz?

İkinci örnek sorunu, gerekçeyi ve olası yönü açıklar. Emir vermek yerine tartışma alanı oluşturur. İyi bir inceleme yorumu çoğunlukla şu yapıyı izler:

Gözlem → Olası etki → Öneri veya soru

Eleştiriyi kişisel almamak için pratikler

1. Kişi ile çıktıyı ayırın. “Kodumda hata var” cümlesi, “Ben kötü bir geliştiriciyim” anlamına gelmez.
2. Anında cevap vermeyin. Duygusal yükselme hissediyorsanız kısa bir mola verin; ilk tepki çoğu zaman en savunmacı olandır.
3. Niyeti tahmin etmek yerine açıklama isteyin. “Buradaki temel risk performans mı, bakım maliyeti mi?” sorusu tartışmayı somutlaştırır.
4. Haklı çıkmayı değil, ürünü iyileştirmeyi hedefleyin. Kod incelemesi bir düello değil, dağıtımdan önce yapılan takım çalışmasıdır.
5. Yorumları önem derecesiyle etiketleyin. blocker, suggestion veya nit gibi etiketler her yorumun zorunlu değişiklik sanılmasını önler.

Sağlıklı ekip kültüründe geri bildirim, geliştiricinin değerini ölçen bir sınav değildir. Kod geçicidir; bugün savunduğumuz çözümü yarın kendimiz yeniden yazabiliriz. Profesyonellik hiç rahatsız olmamak değil, rahatsızlığı fark edip onu meraka çevirebilmektir. Sonuçta en iyi pull request, egonun kazandığı değil, ekibin birlikte daha iyi bir çözüm ürettiği pull request’tir.

``

Legacy kod neden böyle görünür?

Bugünün standartlarıyla geçmişi değerlendirmek kolaydır. Ancak bir kararın kalitesi yalnızca ortaya çıkan kodla değil, karar verildiği anda mevcut olan bilgilerle ölçülmelidir. Bunu basitçe şöyle düşünebiliriz:

Bugün bildiğimiz güvenlik açığı, performans sorunu veya tasarım deseni o gün bilinmiyor olabilir. Ekip küçük, teslim tarihi yakın, test altyapısı yetersiz ya da kullanılan framework henüz olgunlaşmamış olabilir. “Neden bunu düzgün yapmamışlar?” sorusu bu değişkenleri görmezden gelir.

Kod arkeolojisi yapmak

Legacy sistemde çalışmak biraz arkeolojiye benzer. Kod görünen eserdir; commit mesajları, hata kayıtları, eski dokümanlar ve ekip üyelerinin anıları ise kazı alanındaki ipuçlarıdır. Önce modülün ne yaptığını değil, neden var olduğunu öğrenmeye çalışın.

Örneğin aşağıdaki koşul gereksiz bir tekrar gibi görünebilir:

function calculatePrice(order) {
  // Eski mobil istemciler indirim alanını göndermiyor.
  const discount = order.discount == null ? 0 : order.discount;

  if (order.clientVersion && order.clientVersion < 3) {
    return Math.max(0, order.total - discount);
  }

  return applyModernPricing(order, discount);
}

Buradaki sürüm kontrolünü hemen silmek kodu sadeleştirir; fakat eski istemcilerin fiyat hesaplamasını bozabilir. Yorum, davranışın tarihsel nedenini kısmen açıklıyor. Daha iyi yaklaşım; kullanım metriklerini incelemek, eski istemcilerin hâlâ aktif olup olmadığını doğrulamak ve kaldırma kararını testlerle güvenceye almaktır.

Empati, kötü kodu korumak değildir

Empatik yaklaşım “Hiçbir şeye dokunmayalım” anlamına gelmez. Tam tersine, güvenli değişiklik yapabilmek için sistemi ciddiye almaktır. Kodu yazan kişiyi yargılamamakla teknik sorunları açıkça adlandırmak aynı anda mümkündür.

Sağlıklı bir iyileştirme süreci şu sırayı izleyebilir:

1. Mevcut davranışı karakterizasyon testleriyle kaydet.
2. Kodun çağrıldığı yerleri ve dış bağımlılıkları bul.
3. Küçük, geri alınabilir değişiklikler yap.
4. Gözlemlenebilirlik ekleyerek sonucu ölç.
5. Öğrenilen tarihsel bilgiyi dokümante et.

Risk kabaca değişikliğin büyüklüğü ve belirsizlikle artar:

Bu yüzden dev bir “temizlik” pull request’i yerine küçük adımlar genellikle daha güvenlidir. Önce test eklemek, ardından isimleri düzeltmek ve son olarak sorumlulukları ayırmak hem incelemeyi hem geri dönüşü kolaylaştırır.

Dilden kültüre uzanan etki

Kod incelemesinde kullanılan dil ekip kültürünü belirler. “Bu saçma olmuş” yerine “Bu kararın arkasındaki kısıtı biliyor muyuz?” demek yalnızca daha nazik değildir; daha fazla teknik bilgi üretir. İnsanlar yargılanmayacaklarını bildiklerinde eski hataları, geçici çözümleri ve gizli riskleri daha rahat paylaşır.

Unutmayın: Bugünün modern mimarisi de yarının legacy sistemidir. Bize miras kalan kodu merakla okumak, gelecekte kendi kararlarımızın da bağlam içinde değerlendirilmesini istemektir. İyi mühendislik yalnızca temiz kod yazmak değil, kirli görünen kodun hangi fırtınadan çıktığını anlayabilmektir.

``

Dil, düşüncenin yalnızca ambalajı mı?

Sapir-Whorf hipoteziyle ilişkilendirilen dilsel görecelik, konuştuğumuz dilin dünyayı algılama ve kategorilere ayırma biçimimizi etkilediğini savunur. Kuramın güçlü yorumu dilin düşünceyi belirlediğini, daha ılımlı ve günümüzde daha fazla kabul gören yorumu ise bazı düşünme alışkanlıklarını yönlendirdiğini söyler.

Örneğin Türkçedeki “o” zamiri konuşulan kişinin cinsiyetini belirtmez. İngilizceye çeviri yapan bir model ise bağlama göre “he”, “she” veya “they” seçmek zorundadır. Kaynak dilin açık bırakabildiği bir özellik, hedef dilde karara dönüşür. Model yalnızca çeviri yapmaz; belirsizliği yorumlar.

Modeller “en doğruyu” nasıl seçiyor?

Modern çeviri sistemleri, bir hedef cümlenin kaynak cümle verildiğinde ne kadar olası olduğunu hesaplar. Basitleştirilmiş amaç şöyle yazılabilir:

Burada $x$ kaynak metin, $y$ hedef metindir. Sorun şudur: En olası çeviri, kültürel açıdan en sadık çeviri olmak zorunda değildir. Eğitim verilerinde sık görülen kalıplar yüksek olasılık kazanır; az temsil edilen lehçeler, yerel benzetmeler veya toplumsal nezaket biçimleri ise istatistiksel gürültü gibi değerlendirilebilir.

Kayıp yalnızca sözcük düzeyinde ölçülemez. Kavramsal olarak kültürel maliyeti şöyle düşünebiliriz:

$L_s$ anlamsal kaybı, $L_p$ pragmatik yani bağlamsal kaybı, $L_c$ kültürel çağrışım kaybını temsil eder. Geleneksel otomatik ölçütler çoğunlukla ilk bileşene odaklanırken diğer ikisini yakalamakta zorlanır.

Küçük bir belirsizlik deneyi

Aşağıdaki Python kodu, tek bir çeviri yerine adayların puanlarını incelemenin neden önemli olduğunu gösteren basitleştirilmiş bir örnektir:

adaylar = {
    "He said he would come.": 0.46,
    "She said she would come.": 0.41,
    "They said they would come.": 0.13
}

sirali = sorted(adaylar.items(), key=lambda x: x[1], reverse=True)

for ceviri, olasilik in sirali:
    print(f"{olasilik:.0%} — {ceviri}")

Kaynak cümle “O geleceğini söyledi” ise ilk iki aday arasındaki küçük fark, modelin gerçek bilgiye sahip olduğunu göstermez. Bu fark; eğitim verilerindeki meslek, isim veya toplumsal cinsiyet dağılımlarından kaynaklanabilir. Sistem kendinden emin bir cümle üretirken aslında kültürel bir tahminde bulunmaktadır.

Daha duyarlı çeviri mümkün mü?

Çözüm, makineleri terk etmek değil; başarı tanımını genişletmektir. Modeller bağlam sormalı, belirsizlikleri işaretlemeli ve birden fazla çeviri önermelidir. Değerlendirme ekiplerinde yerel konuşurlar, çevirmenler ve kültür araştırmacıları bulunmalıdır. Ayrıca “akıcı” görünen her çıktının sadık olmadığı unutulmamalıdır.

Makine çevirisi diller arasındaki mesafeyi olağanüstü biçimde azaltıyor. Yine de hızın bedeli, farklı düşünme biçimlerinin tek ve pürüzsüz bir ifadeye sıkıştırılması olabilir. İyi bir çeviri yalnızca “Bu cümle ne diyor?” sorusunu değil, “Bu dil dünyayı neden böyle söylüyor?” sorusunu da koruyabilmelidir.

``

Tablo yerine doküman düşünmek

İlişkisel modelde veriler satır, sütun ve tablolarla temsil edilir. MongoDB ise verileri collection adı verilen koleksiyonlarda, BSON biçimindeki dokümanlar olarak saklar. BSON; JSON yapısını tarih, ondalık sayı ve ikili veri gibi ek türlerle genişletir.

Örnek bir ürün dokümanı şöyle olabilir:

{
  "_id": "urun-42",
  "ad": "Mekanik Klavye",
  "fiyat": 2499.90,
  "stok": 18,
  "ozellikler": {
    "switch": "Brown",
    "baglanti": ["USB-C", "Bluetooth"]
  },
  "yorumlar": [
    {"kullanici": "Ada", "puan": 5}
  ]
}

Bu doküman, ürünün temel alanlarını, iç içe nesnelerini ve dizilerini birlikte taşır. Uygulama ürünü okuduğunda çoğu bilgiyi tek sorguyla elde edebilir.

Şemasız, kuralsız demek değildir

MongoDB için sıkça “şemasız” ifadesi kullanılır. Daha doğru tanım esnek şemalıdır. Aynı koleksiyondaki dokümanlar farklı alanlar taşıyabilir; ancak uygulama kodu, indeksler ve doğrulama kuralları yine ortak bir veri sözleşmesine ihtiyaç duyar. Aksi hâlde fiyat alanı bir dokümanda sayı, diğerinde metin olabilir ve raporlama sırasında sürpriz yumurtaya dönüşebilir.

Veri doğrulama kurallarıyla bu risk azaltılabilir:

db.createCollection("urunler", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["ad", "fiyat", "stok"],
      properties: {
        ad: { bsonType: "string" },
        fiyat: { bsonType: "double", minimum: 0 },
        stok: { bsonType: "int", minimum: 0 }
      }
    }
  }
})

Bu kod, zorunlu alanları ve kabul edilen veri türlerini belirleyerek esneklik ile güvenilirlik arasında denge kurar.

Gömme mi, referans mı?

Doküman modellemenin kritik kararı, ilişkili veriyi ana dokümana gömmek veya başka koleksiyona koyup referans vermektir. Birlikte okunan ve sınırlı büyüyen veriler gömülebilir. Sürekli büyüyen, bağımsız güncellenen ya da birçok doküman tarafından paylaşılan veriler referanslanmalıdır.

Basit bir karar ölçüsü şöyle düşünülebilir:

Gömme, okuma maliyetini azaltırken tekrarlanan verinin güncelleme maliyetini artırabilir. Referanslama ise tekrarı azaltır fakat ek sorgu veya $lookup gerektirebilir. Bu nedenle model, nesnelerden önce uygulamanın erişim desenlerine göre tasarlanmalıdır.

Sorgulama ve indeksleme

İç içe alanlar nokta gösterimiyle sorgulanabilir:

db.urunler.find({
  "ozellikler.baglanti": "Bluetooth",
  fiyat: { $lte: 3000 }
})

Sorgu Bluetooth destekleyen ve belirlenen fiyatın altındaki ürünleri getirir. Sık kullanılan alanlarda indeks oluşturmak performansı yükseltir:

db.urunler.createIndex({
  "ozellikler.baglanti": 1,
  fiyat: 1
})

İndeksler okumayı hızlandırır; ancak disk kullanımı ile yazma maliyetini artırır. Dolayısıyla “her alana indeks” yaklaşımı, veritabanına gereksiz ağırlık bağlamak gibidir.

Sonuç olarak MongoDB, değişken yapılı ve hızla gelişen uygulamalarda güçlü bir seçenektir. Başarılı bir doküman modeli; veri ilişkilerini, büyüme hızını, atomik güncelleme sınırlarını ve sorgu alışkanlıklarını birlikte değerlendirir. NoSQL, SQL’in rakibi değil; doğru problemde kullanılan farklı bir araçtır.

Eşzamanlılık ile paralellik aynı şey değildir

Eşzamanlılık, birden fazla işin ilerleyişinin aynı zaman aralığında yönetilmesidir. Paralellik ise bu işlerden birkaçının fiziksel olarak aynı anda yürütülmesidir. Tek çekirdekli bir işlemci görevler arasında hızla geçiş yaparak eşzamanlı olabilir; çok çekirdekli bir işlemciyse görevleri gerçekten paralel çalıştırabilir.

Bu ayrım önemlidir; fakat zihinsel bedelin ana kaynağı ikisinde de aynıdır: olası yürütme sıralarının çoğalması.

Olasılık ağacı neden hızla büyür?

İki iş parçacığının üçer atomik adımı olduğunu düşünelim. Her iş parçacığının kendi iç sırası korunurken adımlar farklı biçimlerde iç içe geçebilir. Olası sıralama sayısı kabaca kombinasyonla hesaplanır:

$a=3$ ve $b=3$ için $N=20$ olur. İş parçacığı ve adım sayısı arttıkça sayı patlar. Üstelik gerçek programlarda önbellek, işletim sistemi zamanlayıcısı, G/Ç gecikmesi ve bellek modeli de oyuna katılır. Programcı yalnızca “Kod ne yapıyor?” sorusunu değil, “Başka hangi sırayla yapabilir?” sorusunu da yanıtlamak zorundadır.

İnsan çalışma belleği sınırlıdır. Birkaç değişkenin değerini, kilitlerin durumunu ve iş parçacıklarının konumunu aynı anda zihinde tutmaya çalışmak bilişsel yükü artırır. Bu nedenle eşzamanlılık hataları çoğu zaman kodu yazarken değil, nadir bir zamanlama gerçekleştiğinde ortaya çıkar.

Klasik tuzak: yarış koşulu

Aşağıdaki Python örneğinde iki iş parçacığı aynı sayacı artırır:

import threading

counter = 0

def increment():
    global counter
    for _ in range(100_000):
        counter += 1  # Okuma, artırma ve yazma tek bir düşünsel adım değildir.

threads = [threading.Thread(target=increment) for _ in range(2)]
for thread in threads:
    thread.start()
for thread in threads:
    thread.join()

print(counter)

counter += 1 basit görünür; ancak kavramsal olarak değeri okuma, yeni değeri hesaplama ve geri yazma aşamalarından oluşur. İki iş parçacığı aynı eski değeri okuyabilir ve artışlardan biri kaybolabilir. Buna yarış koşulu denir: sonuç, işlemlerin zamanlamasına bağlıdır.

Bir kilit kritik bölgeyi koruyabilir:

lock = threading.Lock()

def safe_increment():
    global counter
    for _ in range(100_000):
        with lock:
            counter += 1  # Bu bölgeye aynı anda yalnızca bir iş parçacığı girer.

Kilidin bedeli yalnızca performans değildir. Programcı artık kilidin nerede alındığını, ne zaman bırakıldığını ve başka kilitlerle hangi sırada kullanıldığını da izlemelidir. Yanlış sıra, bu kez deadlock adlı “Herkes birbirini bekliyor” komedisine dönüşebilir.

Beyne uygun eşzamanlılık tasarlamak

En güvenli strateji, beynimizi daha fazla iş parçacığı düşünmeye zorlamak değil, düşünülmesi gereken durum sayısını azaltmaktır. Paylaşılan değişkenleri sınırlamak, saf fonksiyonlar kullanmak, görev sahipliğini açıkça belirtmek ve zaman aşımı tasarlamak kodu anlatılabilir hale getirir.

Sonuçta paralel programlama yalnızca işlemci çekirdeklerini yönetme sanatı değildir; olasılık uzayını insan zihninin taşıyabileceği boyuta indirme sanatıdır. İyi eşzamanlı kod, sadece hızlı çalışan değil, sabah kahvesinden önce bile hangi olayın kimi beklediği anlaşılabilen koddur.

Mizahın görünmeyen bağımlılıkları

Sosyolojide grup kimliği, insanların kendilerini bir topluluğun parçası olarak tanımlamasıyla oluşur. Ortak dil, ritüeller ve semboller bu kimliği güçlendirir. Yazılımcılar için kod incelemeleri, sürüm çıkışları, üretim hataları ve bitmeyen toplantılar birer mesleki ritüeldir. “Ön belleği temizledin mi?” sorusu ise bazen teknik öneriden çok kültürel selamlaşmaya dönüşür.

Programcı şakasının etkisini basitçe şöyle düşünebiliriz:

Burada $M$ mizahın etkisini, $B$ paylaşılan bilgiyi, $D$ ortak deneyimi ve $T$ doğru zamanlamayı temsil eder. Değişkenlerden biri sıfıra yaklaşırsa şaka da sessizce başarısız olur. Bir veritabanı esprisini düğünde anlatmak, doğru kodu yanlış ortamda çalıştırmaya benzer.

İç grup ve dış grup farkı

Mesleki mizah, “biz” ile “onlar” arasındaki sınırı görünür kılar. Şakayı anlayan kişi yalnızca teknik detayı çözmez; aynı zamanda “Ben de bunu yaşadım” mesajı verir.

Örneğin aşağıdaki kod, teknik olarak basit olsa da kültürel bir hikâye anlatır:

def production_ready(code):
    if code.works_on_my_machine:
        return 'Deploy edelim, ne olabilir ki?'
    return 'Bir toplantı daha planla'

Bu kod gerçek bir dağıtım sistemi değildir. Mizah, riskli özgüven ile kurumsal toplantı alışkanlığını aynı yerde buluşturur. Şakayı komik yapan if yapısı değil, üretim ortamında işlerin nadiren planlandığı kadar kolay ilerlemesidir.

Kültürel sermaye olarak şaka

Sosyolog Pierre Bourdieu’nün kültürel sermaye kavramı, belirli bir alanda değer gören bilgi ve davranışları açıklar. Programcı topluluklarında eski teknolojileri bilmek, meşhur hata mesajlarını tanımak veya bir regex şakasını hızla çözmek sembolik statü sağlayabilir. Şakaya erken gülen kişi, adeta görünmez bir teknik rozet takar.

Fakat bu mekanizma masum değildir. Aşırı içe kapalı mizah yeni başlayanları, farklı uzmanlıklardan çalışanları veya teknik olmayan ekip üyelerini dışlayabilir. “Bunu anlamıyorsan bizden değilsin” tavrı, ekip dayanışması yerine hiyerarşi üretir. Kapsayıcı mizah ise deneyimi paylaşır ama bilgi eksikliğini küçümsemez.

const ekipMizahi = (saka, baglam) =>
  baglam.herkesAnliyor ? saka : `${saka} — kısa açıklaması da burada`;

Bu örnek, şakayı yasaklamak yerine bağlam eklemeyi önerir. İyi ekipler içeriden şakalarını korurken yeni üyelerin kültürel bağımlılıkları kurmasına da yardım eder.

Sonuç: Kahkaha bir kimlik protokolüdür

Programcı mizahı; stres boşaltma, uzmanlık gösterme ve aidiyet kurma aracıdır. Ortak bir bug’a gülmek, “Bu kaosu birlikte tanıyoruz” demektir. Ancak en sağlıklı topluluklar mizahı güvenlik duvarına çevirmeyenlerdir. Şaka grubun kapısını kilitlemek yerine yeni gelenlere README sunabiliyorsa, hem komik hem de sürdürülebilirdir.