Bir fonksiyonu $f(x)$ gibi düşünelim. Test yazarken aslında belirli girdiler için şu önermeyi kontrol ederiz: $f(girdi) = beklenen_çıktı$. Örneğin indirim hesaplayan bir fonksiyonda $f(100, 0.2) = 80$ olmalıdır. Eğer bu önerme bozulursa test kırmızıya döner ve bize şunu söyler: Kodun davranışı ile beklentin aynı evrende yaşamıyor.

Birim testlerinde yaygın desen Arrange-Act-Assert üçlüsüdür. Önce ortamı hazırlarız, sonra fonksiyonu çalıştırırız, en sonunda sonucu doğrularız. Python ve pytest ile küçük ama anlamlı bir örnek görelim:

def calculate_discount(price, rate):
    if price < 0:
        raise ValueError('price cannot be negative')
    if not 0 <= rate <= 1:
        raise ValueError('rate must be between 0 and 1')
    return price * (1 - rate)


def test_calculate_discount_normal_case():
    # Arrange
    price = 100
    rate = 0.25

    # Act
    result = calculate_discount(price, rate)

    # Assert
    assert result == 75


def test_calculate_discount_rejects_negative_price():
    import pytest
    with pytest.raises(ValueError):
        calculate_discount(-10, 0.2)

Bu testler sadece normal senaryoyu değil, hata senaryosunu da kontrol eder. İyi test yazmanın püf noktası, mutlu yol kadar mutsuz yolları da düşünmektir. Çünkü kullanıcılar her zaman bizim hayal ettiğimiz gibi davranmaz; bazen eksi fiyat girerler, bazen yüzde 400 indirim isterler, bazen de sistemin sabrını sınarlar.

Test kapsamı konuşulurken sıkça coverage oranı gündeme gelir. Diyelim ki projenizde 100 satır çalıştırılabilir kod var ve testler 85 satırı çalıştırıyor. Kapsam yaklaşık $Coverage = \frac{85}{100} \times 100 = 85\%$ olur. Ancak dikkat: Yüksek coverage, kaliteli test anlamına her zaman gelmez. Bir satırı çalıştırmak başka, onun doğru davrandığını doğrulamak başkadır.

Gelelim profil analizine. Kod doğru olabilir ama yavaşsa kullanıcı yine mutsuz olur. Python’da cProfile, hangi fonksiyonun kaç kez çağrıldığını ve toplamda ne kadar süre harcadığını gösterir:

import cProfile

def slow_sum(numbers):
    total = 0
    for number in numbers:
        total += number
    return total

if __name__ == '__main__':
    data = range(10_000_000)
    cProfile.run('slow_sum(data)')

Bu çıktı bize darboğazları gösterir. Performans analizinde önemli olan tahminle değil ölçümle hareket etmektir. Çünkü geliştiricinin iç sesi çoğu zaman dramatiktir: “Kesin şu döngü yavaş!” Profil aracı ise sakin bir şekilde “Hayır dostum, asıl sorun veritabanı çağrısında” diyebilir.

Birim testleri ve profil araçları birlikte kullanıldığında güvenli refactoring mümkün olur. Önce testlerle davranışı sabitlersin, sonra profille yavaş noktaları bulursun, ardından kodu iyileştirirsin. Son adımda testleri tekrar çalıştırırsın. Eğer testler yeşilse ve profil daha iyiyse, kodun hem doğru hem de daha fit hale gelmiştir.

Özetle, test yazmak zaman kaybı değil, gelecekteki panik anlarına yapılan yatırımdır. Profil analizi de optimizasyonu falcılıktan çıkarıp mühendisliğe dönüştürür. Koduna küçük bir laboratuvar kur: testlerle doğrula, profille ölç, sonra gönül rahatlığıyla geliştir.

Temel kavram akıştır. Akış, verinin bir kaynaktan hedefe sıralı şekilde aktığı soyut kanaldır. Dosya, terminal, ağ soketi veya bellek tamponu birer akış gibi düşünülebilir. Matematiksel olarak okuma maliyetini basitçe şöyle düşünebiliriz: $T = \frac{B}{R} + L$. Burada $B$ taşınan bayt sayısı, $R$ aktarım hızı, $L$ ise gecikmedir. Küçük küçük binlerce okuma yapmak $L$ değerini tekrar tekrar ödetir; parçalı ama dengeli okumak genelde daha verimlidir.

Metin dosyalarında kodlama konusu da kritik. UTF-8 bugün varsayılan kahramanımızdır; Türkçe karakterlerin bozulmaması için dosya açarken kodlamayı açıkça belirtmek iyi alışkanlıktır. İkili dosyalarda ise karakter değil bayt okuruz; resim, ses veya sıkıştırılmış dosyalar bu kategoriye girer.

Aşağıdaki örnek, bir JSON ayar dosyasını okumayı; dosya yoksa varsayılan içerikle oluşturmayı gösterir:

from pathlib import Path
import json

path = Path('ayarlar.json')

