Günlerinizi kod yazarak geçiriyorsanız, saatlerinizi iki ortam içinde geçirirsiniz: çalışmanızın gerçekte çalıştığı tarayıcı penceresi ve oraya ulaşmak için verdiğiniz her kararı hatırlayan Git deposu. Biri kamuya açık ve öngörülemez, diğeri ise özel ve titizdir. Her ikisini de anlamak bir seçenek değil, zorunluluktur. Tarayıcının dahili mekanizmasına ve Git'in staging mantığına hakim olmak, tahmin yürüten geliştiricileri, bir şeyin neden bozulduğunu ve ne zaman değiştiğini tam olarak bilen geliştiricilerden ayırır.

URL Anatomisi

Her web sitesi ziyareti, basit görünen ancak kesin talimatlar taşıyan bir karakter dizisiyle başlar. https://shop.example.com:443/products/id/42?sort=price#reviews gibi bir URL, aslında ayrık talimatlar yığınıdır.

Protokol en başta yer alır ve iletişimin kurallarını belirler. https:// gördüğünüzde, tarayıcı herhangi bir şey göndermeden önce bağlantıyı şifrelemesi gerektiğini bilir. Alan adı (shop.example.com), sunucunun gerçek ağ adresinin insan tarafından okunabilir adıdır. Bilgisayarınızın nereye vuracağını bilmesi için DNS üzerinden çözümlenir. Port (:443), o sunucudaki belirli kapıdır. Tarayıcılar HTTPS için 443'ü, HTTP için 80'i varsaydığından genellikle görünmezdir ancak mekanizmanın içinde her zaman oradadır. Yol (/products/id/42), klasörler gibi düzenlenmiş şekilde sunucuya hangi kaynağı istediğinizi söyler. Sorgu dizisi (?sort=price), filtreler, arama terimleri veya sayfalama için mükemmel olan dinamik verileri anahtar-değer çiftleri olarak iletir. Son olarak, fragman (#reviews) sayfadaki belirli bir öğe kimliğine (ID) işaret eder. Sunucuya asla ulaşmaz; tarayıcı, sayfa geldikten sonra bunu tamamen istemci tarafında işler.

Fragmanı sonda tutun. Eğer sorgu dizisinden önceye taşırsanız bağlantıyı bozarsınız; çünkü diyez işaretinden sonra gelen her şey sunucu talimatı olarak değil, istemci tarafı bağlamı olarak kabul edilir.

DOM: Sayfanızın Canlı Sinir Sistemi

Kablo üzerinden gelen HTML sadece metindir. Tarayıcı bu metni okur ve düğümler (nodes) adı verilen nesnelerden oluşan, canlı ve ağaç yapısında bir harita olan Document Object Model'i (DOM) oluşturur. Element etiketleri element düğümlerine dönüşür. Etiketler arasındaki metinler metin düğümleri olur. Özniteliklerin ve yorumların bile kendi düğüm türleri vardır. Bu ağaç statik bir diyagram değildir. JavaScript'in anında okuyabileceği ve yeniden yazabileceği canlı bir veri yapısıdır.

Betiğiniz document.getElementById çalıştırdığında veya bir className değerini değiştirdiğinde, bu ağaca ulaşıyor ve onu değiştiriyorsunuz. Tarayıcı bunu fark eder ve sunucudan yeni bir sayfa istemeden ekranı yeniden boyar. Modern web uygulamalarını mümkün kılan güç budur, ancak bir maliyeti vardır. DOM'a her dokunduğunuzda, tarayıcı düzeni ve stilleri yeniden hesaplayabilir. Bunu yüzlerce öğenin bulunduğu sık bir döngü içinde yaparsanız, kare hızınız (frame rate) dibe vurur. Uzun bir liste eklemeniz gerekiyorsa, önce bellekte bir DocumentFragment oluşturun ve ardından onu tek seferde ekleyin. Okuma ve yazma işlemlerinizi toplu halde yapın. DOM dayanıklıdır ancak bedava değildir.

Tarayıcı Depolama: Üç Araç, Üç Görev

