Merdiven Nasıl Kuruluyor

İşin ilginci, o merdiveni kuran kişi kötü bir geliştirici değildi. Eski dünyada bir kullanıcıyı, sonra avatarını çeken en masum akış bile ister istemez böyle görünüyordu:

func loadProfile(id: String,
                 completion: @escaping (Result<Profile, Error>) -> Void) {
    fetchUser(id) { result in
        switch result {
        case .success(let user):
            fetchAvatar(user.avatarURL) { avatarResult in
                switch avatarResult {
                case .success(let avatar):
                    completion(.success(Profile(user: user, avatar: avatar)))
                case .failure(let error):
                    completion(.failure(error))
                }
            }
        case .failure(let error):
            completion(.failure(error))
        }
    }
}

İki istek için yirmi satır. Asıl mantık üç kelime — kullanıcıyı al, avatarı al, birleştir — ama kodda görünmüyor bile. Her katman kendi hata yönetimini taşıyor ve completion'ı bir dalda çağırmayı unutursanız uygulama sessizce takılıyor; bunu size hiçbir derleyici söylemiyor.

await: Bekle, Ama Kilitleme

Aynı fonksiyonun async/await hâli şu:

func loadProfile(id: String) async throws -> Profile {
    let user = try await fetchUser(id)
    let avatar = try await fetchAvatar(user.avatarURL)
    return Profile(user: user, avatar: avatar)
}

await gördüğünüz yerde fonksiyon duraklıyor ama iş parçacığı kilitlenmiyor; sistem o sırada başka işleri yürütüyor. Hata yönetimi closure'lardan throws'a taşındı: Result açıp kapatmak yok, unutulan completion yok. Bir dal eksikse bunu çalışma zamanında değil, derleme anında öğreniyorsunuz.

Bağımsız İşleri Sıraya Dizmeyin

Yukarıdaki kodda avatar, kullanıcı verisine muhtaç; sıralı beklemek zorundayız. Ama birbirinden bağımsız üç isteği art arda await etmek düpedüz israf. async let üçünü aynı anda başlatır:

func loadDashboard(for id: String) async throws -> Dashboard {
    async let profile = fetchProfile(id)
    async let feed = fetchFeed(id)
    async let badges = fetchBadges(id)

    return try await Dashboard(profile: profile,
                               feed: feed,
                               badges: badges)
}

Toplam süre artık üç isteğin toplamı değil, en yavaşının süresi. O eski projede yalnızca bu değişiklik ana ekranın açılışını 1,8 saniyeden 700 milisaniyeye indirdi. Ölçmeden söyleseler inanmazdık.

Paylaşılan Duruma Gelince: Actor

Eşzamanlılığın gerçekten canımızı yakan kısmı yarış durumları (data race): iki görev aynı sözlüğe aynı anda yazmaya kalkınca bazen çöken, bazen sessizce yanlış veri üreten türden hatalar. Swift'in cevabı actor — içindeki duruma aynı anda tek görev erişebilir ve bunu derleyici garanti eder:

actor ImageCache {
    private var store: [URL: Image] = [:]

    func image(for url: URL) -> Image? {
        store[url]
    }

    func insert(_ image: Image, for url: URL) {
        store[url] = image
    }
}

// Erişim her zaman await ile:
let cache = ImageCache()
await cache.insert(avatar, for: url)
let hit = await cache.image(for: url)

Eskiden bu iş için DispatchQueue üzerine kilit kurar, herkesin doğru kullandığını umardık. Umut, bir eşzamanlılık stratejisi değildir.

async/await kodu kısaltmıyor; okunur yapıyor. Kazanç satır sayısında değil, altı ay sonra o dosyayı açan kişinin yüzünde.

O 'buraya girmeyin' yazan fonksiyon bugün otuz satır ve ekibe yeni katılan herkes ilk okuyuşta anlıyor. Callback merdivenini özleyen tek kişiye rastlamadık.

Sızıntı Nasıl Doğar

Ders kitabı örneği gibi görünen şu fonksiyona bakın:

void process() {
    Widget* w = new Widget();

    if (!w->init()) {
        return;            // sızıntı: delete'e hiç ulaşılmadı
    }

    w->run();
    delete w;
}

init() başarısız olursa delete çalışmaz, Widget bellekte öksüz kalır. run() bir istisna fırlatırsa yine aynı hikâye. Buradaki sorun dikkatsizlik değil; 'her çıkış yolunda temizlik yap' kuralını insana emanet etmek. İnsan unutur. Kod büyüdükçe daha çok unutur.

RAII: Temizliği Nesneye Emanet Edin