try:
    with path.open('r', encoding='utf-8') as f:
        config = json.load(f)
except FileNotFoundError:
    config = {'tema': 'dark', 'sayfa_boyutu': 20}
    with path.open('w', encoding='utf-8') as f:
        json.dump(config, f, ensure_ascii=False, indent=2)

print(config['tema'])

Burada with bloğu çok önemlidir. Dosyayı açar, iş bitince otomatik kapatır. Eğer istisna oluşursa bile kaynak sızıntısı yaşanmaz. Bu fikir genelde RAII veya context management mantığıyla açıklanır: Kaynağı kim aldıysa, düzenli biçimde geri bırakmalıdır.

Yazma işlemlerinde bir başka hassas konu atomikliktir. Program dosyayı yazarken çökerse yarım kalmış, bozuk bir dosya bırakabilir. Daha güvenli yaklaşım önce geçici dosyaya yazmak, sonra hedef dosyayla atomik olarak değiştirmektir.

from pathlib import Path
import os, tempfile

def guvenli_yaz(hedef: Path, veri: str):
    klasor = hedef.parent
    with tempfile.NamedTemporaryFile('w', encoding='utf-8', dir=klasor, delete=False) as tmp:
        tmp.write(veri)
        tmp.flush()
        os.fsync(tmp.fileno())
        gecici_ad = tmp.name
    os.replace(gecici_ad, hedef)

guvenli_yaz(Path('rapor.txt'), 'Merhaba dosya sistemi!')

flush() veriyi kullanıcı alanı tamponundan işletim sistemine iter; fsync() ise diske yazılmasını daha güçlü biçimde talep eder. Her zaman gerekli değildir, çünkü pahalıdır; ama para transferi, kritik ayar veya işlem günlüğü gibi durumlarda değerlidir.

Son olarak, dosya yolu güvenliğini unutmayın. Kullanıcıdan gelen dosya adını doğrudan birleştirmek path traversal gibi sorunlara yol açabilir. Ayrıca eşzamanlı çalışan programlarda kilitleme, izinler ve yarış koşulları düşünülmelidir. Kısacası dosya I/O, basit bir kapı kolu gibi görünür; ama arkasında bellek yönetimi, işletim sistemi çağrıları ve veri bütünlüğüyle dolu koca bir makine odası vardır. Doğru akış modelini seçerseniz, veriniz de programınız da huzurla yaşar.

JSON ve serileştirmenin teorisi

Serileştirme, bellekte duran bir veri yapısını aktarılabilir bir biçime dönüştürme işlemidir. Go’da buna çoğunlukla marshal, tersine ise unmarshal denir. Matematiksel düşünürsek, serileştirmeyi bir dönüşüm fonksiyonu gibi görebiliriz: $f: GoStruct \rightarrow JSON$. Ters işlem ise $f^{-1}: JSON \rightarrow GoStruct$ şeklindedir. Elbette pratikte $f^{-1}$ her zaman mükemmel değildir; eksik alanlar, tip uyuşmazlıkları veya beklenmeyen değerler yüzünden hata alabiliriz.

JSON’un avantajı basit olmasıdır: string, number, boolean, array, object ve null. Go ise daha zengin tiplere sahiptir. Bu yüzden iki dünya arasında çeviri yaparken tip eşleşmelerini iyi bilmek gerekir.

Struct tag: JSON pasaport kontrolü

Go’da alan adları dışa açılmak için büyük harfle başlamalıdır. Ancak JSON alan isimleri genellikle küçük harfli veya snake_case olur. İşte struct tag burada devreye girer.

package main

import (
    "encoding/json"
    "fmt"
)

type User struct {
    ID       int    `json:"id"`
    FullName string `json:"full_name"`
    Email    string `json:"email,omitempty"`
}

func main() {
    user := User{ID: 7, FullName: "Ada Lovelace"}

    data, err := json.MarshalIndent(user, "", "  ")
    if err != nil {
        panic(err)
    }

    fmt.Println(string(data))
}

Bu örnekte MarshalIndent, JSON’u okunabilir biçimde üretir. omitempty ise alan boşsa JSON’a yazma anlamına gelir. Yani e-posta yoksa gereksiz bir email alanı gönderilmez. API tüketen sistemlerin “Bu niye boş geldi?” diye trip atmasını engeller.

Gelen JSON’u Go yapısına çözmek

Dış sistemden veri geldiğinde json.Unmarshal kullanırız. Burada önemli detay, hedef değişkenin adresini vermektir; çünkü Go’nun o değişkenin içini doldurması gerekir.

package main

import (
    "encoding/json"
    "fmt"
)

type Product struct {
    Code  string  `json:"code"`
    Price float64 `json:"price"`
    Stock int     `json:"stock"`
}

func main() {
    raw := []byte(`{"code":"KB-42","price":129.90,"stock":15}`)

    var product Product
    err := json.Unmarshal(raw, &product)
    if err != nil {
        fmt.Println("JSON hatası:", err)
        return
    }

    fmt.Printf("%s ürünü %.2f TL\n", product.Code, product.Price)
}