Modern tarayıcılar, verileri doğrudan kullanıcının makinesinde depolamanıza olanak tanır ve doğru mekanizmayı seçmek önemlidir, çünkü her biri farklı bir ömür ve kapasite için tasarlanmıştır.

LocalStorage en basit olanıdır. Kodunuz veya kullanıcı silene kadar küçük miktardaki dize verilerini kalıcı olarak saklar. Klasik bir kullanım durumu karanlık mod tercihidir. Birisi anahtarı değiştirdiğinde LocalStorage'a "theme": "dark" yazın. Bir sonraki ziyarette, bunu geri okuyun ve ilk boyamadan (paint) önce sınıfı uygulayın. Senkrondur ve kökenle (origin) sınırlıdır; bu onu kolaylaştırır ancak içine asla hassas jetonlar (tokens) bırakmamanız gerektiği anlamına da gelir. Sayfanızda çalışan herhangi bir betik bunu okuyabilir.

SessionStorage aynı anahtar-değer API'sini kullanır, ancak ömrü tarayıcı sekmesine bağlıdır. Sayfa yenilemelerinde veriler korunur, bu da onu geçici form ilerlemeleri için mükemmel kılar. Bir kullanıcının uzun bir anket doldurduğunu, yanlışlıkla sayfayı yenilediğini ve verileri SessionStorage'a sakladığınız için yanıtlarını hala gördüğünü hayal edin. Sekmeyi kapattıklarında, veriler otomatik olarak temizlenir.

Cache API farklı bir ölçekte çalışır. İstek ve yanıt çiftlerini depolar; genellikle service worker'lar tarafından resimler, yazı tipleri ve script paketleri gibi büyük statik varlıkları tutmak için kullanılır. Her ziyarette aynı ana görseli (hero image) veya React paketini ağ üzerinden çekmek yerine, uygulamanız bunu doğrudan disk önbelleğinden sunabilir. Çevrimdışı çalışabilen sitelerin tekrarlanan ziyaretlerde anında yüklenmesinin yolu budur. Diğer ikisi gibi genel bir anahtar-değer deposu değildir; doğrudan HTTP yanıtları için özel olarak tasarlanmıştır.

Bir katı kural: Kimlik doğrulama token'larını veya kişisel tanımlayıcıları asla LocalStorage'da saklamayın. XSS saldırıları bunları milisaniyeler içinde ele geçirebilir. Hassas her şey için HttpOnly, Secure, SameSite çerezlerini kullanın ve bu bayrakların (flags) gerçekten ayarlandığını doğrulayabileceğiniz Application sekmesinden bunları inceleyin.

Tarayıcı DevTools: Tahmin Etmeyi Bırakın, Okumaya Başlayın

DevTools paneli sadece konsoldaki kırmızı hataları düzeltmek için değildir. Tarayıcı içinde gerçekleşen her şey için sizin tanı laboratuvarınızdır.

Elements panelinde, DOM ağacının üzerine gelerek düğümlerin (nodes) sayfada gerçek zamanlı olarak vurgulandığını izleyebilirsiniz. Kaynak kodunuza dokunmadan önce bir kenar boşluğunu (margin) veya rengi test etmek için CSS değerlerini doğrudan Styles bölmesinde düzenleyebilirsiniz. Console sizin karalama defterinizdir. Nesneleri loglayın, regex test edin veya mevcut sayfa durumuna karşı canlı olarak fonksiyonları çağırın. Eğer bir değişken beklenen gibi davranmıyorsa, adını yazın ve doğrudan inceleyin.

Network sekmesi performans hakkındaki gerçekleri ortaya çıkarır. O yavaş sayfa JavaScript'inizden kaynaklanmıyor olabilir. Yanıt vermesi dört saniye süren üçüncü taraf bir yazı tipi veya hiç sıkıştırmadığınız iki megabaytlık bir JSON veri yükü (payload) döndüren bir API uç noktası (endpoint) olabilir. Her isteğin tüm yaşam döngüsünü izleyebilir, kendi API çağrılarınızı görmek için Fetch/XHR ile filtreleyebilir ve önbelleğe alma direktiflerine uyulup uyulmadığını görmek için başlıkları (headers) inceleyebilirsiniz. Bu sırada, Application sekmesi depolama alanınızı denetlemenize olanak tanır. LocalStorage anahtar-değer çiftlerine göz atın, tekil çerezleri ve bayraklarını inceleyin ve service worker'ınızın gerçekten kayıtlı olup olmadığını ve beklediğiniz şeyi önbelleğe alıp almadığını doğrulayın.