C++'ın cevabının adı kulağa bürokratik gelir — Resource Acquisition Is Initialization — ama fikir tek cümledir: kaynağı bir nesnenin ömrüne bağla. Nesne kapsamdan çıkarken yıkıcısı çalışır ve kaynağı o bırakır. Nasıl çıkıldığının önemi yoktur; normal akış, erken return, istisna... yıkıcı her koşulda çağrılır:

class FileHandle {
public:
    explicit FileHandle(const char* path)
        : file_(std::fopen(path, "r")) {}

    ~FileHandle() {
        if (file_) std::fclose(file_);
    }

    // İki nesne aynı dosyayı kapatmasın diye kopyalama kapalı.
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;

    std::FILE* get() const { return file_; }

private:
    std::FILE* file_;
};

Artık 'dosyayı kapatmayı hatırlamak' diye bir iş yok; FileHandle kapsamdan çıktığı an dosya kapanıyor. Standart kütüphanedeki std::lock_guard, std::vector, std::string — hepsi aynı desenin ürünü. Muhtemelen yıllardır RAII kullanıyorsunuz, adını koymadan.

Akıllı İşaretçiler: new/delete'siz Hayat

İşaretçiler için de aynı desenin hazır hâli var: unique_ptr tek sahiplik, shared_ptr paylaşılan sahiplik demek.

#include <memory>

auto w = std::make_unique<Widget>();
if (!w->init()) {
    return;               // sızıntı yok; w kendini temizler
}
w->run();

// Paylaşılan sahiplik: son sahip gidince nesne serbest kalır.
auto config = std::make_shared<Config>();
useConfig(config);

Baştaki process() fonksiyonunun bütün hata sınıfı — unutulan delete, çift delete, istisna yolunda sızıntı — tek satırlık değişiklikle yok oldu. Performans bedeli mi? unique_ptr için sıfır; derlenen kod çıplak işaretçiyle aynı.

Bir uyarı da borç bilelim: shared_ptr her derde deva değil. Referans sayacı atomik olduğu için küçük bir maliyeti var ve döngüsel referanslar — A B'yi tutar, B A'yı — sayacı asla sıfıra indirmez. Varsayılanınız unique_ptr olsun; gerçekten paylaşılan sahiplik varsa shared_ptr'a geçin, döngü riski olan kenarda weak_ptr kullanın.

Modern C++ kodunda çıplak new ve delete görüyorsanız, ya çok özel bir şey yapılıyordur ya da bir hata bekliyordur. Tecrübeyle sabit: çoğunlukla ikincisi.

Gece ikideki valgrind seansına dönersek: o sızıntıyı elle bulup kapatmıştık, çünkü kod tabanı akıllı işaretçilere hazır değildi. Ertesi ay 'yeni kod çıplak new yazamaz' kuralını koyduk. O günden beri sızıntı avına çıkmadık.

& Adres Verir, * Adrese Gider

int x = 42;
int *p = &x;          // p, x'in adresini tutuyor

printf("%d\n", *p);   // 42 — p'nin gösterdiği değer
*p = 7;               // x artık 7; p onu gösteriyor

&x, 'x nerede duruyor' sorusunun cevabı; *p ise 'p'nin gösterdiği yerde ne var'. İkisi birbirinin tersi. *p = 7 yazdığınızda x'i doğrudan değiştiriyorsunuz, çünkü ikisi aynı adrese bakıyor.

Bu fikrin ilk gerçek meyvesi, fonksiyonların dışarıdaki değişkenleri değiştirebilmesi. C'de her argüman kopyalanarak geçer; ama adresi geçerseniz fonksiyon asıl veriye ulaşır:

void swap(int *a, int *b) {
    int tmp = *a;
    *a = *b;
    *b = tmp;
}

int i = 1, j = 2;
swap(&i, &j);         // i == 2, j == 1

scanf'e neden &sayi yazdığınızı hiç merak ettiyseniz, cevap bu: fonksiyon okuduğu değeri sizin değişkeninize yazabilsin diye ona adresi veriyorsunuz.

Diziler: Göründüğünden Yakın Akraba

C'nin yeni başlayanı en çok şaşırtan gerçeği: dizi adı, çoğu bağlamda ilk elemanının adresine dönüşür. Buna 'decay' deniyor:

int nums[3] = {10, 20, 30};
int *p = nums;              // &nums[0] ile aynı

printf("%d\n", *(p + 2));   // 30
printf("%d\n", p[2]);       // 30 — birebir aynı şey

p[2] ile *(p + 2) aynı ifadenin iki yazımı; köşeli parantez yalnızca kısaltma. Gözden kaçan incelik şu: p + 2 iki bayt değil, iki int ileri gider. İşaretçi aritmetiği, eleman boyutunu sizin yerinize hesaba katar.