Buradaki fiyat alanı için float64 kullandık. Para işlemlerinde kayan nokta hassasiyetine dikkat etmek gerekir. Örneğin $0.1 + 0.2 \neq 0.3$ gibi görünen sonuçlar bilgisayar temsilinden kaynaklanabilir. Finansal uygulamalarda kuruşu int olarak saklamak daha güvenlidir.

Struct mı map mi?

Her JSON için struct yazmak zorunda değilsiniz. Dinamik veya şeması belirsiz verilerde map[string]interface{} kullanılabilir. Ancak bu esneklik, tip güvenliğinden ödün verir.

Hata yönetimi ve sözleşme bilinci

JSON işlemlerinde en büyük hata, “Karşı taraf doğru gönderir ya” rahatlığıdır. Göndermez. Alan eksik gelir, sayı string gelir, null gelir, hatta bazen HTML hata sayfası JSON sanılıp parse edilmeye çalışılır. Bu yüzden her Marshal ve Unmarshal çağrısında hata kontrolü yapılmalıdır.

Ayrıca JSON, sistemler arası bir sözleşmedir. Bu sözleşmenin maliyetini basitçe şöyle düşünebiliriz: $Toplam\ Risk = Veri\ Belirsizliği \times Entegrasyon\ Sayısı$. Entegrasyon arttıkça küçük tip hataları bile büyük problemlere dönüşür.

Sonuç

Go’nun encoding/json paketi, dış sistemlerle konuşmak için sade ama güçlü bir araçtır. Struct tag’leriyle alan adlarını kontrol eder, Marshal ile veriyi dışarı yollar, Unmarshal ile gelen veriyi güvenli şekilde içeri alırız. İyi modellenmiş struct’lar, dikkatli hata yönetimi ve tip farkındalığı sayesinde JSON iletişimi kaotik bir mesajlaşma grubu olmaktan çıkar, düzenli bir protokole dönüşür.

HTTP Mantığını Kısaca Isıtalım

HTTP, istemci ile sunucu arasında yapılan istek-yanıt tabanlı bir protokoldür. Tarayıcı istemcidir; Go ile yazdığımız uygulama ise sunucudur. İstemci “Bana / adresini ver” der, sunucu da “Buyur, içerik burada” diye yanıt döner.

Bu model basitçe şöyle düşünülebilir:

Daha teknik bir bakışla yanıt süresi şu şekilde modellenebilir:

Yani iyi bir web sunucusu yalnızca çalışmakla kalmaz; istekleri doğru yakalar, hızlı işler ve anlaşılır yanıt üretir.

İlk Go HTTP Sunucusu

Aşağıdaki örnek, kök adrese gelen HTTP isteklerini karşılayan sade bir Go web sunucusudur:

package main

import (
    "fmt"
    "log"
    "net/http"
)

func homeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Merhaba! Go HTTP sunucusu çalışıyor.")
}

func main() {
    http.HandleFunc("/", homeHandler)

    log.Println("Sunucu http://localhost:8080 üzerinde çalışıyor...")
    err := http.ListenAndServe(":8080", nil)
    if err != nil {
        log.Fatal(err)
    }
}

Bu kodda http.HandleFunc, belirli bir URL yolunu fonksiyona bağlar. / yoluna istek geldiğinde homeHandler çalışır. http.ResponseWriter, istemciye yanıt yazmamızı sağlar. *http.Request ise gelen isteğin metodunu, başlıklarını, yolunu ve gövdesini taşır.

Programı çalıştırmak için:

go run main.go

Ardından tarayıcıda http://localhost:8080 adresine gittiğinde mesajı görürsün. Tebrikler, artık kendi mini web sunucun var!

İstek Metodunu Kontrol Etmek

HTTP’de her istek aynı değildir. GET veri okumak, POST veri göndermek için kullanılır. Handler içinde metodu kontrol ederek daha bilinçli davranabiliriz:

func helloHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodGet {
        http.Error(w, "Sadece GET desteklenir", http.StatusMethodNotAllowed)
        return
    }

    name := r.URL.Query().Get("name")
    if name == "" {
        name = "Gopher"
    }

    fmt.Fprintf(w, "Merhaba, %s!", name)
}

Bu fonksiyon /hello?name=Ayse gibi bir istek aldığında kişiselleştirilmiş yanıt üretir. Boş gelirse varsayılan olarak Gopher der. Küçük ama üretim mantığına yakın bir davranış!

JSON Yanıt Döndürmek

Web sunucuları çoğu zaman HTML değil JSON döndürür. Go’da bu da standart kütüphane ile mümkündür:

func statusHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintln(w, `{"status":"ok","message":"Sunucu ayakta"}`)
}

Header ayarı önemlidir; istemciye “Benim yanıtım JSON formatında” demiş oluruz. Bu küçük detay, API tüketen uygulamaların doğru davranmasını sağlar.

Sonuç