Git İş Akışı: Üç Kova

Git bir yedekleme yazılımı değildir. Tarihi düzenlemek için bir araçtır. Bu şekilde düşünmek, onu nasıl kullandığınızı değiştirir. Git, projenizi üç farklı alan üzerinden yönetir.

working tree sizin dağınık masanızdır. Burada dosyaları düzenler, klasörleri siler ve deneyler yaparsınız. Henüz hiçbir şey güvende değildir. staging area veya index, bir sonraki anlık görüntüye (snapshot) neyin dahil edileceğini seçici olarak belirlediğiniz yerdir. Bir dosya üzerinde git add komutunu çalıştırmak, onu working tree'den staging alanına taşır. Bu size hassasiyet sağlar. On dosyayı değiştirebilir, bunlardan sadece üçünü stage edebilir ve gerçekten tek bir değişikliği tanımlayan temiz, mantıklı bir anlık görüntü (snapshot) commit edebilirsiniz. git commit komutunu çalıştırdığınızda, local repository anlık görüntüyü alır. O noktada Git, mesajınızla birlikte stage edilmiş dosyaların tam durumunu kaydeder ve daha sonra geri dönebileceğiniz kalıcı bir kontrol noktası (checkpoint) oluşturur.

Herhangi bir şeyi stage etmeden önce git status komutunu çalıştırın. Bu komut size takip edilmeyen (untracked) dosyaları ve unutmuş olabileceğiniz değiştirilmiş dosyaları gösterir. Bu kontrolü atlarsanız, geçici derleme çıktıları (build artifacts), günlük dosyaları veya ortam dosyaları commit'lerin içine sızabilir. Sağlam bir .gitignore dosyası yardımcı olur, ancak git status sizin son uçuş öncesi kontrolünüzdür.

Staging ayrıca hataları geçmişe dönüşmeden önce düzeltmenize olanak tanır. Bir dosyayı vaktinden önce eklediyseniz git restore --staged ile stage alanından çıkarın. Commit mesajınız çok belirsizse yeniden yazın. Staging alanı, tam olarak commit'lerinizin sadece öğle yemeğinden beri yaptığınız her tuş vuruşunun ham bir dökümü değil, tutarlı bir hikaye anlatması için vardır.

Hepsini Bir Araya Getirmek

Bu iki alan, tarayıcı ve Git, iş akışınızın neredeyse her saatini şekillendirir. Tarayıcıda, isteklerin nasıl çözümlendiğini, DOM'un script'lerinize nasıl tepki verdiğini ve verilerin istemcide (client) nerede bulunduğunu anlamanız gerekir. Sırları saklamak için LocalStorage'ı yanlış kullanmak veya DOM'u toplu olmayan (unbatched) güncellemelerle dövmek, kırılgan ve yavaş uygulamalar yaratır. Terminalinizde Git'e bir "kaydet" düğmesi gibi davranmak, gelecekteki haliniz de dahil olmak üzere hiç kimsenin okuyamayacağı bir geçmiş oluşturur. Staging alanını bilinçli kullanın. Durumunuzu (status) kontrol edin. Sadece "ne" olduğunu değil, "neden" olduğunu açıklayan commit'ler yazın.

Her iki dünyayı birbirine bağlayan alışkanlık incelemedir. API'yi suçlamadan önce URL'leri araştırın. Bir framework eklemeden önce DOM'u profilleyin. Daha büyük bir sunucu satın almadan önce Network sekmesini okuyun. Bir hatayı sabitlemeden önce git status komutunu gözden geçirin. Araçlar zaten ekranınızda açık. Onları dürüstçe okumayı öğrenmek asıl iştir.