const: Derleyiciye Verilen Söz

İşaretçi alan her fonksiyon, veriyi değiştirme gücünü de alır. const, bu gücü iade etmenin yolu:

void printName(const char *name) {
    // *name = 'X';  -> derleme hatası
    printf("Merhaba, %s\n", name);
}

Küçücük bir anahtar kelime ama iki iş birden yapıyor: çağırana 'verine dokunmayacağım' garantisi veriyor, size de yanlışlıkla dokunursanız derleme hatası. Bedava sigorta; fonksiyon imzalarınızda cömert olun.

İşaretçilerin kötü şöhreti bence kötü öğretilmelerinden. Kutu ve ok çizmeden, adres kavramını oturtmadan söz dizimine dalınca semboller anlamsız bir büyüye dönüşüyor. Adres fikri bir kez oturduğundaysa diziler, dizeler, dinamik bellek, bağlı listeler — hepsi aynı temelin üzerine sırayla diziliyor. Korkulacak bir şey yok; burası C'nin kalbi.

Aynı Soru, İki Farklı Cevap

Alışık olduğumuz yazılımda aynı girdi aynı çıktıyı üretir. Dil modelinde üretmez — ve bununla savaşmak yerine mimariyi buna göre kurmak gerekir. İlk kural: modelin çıktısına asla çıplak güvenmeyin. Yapılandırılmış veri bekliyorsanız şemayla doğrulayın, uymuyorsa yeniden isteyin:

const Invoice = z.object({
  vendor: z.string(),
  total: z.number().positive(),
  currency: z.enum(["TRY", "USD", "EUR"]),
});

async function extractInvoice(text: string) {
  for (let attempt = 1; attempt <= 3; attempt++) {
    const raw = await model.complete(prompt(text));
    const parsed = Invoice.safeParse(tryJson(raw));
    if (parsed.success) return parsed.data;
  }
  throw new ExtractionFailed();
}

Üç denemede de şemaya oturmayan yanıt için doğru davranış, yanlış veriyi sessizce kabul etmek değil, kullanıcıya dürüst bir hata göstermek. 'Emin olamadım' diyebilen bir sistem, emin olmadan konuşan bir sistemden her zaman daha fazla güven toplar.

Bağlam, Modelden Kıymetlidir

Projelerde en sık duyduğumuz cümle: 'Daha güçlü model alsak düzelir mi?' Çoğu zaman hayır — çünkü yanıt kalitesinin asıl belirleyicisi modele ne gösterdiğiniz. RAG kurulumunda gerçek mühendislik arama katmanındadır: doğru belgeyi bulamayan sistem, hangi model olursa olsun uydurur. Elinde başka malzeme yok ki.

Bağlam penceresini doldurmak da çözüm değil. Alakasız on belge modelin dikkatini dağıtır, üstüne faturayı şişirir. Bizim ölçümlerimizde alakalı iki paragraf, 'ne olur ne olmaz' diye eklenmiş yirmi paragrafı istikrarlı biçimde geçti. Az ama isabetli bağlam kazanıyor.

Prompt Değişikliği Kör Uçuş Olmasın

Prompt'ta üç kelime değiştirdiniz; sistem şimdi daha mı iyi? Elinizde ölçüm yoksa dürüst cevap 'bilmiyorum'dur. Her kritik akış için gerçek kullanıcı sorularından derlenmiş bir değerlendirme seti tutuyoruz — girdiler ve beklenen davranışlar, sürüm kontrolünde sıradan bir dosya:

{
  "input": "Geçen ayki AWS faturasını kim onayladı?",
  "expect": {
    "must_cite_source": true,
    "must_not_contain": ["tahminimce", "muhtemelen"],
    "tool_called": "search_invoices"
  }
}

Prompt ya da model değiştiğinde set baştan koşuyor; skor düştüyse değişiklik ana dala giremiyor. Klasik yazılımdaki regresyon testinin buradaki karşılığı bu. Kurması yarım gün sürdü; karşılığında her dağıtım kumar olmaktan çıktı.

Token Faturası ve Üç Saniyelik Boşluk

Demoda kimse maliyete bakmaz; üretimde her istek gerçek paradır. En etkili çare kademeleme: sınıflandırma, kısa özet gibi işleri küçük bir modele verin, büyük modeli yalnızca gerçekten zor sorulara saklayın. Bu tek karar bizim faturayı yarıdan fazla düşürdü. Gecikme tarafında ise akış (streaming) pazarlıksız: ilk kelime 300 milisaniyede ekrana düşüyorsa kullanıcı toplam üç saniyeyi dert etmiyor. Boş ekrana bakılan üç saniye ise sonsuzluk.