Go ile temel HTTP sunucusu geliştirmek, web’in çalışma mantığını öğrenmek için harika bir başlangıçtır. Framework kullanmadan route, handler, request, response ve method gibi temel kavramları çıplak gözle görürsün. Bu sayede ileride Gin, Echo veya Fiber gibi framework’lere geçtiğinde arka planda neler döndüğünü çok daha iyi anlarsın. Kısacası Go’nun net/http paketi, küçük projeler için yeterince sade; büyük fikirler içinse yeterince güçlüdür.

Teorik altyapı için üç şeyi ayırmak çok işe yarar: veri yapısı, karmaşıklık ve bağlam. Bir algoritma hilesi genellikle bu üçlünün kesişiminde saklanır. Örneğin eski bir arama aracında tam metin arama yerine bit maskeleri kullanılmış olabilir. Eğer belge sayısı $n$, kelime sayısı $m$ ise klasik yaklaşımda sorgu maliyeti kabaca $O(n \cdot m)$ gibi büyürken, bit kümeleriyle kesişim almak $O(n / w)$ seviyesine iner; burada $w$ makine kelimesi genişliğidir. Yani 64 bitlik işlemcide tek hamlede 64 olasılık süzülür. Bu, küçük bir sihir değil; donanımı algoritmaya dahil etmektir.

Arkeolojik kazıda en sevdiğim örneklerden biri, eski oyun motorlarında görülen “kirli dikdörtgen” tekniğidir. Ekranın tamamını yeniden çizmek yerine sadece değişen bölgeler işaretlenir. Bugün bunu “incremental rendering” diye daha havalı anlatıyoruz. Mantık basittir: Eğer ekran alanı $A$, değişen alan $d$ ise ve $d \ll A$ ise, çizim maliyeti dramatik biçimde düşer. Formül gibi söyleyelim: toplam iş $T \approx c \cdot d$ olur, $c \cdot A$ değil.

Aşağıdaki örnek, terk edilmiş bir GUI kütüphanesinde görebileceğiniz fikri modern Python ile sadeleştirir. Amaç, çakışan kirli bölgeleri birleştirip gereksiz çizimi azaltmaktır:

from dataclasses import dataclass

@dataclass
class Rect:
    x: int
    y: int
    w: int
    h: int

    def overlaps(self, other):
        return not (
            self.x + self.w < other.x or other.x + other.w < self.x or
            self.y + self.h < other.y or other.y + other.h < self.y
        )

    def merge(self, other):
        x1 = min(self.x, other.x)
        y1 = min(self.y, other.y)
        x2 = max(self.x + self.w, other.x + other.w)
        y2 = max(self.y + self.h, other.y + other.h)
        return Rect(x1, y1, x2 - x1, y2 - y1)

def compact_dirty_regions(regions):
    result = []
    for rect in regions:
        for i, old in enumerate(result):
            if rect.overlaps(old):
                result[i] = old.merge(rect)
                break
        else:
            result.append(rect)
    return result

Bu kod kusursuz bir geometri motoru değildir; fakat fikri net gösterir. Eski projelerde sıkça karşılaşılan değer de budur: üretim seviyesinde paketlenmiş bir çözüm değil, doğru problemi doğru yerinden yakalayan küçük bir mekanizma.

Kod arkeolojisi yaparken commit geçmişi, issue tartışmaları ve test dosyaları altın değerindedir. Kod “ne” yaptığını söyler, testler “neden” yaptığını fısıldar, issue’lar ise “hangi acı yüzünden” yazıldığını bağırır. Özellikle performansla ilgili yamalarda şu izi arayın: Önce basit çözüm vardır, sonra kullanıcı şikâyeti gelir, ardından küçük ama keskin bir optimizasyon eklenir.

Sonuçta terk edilmiş repolar birer mezarlık değil, fikir fosili yatağıdır. Her eski hileyi bugüne taşımak gerekmez; bazıları sadece döneminin kısıtlarına uygundur. Ama iyi bir kod arkeoloğu, paslı satırların arasından şu soruyu çıkarır: “Bu çözüm hangi basit ilkeye dayanıyor?” Cevap çoğu zaman hâlâ değerlidir: daha az iş yap, veriyi doğru biçimde tut, sınır durumunu baştan tasarla ve algoritmanın matematiğini unutma.

Go’da temel organizasyon birimi package kavramıdır. Aynı amaca hizmet eden fonksiyonlar, tipler ve değişkenler bir paket altında toplanır. Örneğin payment, user, logger gibi paketler hem okunabilirliği artırır hem de kodun tekrar kullanılmasını kolaylaştırır. Daha büyük ölçekte ise module, bir veya daha fazla paketi içeren ve kökünde go.mod dosyası bulunan sürümlenebilir proje birimidir.

Teorik olarak şöyle düşünebiliriz: Paket, kodun mantıksal bölmesidir; modül ise bu bölmelerin sürüm ve bağımlılık kimliğidir. Eğer projenin bağımlılık kümesini $D$ ve her bağımlılığın seçilen sürümünü $v_i$ olarak düşünürsek, modülün derlenebilir durumu kabaca şöyle ifade edilebilir: $M = {(d_i, v_i) \mid d_i \in D}$. Yani sadece hangi kütüphaneyi kullandığın değil, hangi sürümünü kullandığın da önemlidir.

Yeni bir Go modülü başlatmak için genellikle şu komut kullanılır:

go mod init github.com/kullanici/proje

Bu komut projenin kökünde go.mod dosyası üretir. Basit bir go.mod şöyle görünebilir:

module github.com/kullanici/proje

go 1.22

require github.com/google/uuid v1.6.0

Burada module satırı projenin kimliğini, go satırı hedef Go sürümünü, require satırı ise dış bağımlılığı belirtir. github.com/google/uuid v1.6.0 ifadesi, projede UUID üretmek için kullanılan paketin belirli bir sürümünü kilitler. Böylece bugün çalışan kodun yarın gizemli biçimde bozulma ihtimali azalır.

Go’da paketleri kullanmak oldukça doğaldır. Diyelim ki internal/logger adlı bir paket yazdık:

package logger

import "fmt"

func Info(message string) {
    fmt.Println("[INFO] " + message)
}

Ana uygulamada bu paketi şöyle çağırabiliriz:

package main

import "github.com/kullanici/proje/internal/logger"

func main() {
    logger.Info("Uygulama başladı")
}

Buradaki internal klasörü özel bir anlama sahiptir: Go, bu klasör altındaki paketlerin yalnızca ilgili modül içinde kullanılmasına izin verir. Bu da mimari sınırları korumak için harika bir yöntemdir. Kısacası internal, paketin kapısına asılmış nazik ama kararlı bir “personel harici giremez” tabelasıdır.

Sürümleme tarafında Go Modules, semantik sürümleme yaklaşımını destekler. Genel biçim $MAJOR.MINOR.PATCH$ şeklindedir. Örneğin v1.6.0 için $MAJOR=1$, $MINOR=6$, $PATCH=0$ olur.

Bağımlılık eklemek için çoğu zaman ayrıca dosya düzenlemeye gerek yoktur. Şu komut yeterlidir:

go get github.com/google/uuid@v1.6.0

Ardından kullanılmayan bağımlılıkları temizlemek ve eksikleri tamamlamak için şu komut çalıştırılır:

go mod tidy

go mod tidy, projenin oda toparlayan robot süpürgesi gibidir: gereksizleri kaldırır, eksikleri yerine koyar. CI/CD süreçlerinde de bu dosyaların tutarlı olması önemlidir. go.mod ve go.sum dosyaları mutlaka sürüm kontrolüne eklenmelidir; çünkü ekip arkadaşlarının ve sunucuların aynı bağımlılık ağacını kurmasını sağlar.

Sonuç olarak Go Modules, sadece “kütüphane indirme aracı” değildir. Kodun sınırlarını çizen, bağımlılıkları matematiksel bir kesinlikle sürümlere bağlayan ve projeyi taşınabilir hale getiren bir sistemdir. Paketler kodu okunabilir kılar, modüller ise projeyi güvenilir yapar. İyi organize edilmiş bir Go projesinde her paket kendi işini bilir, her bağımlılığın sürümü bellidir ve geliştirici de hata ayıklamak yerine keyifle üretmeye odaklanır.

Rastgelelik Ne Demek?

Gündelik hayatta rastgelelik, sonucu önceden bilememek demektir. Ancak bilgisayar biliminde bu tanım yetmez. Bir sayı dizisinin rastgele görünmesi, onun gerçekten nedensiz olduğu anlamına gelmez. Determinist bir sistemde aynı başlangıç koşulları aynı sonucu üretir. Yani bir algoritmaya aynı tohumu, yani seed değerini verirseniz, aynı sayı dizisini tekrar alırsınız.

Matematiksel olarak birçok sözde rastgele sayı üreteci şu fikre dayanır:

$X_{n+1} = (aX_n + c) \bmod m$

Bu formül, Linear Congruential Generator yani LCG adı verilen klasik yöntemin kalbidir. Burada $X_n$ mevcut durum, $a$ çarpan, $c$ artış ve $m$ mod değeridir. Sonuçta kaotik görünen ama tamamen hesaplanabilir bir dizi oluşur.

Seed: Kaderin Küçük Başlangıç Noktası

Seed, algoritmanın başlangıç koşuludur. Determinist felsefede evrenin tüm anları, ilk koşullardan zorunlu olarak çıkıyorsa; PRNG de bunun cep boy versiyonudur. Seed değerini bilirseniz geleceği bilirsiniz. Bu, Laplace’ın şeytanı fikrine benzer: Evrenin tüm parçacıklarının konumunu ve hızını bilen bir zihin, geçmişi ve geleceği hesaplayabilir miydi?

Basit bir PRNG örneği görelim:

class LCG:
    def __init__(self, seed):
        self.state = seed
        self.a = 1664525
        self.c = 1013904223
        self.m = 2**32

    def next_int(self):
        self.state = (self.a * self.state + self.c) % self.m
        return self.state

    def random(self):
        return self.next_int() / self.m