Demo, mutlu senaryonun gösterisidir; ürün, mutsuz senaryoların toplamı. LLM işinde bu makas her zamankinden geniş.

Uçurumun öbür yakasına geçilmez değil. Şema doğrulaması, isabetli bağlam, değerlendirme seti ve maliyet disiplini — dördü bir arada, büyüleyici demoyu güvenilir ürüne çeviriyor. Sırayla ve acele etmeden.

LCP: Sayfa Ne Zaman 'Geldi'

Largest Contentful Paint, ekrandaki en büyük içeriğin — genelde kapak görselinin ya da başlığın — göründüğü an. O projede suçlu, geç keşfedilen kapak görseliydi: tarayıcı önce CSS'i indiriyor, görselin varlığını ondan sonra öğreniyordu. Çare, tarayıcıya baştan haber vermek:

<link
  rel="preload"
  as="image"
  href="/hero.avif"
  imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
/>

Bir de yazı tipi klasiği var: font inene kadar metni gizleyen siteler kullanıcıya uzun uzun boş ekran gösterir. font-display: swap önce sistem fontuyla metni basar, marka fontu gelince değiştirir:

@font-face {
  font-family: "Space Grotesk";
  src: url("/fonts/space-grotesk.woff2") format("woff2");
  font-display: swap;
}

Bu iki değişiklik ve görsellerin AVIF'e çevrilmesi, o sitede LCP'yi 4,1 saniyeden 1,9'a indirdi. Egzotik hiçbir şey yok; yalnızca tarayıcının işini kolaylaştırmak.

INP: Tıkladım, Neden Bir Şey Olmuyor

Interaction to Next Paint, etkileşimden ekrandaki ilk tepkiye kadar geçen süreyi ölçer. Baş düşman, ana iş parçacığını yüzlerce milisaniye kilitleyen JavaScript: tarayıcı tek uzun görevle meşgulken tıklamalar kuyruğa girer ve arayüz donmuş hisseder. Çare, işi bölmek:

async function processRows(rows) {
  for (const [i, row] of rows.entries()) {
    handle(row);
    if (i % 100 === 0) {
      // Her 100 satırda tarayıcıya nefes aldır:
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Kaba ama etkili: uzun döngü artık aralıklarla ana iş parçacığını bırakıyor, bekleyen tıklamalar işlenebiliyor. Daha şık araçlar da var — scheduler.yield(), Web Worker'lar — ama ilke hep aynı: ana iş parçacığı kullanıcınındır; siz orada misafirsiniz.

CLS: Tam Tıklayacaktım, Kaydı

Cumulative Layout Shift, yüklenme sırasında içeriğin ne kadar zıpladığını ölçer. Herkes yaşamıştır: okuduğunuz paragraf, üstte geç beliren bir banner yüzünden aşağı kaçar. Sebep neredeyse hep aynıdır — boyutu önceden bildirilmemiş görseller ve gömülü içerikler. Modern CSS'te çözüm iki satır:

img {
  aspect-ratio: 16 / 9; /* yer, görsel inmeden ayrılır */
  width: 100%;
  height: auto;
}

Tarayıcı en-boy oranını bildiği an görsele yerini baştan ayırır; içerik zıplamaz. Dinamik banner ve reklamlar için de ilke aynı: alanı önceden ayır, içeriği o alana yerleştir.

Laboratuvar testi sizin bilgisayarınızı ölçer; RUM, kullanıcınızın telefonunu. Karar verirken ikincisine bakın.

O projeden aklımızda kalan ders: performans tek seferlik bir bahar temizliği değil, bütçe gibi yönetilen bir şey. Her yeni özellik o bütçeden harcar. Ölçümü sürekli tutarsanız borç birikmeden görünür; bırakırsanız faiziyle geri döner.

Boolean Bataklığı

Klasik örnek, çünkü hâlâ her yerde: isLoading, isError, data diye üç ayrı alan. Üç alan size sekiz kombinasyon verir; anlamlısı üç tane. Hem yükleniyor hem hatalı bir durum mantıken yok — ama tip sisteminde var ve bir gün üretimde karşınıza çıkıyor. Durumu ayrık birleşimle (discriminated union) modelleyince saçma kombinasyonlar dilden düşer:

type State =
  | { status: "loading" }
  | { status: "error"; error: Error }
  | { status: "success"; data: User };

data'ya artık yalnızca success dalında erişilebiliyor. Yükleme sırasında veriyi okumaya çalışan kod derlenmiyor bile; o hata sınıfı üretime gitmeden, daha editörde ölüyor.

Bu desenin az bilinen ikramiyesi: switch ile birleşince derleyici eksik dalları da yakalıyor:

function render(state: State) {
  switch (state.status) {
    case "loading":
      return spinner();
    case "error":
      return alert(state.error);
    case "success":
      return table(state.data);
    default: {
      const eksik: never = state; // yeni durum eklenirse burada patlar
      return eksik;
    }
  }
}

Altı ay sonra biri State'e { status: "empty" } eklediğinde bu switch derleme hatası verir ve güncellenmesi gereken her yer kendini ihbar eder. Yapılacaklar listenizi derleyici yazar.

Her Şey string Olunca

Kullanıcı kimliği string, e-posta string, sipariş numarası string... Hepsi aynı tipse, sendEmail(user.id) yazdığınızda sizi kimse durdurmaz. Markalı tipler (branded types) bu karışıklığı derleme hatasına çevirir:

type UserId = string & { readonly __brand: "UserId" };
type Email = string & { readonly __brand: "Email" };

function sendEmail(to: Email) {
  /* ... */
}

sendEmail(user.id); // derleme hatası — id bir Email değil

Çalışma zamanında bunlar sıradan string; maliyet sıfır. Ama para tutarı, tarih, ölçü birimi gibi karışması pahalı değerlerde bu sıfır maliyetli çit gerçek kazaları önlüyor. Mars Climate Orbiter metrik-emperyal birim karışıklığına kurban gitmişti; iyi kurgulanmış bir tip sistemi o hatayı fırlatmadan önce yakalardı.

Sınırda Doğrula, İçeride Güven

Tipler yalnızca kendi kodunuzun içinde geçerlidir. API'den gelen JSON'a as User demek bir tespit değil, bir dilektir. Sınırda çalışma zamanı doğrulaması yapın; içeride tiplere gönül rahatlığıyla güvenin:

const User = z.object({
  id: z.string(),
  name: z.string(),
  age: z.number().int().min(0),
});

const user = User.parse(await res.json()); // uymuyorsa burada patlar

Böylece hata, verinin sisteme girdiği kapıda ve anlaşılır bir mesajla patlıyor — üç katman derinde 'undefined is not a function' olarak değil.

as bir umut ifadesidir; parse bir kanıt. Sınırda kanıt isteyin.

Tiplere tasarım aracı muamelesi yapmaya başlayınca ilginç bir şey oluyor: daha kod yazmadan, modeli kurarken tasarımdaki boşlukları görüyorsunuz. 'Bu durumda şu alan ne olacak?' sorusunu size derleyici sordurtuyor. Yazarken kötü hissettiren tip tanımı, çoğu zaman kötü bir tasarım kararının ilk belirtisidir.

Beş Dakikalık Test: Fareyi Bırakın

Sitenizin durumu hakkında en hızlı fikri şöyle edinirsiniz: fareyi bırakın, yalnızca Tab, Enter ve ok tuşlarıyla gezinin. Odağın nerede olduğunu görebiliyor musunuz? Her düğmeye ulaşabiliyor musunuz? Açılan menüden Escape ile çıkabiliyor musunuz? Bu testi geçemeyen arayüz yalnızca engelli kullanıcılar için değil, klavyeyle çalışmayı seven herkes için bozuktur.

Testin en sık yakaladığı hata da bellidir: div'den düğme yapmak.

<!-- Görünüşte düğme, işlevde hiçbir şey: -->
<div class="btn" onclick="save()">Kaydet</div>

<!-- Klavye, odak, Enter, ekran okuyucu — hepsi bedava: -->
<button type="button" onclick="save()">Kaydet</button>

İlki fareyle çalışır ve orada biter: Tab'la odaklanamaz, Enter'ı duymaz, ekran okuyucuya 'düğmeyim' demez. Bunların hepsini tabindex, role ve keydown ile elle geri eklemek mümkün — ama neden? Doğru HTML öğesi, yüz satır ARIA yamasının yapamadığını sıfır satırla yapar.

Yapı, Gözle Görmeyene Anlatılır

Ekran okuyucu kullanıcısı sayfayı gözle taramaz; başlıklar ve işaret noktaları (landmark) arasında sıçrayarak dinler. <nav>, <main>, <header> ve düzgün bir başlık hiyerarşisi bu yüzden 'temiz kod zevki' değil, gerçek bir gezinme aracıdır. Görsellerin alternatif metni de aynı işin parçası ve başlı başına bir zanaat: 'grafik' yazmak bilgi taşımaz; 'gelirin son çeyrekte yüzde 20 arttığını gösteren çizgi grafik' taşır. Kural basit: görseli tarif etmeyin, taşıdığı bilgiyi aktarın.

Renk Tek Başına Konuşamaz

Formda hatalı alanları yalnızca kırmızıyla işaretlediyseniz, renk körü bir kullanıcı için hiçbir şey işaretlememişsinizdir — ki bu her 12 erkekten biri demek, azımsanacak kitle değil. Renge daima ikinci bir kanal eşlik etmeli: ikon, metin ya da desen. Kontrast da pazarlık kabul etmez; tasarımda çok şık duran o açık gri metin, öğlen güneşindeki telefon ekranında yok olur.

Hareket konusu daha az bilinir ama bazı kullanıcılar için mesele konfor değil, sağlıktır: büyük paralaks ve geçiş animasyonları, vestibüler rahatsızlığı olanlarda gerçek fiziksel bulantı tetikleyebilir. Sistem genelinde 'hareketi azalt' demiş kullanıcıyı dinlemek tek medya sorgusu:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Altyazı sağır kullanıcılar için icat edildi; bugün metroda hepimiz videoları altyazıyla izliyoruz. Kısıt için tasarlanan şey herkes için netleşir.

O kullanıcı testinden beri ekipte kural şu: her yeni bileşen birleşmeden önce klavyeyle test edilir, her görsel alternatif metniyle gelir, her renk kontrastıyla seçilir. Kâğıt üstünde fazladan iş gibi duruyor; pratikte, sonradan düzeltmenin maliyetinin yanında baştan doğru yapmak neredeyse bedava.

Her Şeyi Derin İzlemeyin

Vue, varsayılan olarak bir nesnenin her seviyesini reaktif yapar. Grafik için gelen 5.000 noktalık dizinin her elemanına tek tek izleyici takmaksa yalnızca bellek yakar — o noktaları tek tek değiştirmiyorsunuz ki. Veriyi bütün olarak değiştiriyorsanız, yalnızca referansı izlemek yeter:

import { shallowRef } from "vue";

const points = shallowRef<Point[]>([]);

// Yeni veri geldiğinde komple değiştir — tek tetikleme:
async function refresh() {
  points.value = await fetchPoints();
}

Pratikteki kural şu: veriyi yerinde değiştirmiyor, yeniden atıyorsanız shallowRef kullanın. Bizim panelde en büyük tek kazanç buydu; bellek kullanımı gözle görülür düştü, büyük güncellemelerdeki takılma kayboldu.

Şişman computed, Tembel Zincir

İkinci suçlu, her şeyi tek başına hesaplayan dev bir computed'dı: filtrele, sırala, grupla, topla — hepsi bir arada. İçindeki herhangi bir bağımlılık kıpırdadığında koca zincir baştan çalışıyordu. Böldük:

// Önce: hepsi tek computed'da, her değişiklikte hepsi baştan.
// Sonra: her halka yalnızca kendi girdisi değişince çalışır.
const filtered = computed(() => rows.value.filter(matches(query.value)));
const sorted = computed(() => sortBy(filtered.value, sortKey.value));
const total = computed(() => sum(sorted.value, "amount"));

Sıralama anahtarı değiştiğinde artık filtreleme tekrarlanmıyor; yalnızca sorted ve sonrası hesaplanıyor. Küçük computed'lar hem daha hızlı hem daha okunur — dev olanın içinde ne döndüğünü zaten kimse bilmiyordu.

v-memo: Güçlü, Ama Keskin

Son dokunuş, tablo satırlarına v-memo. Bir satır, bağımlılıkları değişmediği sürece yeniden render edilmiyor:

<tr
  v-for="row in rows"
  :key="row.id"
  v-memo="[row.id === selectedId, row.updatedAt]"
>
  ...
</tr>

Seçim değiştiğinde 5.000 satırdan yalnızca ikisi — eski ve yeni seçili olan — yeniden çiziliyor. Ama dürüst olalım: v-memo keskin bir bıçak. Bağımlılık listesini eksik yazarsanız Vue'ya 'bu satırı güncelleme' demiş olursunuz ve arayüz sessizce bayatlar. Biz onu yalnızca ölçülmüş bir darboğazda kullanıyoruz; 'ne olur ne olmaz' diye asla.

Önce ölçün, sonra optimize edin — ama ölçtükten sonra da çekinmeyin. Tahminle yapılan optimizasyon, çözdüğünden çok sorun açar.

Sonuç: ilk boyama süresi yarıya indi, yazarkenki donmalar bitti, kod öncekinden daha okunur. Performans işinin tatmin edici yanı da bu — teşhis doğru konunca çözüm çoğu zaman birkaç satır.

Değerler Değil, Kararlar

Bir tasarım sisteminin asıl standartlaştırdığı şey renkler değil, kararlardır: buton kaç varyanta ihtiyaç duyar? Kart hangi durumda gölge alır? Hata rengi ne zaman kullanılır — ve daha önemlisi, ne zaman kullanılmaz? Bu sorulara cevap vermeden seçilen palet, güzel görünen bir renk koleksiyonundan ibarettir. Değerler kararların çıktısıdır, girdisi değil.

Üç Katman: Ham, Anlamsal, Bileşen

Token mimarimiz üç katmandan oluşuyor ve bileşenler asla ham değere bakmıyor, yalnızca anlamsal role:

// 1) Ham değerler — anlam yok, yalnızca sabitler:
@berry-500: #ff3d77;
@ink-900: #0a0a10;

// 2) Anlamsal roller — 'bu değer ne işe yarar':
@color-danger: @berry-500;
@surface-base: @ink-900;

// 3) Bileşen token'ları — belirli bir kullanım:
@button-danger-bg: @color-danger;

İlk bakışta gereksiz bir dolaylama gibi durur — ta ki ilk tema isteği gelene kadar. Koyu tema, markalı beyaz tema, yüksek kontrast: hepsi yalnızca ikinci katmanı değiştirerek, bileşen koduna tek satır dokunmadan çıkıyor. Bir bileşenin içine #ff3d77 yazdığınız an bu esnekliği kaybettiniz; o değer artık orada yaşıyor ve taşınmıyor.

Varyant Enflasyonuna Direnin

Bileşen tarafında ilke aynı: Button bileşeni 'birincil, ikincil, tehlike' sunar — 'mavi buton, kırmızı buton' değil. Tasarımcı 'bu eylem tehlikeli' der, geliştirici danger varyantını seçer; rengin ne olduğu sistemin iç meselesidir, sayfanın değil.

Varyant sayısını az tutmaksa bilinçli bir savaş. Her yeni varyant; test edilecek, belgelenecek, tutarlı tutulacak yeni bir yüzey demek. İlk sistemdeki 14 buton bize dersi verdi: 'belki lazım olur' diye eklenen her şey, sistemin en hızlı çürüyen köşesi oluyor.

Tek Sert Kural

Sistemi iki yıldır ayakta tutan kural tek cümle: tasarımda olmayan hiçbir değer koda giremez, kodda olmayan hiçbir bileşen tasarıma. İki taraf aynı token kaynağından besleniyor. Kural zaman zaman can sıkıyor — 'iki dakikalık iş, elle yazayım gitsin' cazibesi hiç bitmiyor — ama sistemleri öldüren de tam olarak o iki dakikalık işler. Özel durum CSS'i çürümenin ilk sinyalidir; bir tane girdi mi arkası gelir.

Tasarım sistemi bir proje değil, bir anlaşmadır. Proje biter; anlaşma, taraflar uyduğu sürece yaşar.

İkinci sistemimiz altı aydır tek satır özel durum CSS'i olmadan büyüyor. Yeni sayfa açmak artık CSS yazmak değil, hazır bileşenleri dizmek demek. Ve ilk sistemin enkazından öğrendiğimiz her şey bu ikincisinin temelinde duruyor. Belki de tasarım sistemi kurmanın gerçek ilk adımı budur: bir tanesini batırmak.

Yayı Yeniden İcat Etmeyin

iOS'un yay (spring) animasyonları on yılı aşkın ince ayarın ürünü. Süresi doğru ama eğrisi yanlış bir animasyon, kullanıcıda sebebini söyleyemediği bir 'bir şey yapay' hissi bırakır. Hazırı dururken elle eğri çizmeye gerek yok:

withAnimation(.spring(response: 0.35, dampingFraction: 0.8)) {
    isExpanded.toggle()
}

İki parametre, platformun diliyle konuşan bir animasyon. Dokunsal geri bildirim de aynı ucuz-kazanç sınıfında: doğru anda gelen minik bir titreşim — sensoryFeedback(.success, trigger:) — bir eylemin 'gerçekten olduğu' hissini verir. Bunlar süsleme değil; kullanıcının güven duygusunun yapı taşları.

Görünümü Aptal Tutun

Mimaride sıkı sıkıya bağlı olduğumuz tek ilke: görünümler aptaldır. İş mantığı bilmezler; veri alır, çizerler. Durum yönetimi container katmanında, navigasyon kendi katmanında yaşar:

struct AvatarView: View {
    let user: User

    var body: some View {
        HStack(spacing: 12) {
            Circle()
                .fill(.pink.gradient)
                .frame(width: 44, height: 44)
            Text(user.name)
                .font(.headline)
        }
    }
}

Bu ayrımın günlük karşılığı preview'larda ortaya çıkıyor: aptal bir görünüm, uygulamayı ayağa kaldırmadan tek başına önizlenebilir. Tasarımcıyla aynı ekrana bakıp 'bu boşluk 4 mü 8 mi' tartışmasını kod üzerinde, anında yapıyoruz. Preview'lar bizim için canlı tasarım dokümanına dönüştü; Figma ile kod arasındaki 'acaba aynı mı' boşluğu kapandı.

Sınırı Bilmek

SwiftUI olgunlaştı ama her savaşın silahı değil. Milimetrik kontrol isteyen metin düzenleyiciler, kamera arayüzleri, çok özel kaydırma davranışları — buralarda hâlâ UIKit'e iniyor ve UIViewRepresentable ile köprü kuruyoruz. Bunda bir yenilgi yok; ustalık zaten sınırı nereye çizeceğini bilmekte. Dogmatik 'her şey SwiftUI olacak' tutumu, basit bir işi kahramanlık destanına çevirmenin en garantili yolu.

Soru artık 'SwiftUI ile yapılabilir mi?' değil; 'en temiz nerede yapılır?'

Bugün geldiğimiz nokta şu: native his neredeyse bedava, üstüne yalnızca kendi ürün kararlarınızı koyuyorsunuz. Detaylara saygılı tek kişilik bir ekip bile birkaç haftada App Store kalitesinde bir şey çıkarabiliyor. 'Flutter'la olmaz mıydı?' Olurdu. Ama fark, kullanıcının adlandıramadığı o ilk üç saniyede hissediliyor.

Atomik Değişikliğin Rahatlığı

Monorepo'nun asıl vaadi tek kelime: atomiklik. API şemasında bir alanı yeniden adlandırdığınızda, onu tüketen web ve mobil kod aynı pull request'te güncellenir. Kırılan ne varsa diff'te, gözünüzün önündedir. Ayrı depolarda aynı iş sürüm yükseltme dansına dönüşür: paketi yayınla, üç depoda ayrı ayrı yükselt, hangi sürümün hangisiyle uyumlu olduğunu bir tabloda tut. Tek depoda ana dal her an kendi içinde tutarlıdır — bizim için mimari tartışmayı bitiren cümle buydu.

Kurulum: Sandığınızdan Az

Reçetemiz pnpm workspace + Turborepo; özü iki küçük dosya:

# pnpm-workspace.yaml
packages:
  - "apps/*" # web, mobile, api
  - "packages/*" # paylaşılan: ui, config, api-client

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": { "dependsOn": ["build"] }
  }
}

^build şu demek: bir paketi derlemeden önce bağımlı olduklarını derle. Turborepo görev grafiğini çıkarıyor ve değişmeyen her şeyi önbellekten getiriyor. Depo büyüdükçe bu önbellek altın değerinde — depo üç kat büyüdü, CI süremiz hâlâ ilk günkünden kısa.

Asıl Mesele: Katman Disiplini

Kötü haber: araçlar sizi kurtarmaz. Monorepo'ların çöktüğü yer teknik değil, disiplinseldir — sınırlar bulanır, herkes her pakete uzanır ve altı ay sonra elinizde tek depoluk bir bağımlılık yumağı kalır. Kuralımız tek yönlü: uygulamalar paketlere bağlanabilir; paketler uygulamalara asla. Ve bu kuralı insana değil, lint'e emanet ediyoruz:

{
  "rules": {
    "import/no-restricted-paths": ["error", {
      "zones": [
        { "target": "./packages", "from": "./apps" }
      ]
    }]
  }
}

Yasak otomatikleşince tartışma da bitiyor: ihlal, code review'da fikir ayrılığı değil, kırmızı bir CI işareti. İnsanlar kuralı hatırlamakla değil, işiyle uğraşıyor.

Depo büyüdükçe kural ekleyeceğinize otomasyon ekleyin. Aracın zorladığı kural kalıcıdır; insanın hatırladığı kural, o insan izne çıkana kadar.

Dürüst bir dipnot: monorepo bedava değil. CI kurulumu emek istiyor, git geçmişi kalabalıklaşıyor, yanlış kurgulanırsa herkes herkesi bekliyor. Sözleşme paylaşmayan, ayrı yaşayan ürünler için hâlâ ayrı depolar öneriyoruz. Ama o üç günlük üretim hatasından beri, aynı sözleşmeyi konuşan kodların ayrı evlerde yaşamasına gönlümüz razı değil.