rng = LCG(42)
numbers = [rng.random() for _ in range(5)]

Bu kodda random() metodu 0 ile 1 arasında sayı üretir. Fakat sihir yoktur; her şey state değişkeninin dönüşümünden ibarettir. 42 seed değeriyle çalıştırırsanız, diziniz her seferinde aynı olur. Yani bilgisayar ‘şaşırmaz’, sadece bizi şaşırtır.

Entropi: Bilgisayarın Kaos Arayışı

Gerçek rastgeleliğe yaklaşmak için işletim sistemleri fare hareketleri, klavye zamanlamaları, disk erişim gecikmeleri veya donanımsal gürültüler gibi kaynaklardan entropi toplar. Entropi, kabaca belirsizlik miktarıdır. Bilgi kuramında şu şekilde ifade edilir:

$H(X)=-\sum p(x)\log_2 p(x)$

Bir olay ne kadar öngörülemezse entropisi o kadar yüksektir. Adil bir yazı-tura atışında iki sonuç da eşit olasılıklıdır ve belirsizlik maksimumdur. Ama hileli bir paranın sonucu daha tahmin edilebilirdir; entropisi düşer.

Metafizik Soru: Rastgelelik Cehalet mi, Gerçek mi?

Eğer evren tamamen deterministse, rastgelelik sadece bizim bilgisizliğimiz olabilir. Zarın sonucu, hava direnci, atış açısı, yüzey sürtünmesi ve kuvvet bilinse hesaplanabilir. Bu bakışa göre rastgelelik epistemiktir: Bilginin eksikliğinden doğar.

Ama kuantum mekaniği sahneye çıkınca işler karışır. Bazı yorumlara göre parçacıkların davranışı temelde olasılıksaldır. Bu durumda rastgelelik ontolojik olabilir: Yani sadece bilmiyoruz değil, gerçekten belirlenmemiştir. Bilgisayarlar bu tartışmayı çözmez; sadece onu kod yazarken masamıza getirir.

Sonuç: Rastgelelik Bir Araç, Bir Ayna ve Bir Şaka

Programcı için rastgele sayı üretimi, test verisi hazırlamak, oyun tasarlamak, simülasyon yapmak ve güvenlik sağlamak için vazgeçilmezdir. Filozof içinse aynı konu, özgür irade ve determinizm tartışmasının dijital bir modelidir. Bilgisayarların ürettiği çoğu rastgelelik aslında sözde rastgeleliktir; ama yeterince iyi tasarlandığında pratikte harika çalışır.

Belki de en güzel cevap şudur: Bilgisayar rastgeleliği üretmez, rastgelelik hissini mühendislik eder. Ve bazen, yazılım dünyasında ihtiyacımız olan şey tam olarak budur.

Teorik olarak select ifadesini olay tabanlı bir karar mekanizması gibi düşünebiliriz. Elimizde $n$ adet kanal olsun: $C_1, C_2, …, C_n$. Her kanalın veri üretme zamanı farklıdır. Programın tepki süresi kabaca şu şekilde modellenebilir:

Yani en erken hazır olan kanal, akışı belirler. Bu sayede yavaş bir işlem, hızlı gelen başka bir sinyali engellemez. Özellikle ağ programlama, worker pool, timeout yönetimi ve iptal edilebilir işlemlerde bu yaklaşım hayat kurtarır.

Basit bir örnekle başlayalım. Aşağıdaki kodda iki farklı kanal farklı sürelerde veri üretir. select, hangisi önce hazır olursa onu işler:

package main

import (
    "fmt"
    "time"
)

func main() {
    fast := make(chan string)
    slow := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        fast <- "hızlı kanaldan veri geldi"
    }()

    go func() {
        time.Sleep(3 * time.Second)
        slow <- "yavaş kanaldan veri geldi"
    }()

    select {
    case msg := <-fast:
        fmt.Println(msg)
    case msg := <-slow:
        fmt.Println(msg)
    }
}

Bu örnekte program büyük olasılıkla fast kanalındaki mesajı basar. Çünkü fast kanalı 1 saniyede hazır olurken slow 3 saniye bekler. Buradaki kritik nokta şudur: select, kodu sırayla yukarıdan aşağıya denemez; hazır olan case çalışır. Birden fazla kanal aynı anda hazırsa Go çalışma zamanı bunlardan birini sözde rastgele seçer. Bu özellik, bazı kanalların sürekli öncelik kazanmasını engellemeye yardımcı olur.

select ifadesi timeout ile birleştiğinde daha da kullanışlı hale gelir. Diyelim ki bir servisten cevap bekliyorsunuz ama sonsuza kadar beklemek istemiyorsunuz:

select {
case result := <-responseCh:
    fmt.Println("Cevap alındı:", result)
case <-time.After(2 * time.Second):
    fmt.Println("İstek zaman aşımına uğradı")
}

Burada time.After, belirtilen süre sonunda veri gönderen özel bir kanal döndürür. Eğer responseCh iki saniye içinde cevap vermezse timeout bloğu çalışır. Böylece uygulama takılı kalmaz, kullanıcıya veya üst sisteme kontrollü bir sonuç döner.

Bazen de hiç beklemek istemeyiz. Bunun için default kullanılır:

select {
case job := <-jobs:
    fmt.Println("İş alındı:", job)
default:
    fmt.Println("Şu an hazır iş yok, başka göreve geçiliyor")
}

default, hazır kanal yoksa hemen çalışır. Ancak dikkat: Bu yapı döngü içinde kontrolsüz kullanılırsa sürekli dönerek CPU tüketebilir. Genellikle kısa beklemeler, time.Sleep veya daha iyi bir olay tasarımıyla desteklenmelidir.

Özetle select, Go’da çoklu kanal yönetiminin kalbidir. Onu sadece bir switch benzeri yapı olarak görmek eksik olur; aslında zaman, veri ve iptal sinyalleri arasında akıllı bir koordinasyon sağlar. Doğru kullanıldığında sisteminiz daha tepkisel, daha güvenli ve daha ölçeklenebilir hale gelir. Kısacası goroutine’ler orkestraysa, select elindeki bagetle tüm ritmi yöneten şeftir.

Arayüzü teorik olarak bir sözleşme gibi düşünebiliriz. Bir arayüz, “Beni uygulayan her yapı şu metotları, özellikleri veya davranışları sağlayacak” der. Ancak bunu nasıl yapacağını söylemez. Matematiksel olarak bir arayüzü, nesneler kümesinden davranışlar kümesine kurulan bir beklenti ilişkisi gibi görebiliriz: $I = {b_1, b_2, b_3}$ ise, bu arayüzü uygulayan her nesne bu davranışları sağlamalıdır. Burada önemli olan nesnenin iç yapısı değil, dışarıdan gözlemlenebilen davranışıdır.

Çok biçimlilik yani polymorphism ise aynı mesajın farklı nesnelerde farklı şekillerde çalışabilmesidir. Örneğin draw() çağrısı bir daireyi yuvarlak, bir kareyi köşeli çizer. Çağıran kod için önemli olan şeklin gerçek sınıfı değil, çizilebilir olmasıdır. Bu yaklaşım $Kod -> Arayüz$ bağımlılığını güçlendirir, $Kod -> SomutSınıf$ bağımlılığını azaltır.

Basit bir TypeScript örneği düşünelim:

interface Payable {
  calculatePayment(): number;
}

class Employee implements Payable {
  constructor(private salary: number) {}

  calculatePayment(): number {
    return this.salary;
  }
}

class Freelancer implements Payable {
  constructor(private hourlyRate: number, private hours: number) {}

  calculatePayment(): number {
    return this.hourlyRate * this.hours;
  }
}

function printPayment(entity: Payable): void {
  console.log('Ödeme: ' + entity.calculatePayment());
}

printPayment(new Employee(40000));
printPayment(new Freelancer(750, 32));

Burada printPayment fonksiyonu, parametrenin Employee ya da Freelancer olmasını umursamaz. Tek şartı vardır: Payable davranışını sağlaması. Bu fonksiyonun zihni oldukça rahattır; CV sormaz, sadece ödeme hesaplayabiliyor musun diye bakar.

Bu tasarımın gücü, Açık/Kapalı Prensibi ile birleştiğinde ortaya çıkar. Yazılım birimleri genişletmeye açık, değiştirmeye kapalı olmalıdır. Yeni bir Consultant sınıfı eklediğimizde printPayment fonksiyonunu değiştirmiyorsak doğru yoldayız demektir. Teorik olarak bu, sistemin yeni türler karşısında kararlı kalmasıdır: $YeniTip + EskiArayüz = DahaAzKırılma$.

Ancak arayüz kullanmak her derde deva büyülü bir iksir değildir. Gereksiz arayüzler, projede “soyutlama sisi” oluşturabilir. Eğer sadece tek bir sınıfınız varsa ve değişim ihtimali düşükse, hemen arayüz üretmek erken mühendislik olabilir. İyi arayüz, gerçek bir değişim eksenini temsil eder. Yani “ileride farklı ödeme stratejileri olabilir” diyorsanız Payable anlamlıdır; ama “belki bir gün kahve makinesi de ödeme hesaplar” diyorsanız biraz sakinleşmek gerekebilir.

Arayüzlerin bir diğer güzelliği testlerde görülür. Somut veritabanı bağlantısı yerine Repository arayüzüne bağımlı kod, test sırasında sahte bir bellek içi nesneyle çalışabilir. Böylece kodun davranışını izole ederiz. Bu da yazılımı daha ölçülebilir yapar; çünkü test maliyeti kabaca $Maliyet = Kurulum + Bağımlılık + Bekleme$ ise, arayüzler özellikle bağımlılık ve bekleme kısmını azaltır.

Sonuç olarak arayüzler, yazılım tasarımında kimlik kontrolünden davranış kontrolüne geçiştir. Çok biçimlilikle birleştiğinde, aynı kodun farklı nesnelerle uyumlu çalışmasını sağlar. Bu yaklaşım, gelecekte gelecek yeni sınıflara kapıyı açık bırakırken mevcut kodu sakin ve kararlı tutar. Kısacası iyi tasarlanmış bir arayüz şunu söyler: “Bana nereden geldiğini anlatma, ne yapabildiğini göster.”

Teorik Temel: Boyut mu, Esneklik mi?

Dizi, uzunluğu türünün parçası olan sabit boyutlu bir veri yapısıdır. Go’da [3]int ile [4]int farklı türlerdir. Yani derleyici için “3 elemanlı int dizisi” ile “4 elemanlı int dizisi” aynı ailenin kuzenleri bile değildir; tamamen ayrı kimliklere sahiptir.

Dilim ise kendi başına veriyi doğrudan taşımaz. Arkasında genellikle bir dizi bulunur ve dilim bu dizinin belirli bir aralığına referans verir. Bir slice üç parçalı küçük bir başlık gibi düşünülebilir:

• işaretçi: alttaki dizide başlangıç konumu,
• uzunluk: şu an görünen eleman sayısı,
• kapasite: başlangıçtan itibaren kullanılabilecek maksimum alan.

Matematiksel olarak temel kural şudur: $0 \le len(slice) \le cap(slice)$. Yani uzunluk kapasiteyi aşamaz; ama append ile kapasite yetmezse Go yeni ve daha büyük bir alttaki dizi ayırabilir.

Diziler: Sabit Boyutlu Disiplin

Diziler, özellikle boyutun kesin bilindiği durumlarda harikadır. Örneğin RGB renk değeri için [3]uint8 gayet anlamlıdır. Çünkü kırmızı, yeşil ve mavi olmak üzere tam üç kanal vardır; dördüncü eleman beklenmez.

func updateArray(a [3]int) {
    a[0] = 99
}

func main() {
    nums := [3]int{1, 2, 3}
    updateArray(nums)
    println(nums[0]) // 1
}

Bu örnekte updateArray fonksiyonuna dizi gönderildiğinde tüm dizi kopyalanır. Fonksiyon içindeki değişiklik dışarıdaki nums dizisini etkilemez. Bu davranış güvenlidir ama büyük dizilerde maliyetli olabilir. Eğer $n$ elemanlı bir dizi kopyalanıyorsa işlem maliyeti yaklaşık $O(n)$ olur.

Dilimler: Esnek ve Paylaşımcı Pencereler

Dilimlerde durum daha hareketlidir. Slice değeri kopyalansa bile alttaki dizi çoğu zaman aynı kalır. Bu yüzden bir fonksiyona slice gönderdiğinizde eleman değişiklikleri dışarıdan görülebilir.

func updateSlice(s []int) {
    s[0] = 99
}

func main() {
    nums := []int{1, 2, 3}
    updateSlice(nums)
    println(nums[0]) // 99
}

Burada s aslında slice başlığının kopyasıdır; fakat başlığın gösterdiği alttaki dizi aynıdır. Bu nedenle s[0] = 99, orijinal veriyi değiştirir. İşte slice’ların “referans gibi davranıyor” denmesinin sebebi budur. Tam anlamıyla referans türü demek yerine, “referans taşıyan küçük bir descriptor” demek daha doğrudur.

Append ve Kapasite Sürprizi

Slice’ların en eğlenceli tarafı append ile büyüyebilmesidir; ama burada küçük bir numara vardır. Kapasite yetiyorsa aynı alttaki dizi kullanılır. Yetmiyorsa yeni bir dizi oluşturulur ve elemanlar oraya taşınır.

func main() {
    a := []int{10, 20, 30}
    b := a[:2]

    b = append(b, 99)

    println(a[2]) // kapasite yeterse 99 olabilir
}

Bu örnekte b, a dizisinin ilk iki elemanını gösterir. Eğer b için kapasite yeterliyse append, üçüncü konuma 99 yazar ve a[2] de değişmiş gibi görünür. Bu, slice paylaşımının hem süper gücü hem de potansiyel tuzağıdır.

Ne Zaman Hangisi?

Boyut gerçekten sabitse ve bu bilgi programın anlamının parçasıysa array iyi seçimdir. Örneğin matris boyutu, kriptografik bloklar veya sabit protokol alanları buna uygundur. Ancak çoğu uygulama kodunda veri miktarı çalışma zamanında değişir: kullanıcı listeleri, dosyadan okunan satırlar, API sonuçları… Bu durumda slice çok daha pratiktir.

Kısa özetle: array, bellekte düzenli ve sabit bir apartman; slice ise bu apartmanın odalarına bakan esnek bir emlak danışmanıdır. Danışman hafiftir, kolay kopyalanır; ama hangi odayı gösterdiğini unutursanız yanlış duvarı boyayabilirsiniz. Go’da güçlü ve hatasız kod yazmanın yolu, bu küçük pencerenin arkasındaki büyük diziyi her zaman akılda tutmaktan geçer.