Hangi teknolojiyi neden seçtiğimizi, bir projeye uygun altyapıya nasıl karar verdiğimizi ve kodun uzun ömürlü olmasını nasıl sağladığımızı anlatıyoruz.
Bir projede kullanılacak teknolojiyi seçerken sorduğumuz ilk soru "hangisi daha yeni" değil, "bu iş beş yıl sonra kim tarafından, hangi maliyetle bakılacak" oluyor. Kurumsal bir web sitesinin ortalama ömrü üç ilâ beş yıl; bir yönetim panelinin ömrü çoğu zaman daha uzun. Bu süre boyunca altyapının güncellenebilir, güvenlik yamalarının takip edilebilir ve ekibin değişmesi hâlinde devredilebilir olması gerekiyor.
Bu yüzden tercihlerimizi üç ölçüte göre yapıyoruz. Birincisi olgunluk: aracın kararlı bir sürüm geçmişi ve öngörülebilir bir yayın takvimi olmalı. İkincisi ekosistem: sorun yaşandığında çözümün aranabileceği geniş bir topluluk ve yeterli belgelendirme bulunmalı. Üçüncüsü devredilebilirlik: piyasada o teknolojiyi bilen geliştirici bulmak zor olmamalı. Bu üç ölçütü karşılamayan bir araç teknik olarak ne kadar zarif olursa olsun müşteri projesinde kullanmıyoruz.
Hayır. İşin niteliği altyapıyı belirliyor. İçerik ağırlıklı, sık güncellenen ve arama motoru görünürlüğü kritik olan bir kurumsal sitede sunucu tarafında oluşturulan sayfalar (SSR) ya da klasik sunucu taraflı bir yapı genellikle en doğru seçim oluyor; bu yapılar hem ilk yükleme süresini kısaltıyor hem de arama motorlarının içeriği sorunsuz görmesini sağlıyor.
Yoğun etkileşim içeren, kullanıcı oturumuna bağlı çalışan panel ve uygulamalarda ise bileşen tabanlı bir ön yüz çatısı kullanmak mantıklı hâle geliyor. Filtreleme, sürükle-bırak, canlı doğrulama, çok adımlı formlar gibi ekranlarda bu yaklaşım hem geliştirme süresini kısaltıyor hem de kullanıcı deneyimini iyileştiriyor.
Ara bir durum da var: içeriğin ağırlıkta olduğu ama belirli bölümlerinin etkileşimli olması gereken projeler. Bu tür işlerde sayfanın tamamını istemci tarafına taşımak yerine yalnızca etkileşimli bölümü ayrı bir bileşen olarak çalıştırıyoruz. Böylece gereksiz JavaScript yükünden kaçınıyoruz.
Site hızı yayın sonrası eklenen bir iyileştirme değil, mimari bir karardır. Sayfa yapısı yanlış kurulduğunda sonradan yapılan optimizasyonlar ancak sınırlı kazanç sağlar. Bu yüzden performansı geliştirme sırasında ölçüyoruz.
Somut olarak takip ettiğimiz metrikler Core Web Vitals kümesinde toplanıyor: LCP (en büyük içerik ögesinin görünme süresi), INP (etkileşime yanıt süresi) ve CLS (görsel kayma miktarı). Bu değerleri hem laboratuvar ölçümüyle hem de yayın sonrası saha verisiyle izliyoruz; ikisi farklı sonuç verdiğinde gerçek kullanıcı verisini esas alıyoruz.
Pratikte en çok işe yarayan müdahaleler şunlar oluyor: görsellerin modern biçimlerde ve doğru boyutlarda sunulması, ekranın üst kısmında görünmeyen içeriklerin geciktirilerek yüklenmesi, yazı tiplerinin yükleme davranışının düzenlenmesi, gereksiz üçüncü taraf betiklerinin kaldırılması ve veri tabanı sorgularının azaltılması. Bu maddelerin çoğu görsel tasarımdan ödün vermeden uygulanabiliyor.
Veri modeli, bir projede sonradan değiştirilmesi en pahalı kısımdır. Bu yüzden geliştirmeye başlamadan önce varlıkları, ilişkileri ve büyüme senaryolarını yazıya döküyoruz. İlişkisel yapıların çoğu proje için doğru seçim olduğunu düşünüyoruz; ilişkisel bir veri tabanının sağladığı bütünlük kuralları, uygulama katmanında elle yazılan kontrollerden çok daha güvenilir.
Yoğun okuma yapılan ekranlarda önbellekleme katmanı ekliyoruz. Önbelleği baştan değil, ölçüm sonrası ekliyoruz: hangi sorgunun gerçekten pahalı olduğunu tahmin etmek yerine ölçmek, gereksiz karmaşıklıktan koruyor.
Güvenlik bir modül değil, geliştirme boyunca tekrarlanan bir dizi alışkanlık. Uyguladığımız temel maddeler şunlar:
Ayrıca yetkilendirme kurallarını arayüzde gizlemekle yetinmiyoruz. Bir kullanıcının görmemesi gereken bir ekranın menüde görünmemesi yeterli değildir; adres doğrudan yazıldığında da erişimin engellenmesi gerekir. Testlerimizde bu senaryoyu ayrıca deniyoruz.
Sürdürülebilirliğin en somut göstergesi, projeye sonradan katılan bir geliştiricinin ilk katkısını ne kadar sürede yapabildiğidir. Bunu kolaylaştırmak için birkaç alışkanlığımız var: klasör yapısı projeler arasında tutarlıdır, iş mantığı arayüz kodundan ayrılır, tekrar eden yapılar bileşene dönüştürülür ve kurulum adımları depo içinde belgelenir.
Sürüm kontrolünde her değişiklik ayrı bir dalda geliştirilir ve birleştirme öncesi başka bir geliştirici tarafından gözden geçirilir. Otomatik iş akışları (CI) her değişiklikte biçim kontrolü, statik analiz ve varsa testleri çalıştırır. Bu adımlar hatasız kod üretmiyor, ama aynı hatanın ikinci kez üretilmesini büyük ölçüde engelliyor.
Yapay zekâ destekli kod tamamlama ve içerik üretim araçlarını günlük işlerde kullanıyoruz; bunu gizlemenin bir anlamı yok. Ancak iki kuralımız var: üretilen hiçbir kod gözden geçirilmeden depoya girmiyor ve müşteri verisi genel amaçlı servislere aktarılmıyor.
Arama tarafında ise durum değişiyor. Kullanıcıların bir bölümü artık sorularını doğrudan yapay zekâ tabanlı yanıt motorlarına soruyor. Bu motorların içeriği alıntılayabilmesi için sayfanın net bir yapıda olması, sorulara doğrudan yanıt vermesi ve yapısal veri (schema.org) ile desteklenmesi gerekiyor. Bu nedenle içerik yapısını hem klasik arama sonuçlarını hem de yanıt motorlarını gözeterek kuruyoruz.
Her dış servis bir bağımlılıktır ve her bağımlılığın bir maliyeti vardır: aylık ücret, kesinti riski, veri paylaşımı ve gelecekte fiyat değişikliği. Bu yüzden dış servis eklemeden önce iki soruyu soruyoruz: bu işi kendimiz yazsak kaç günde biter ve servis yarın kapansa ne olur.
Basit işler için dış servis kullanmıyoruz. Buna karşılık ödeme altyapısı, e-posta gönderimi, harita ve bildirim servisleri gibi alanlarda kendi çözümümüzü yazmak hem gereksiz hem riskli; bu konularda yerleşik sağlayıcıları tercih ediyoruz.
Kullandığımız her dış servisi, değiştirilebilir olacak şekilde soyutluyoruz. Örneğin e-posta gönderimi doğrudan sağlayıcının kütüphanesiyle değil, kendi arayüzümüz üzerinden yapılıyor; sağlayıcı değiştiğinde tek bir sınıf değişiyor, uygulamanın geri kalanı etkilenmiyor. Kullanılan servislerin listesi ve aylık maliyetleri devir teslim belgesinde yazılı olarak size iletiliyor.
Geliştirme ortamında çalışan bir özelliğin canlıda bozulması, çoğu zaman ortamlar arasındaki farklardan kaynaklanır: farklı sürümler, farklı ayarlar, farklı veri hacimleri. Bu farkları en aza indirmek için ortamları kapsayıcı yapılarla kuruyoruz; geliştirme, staging ve canlı aynı yapılandırmadan üretiliyor.
Veri hacmi farkı ayrı bir konu. Yüz kayıtla çalışan bir ekran, yüz bin kayıtla tamamen farklı davranabiliyor. Bu yüzden performans açısından kritik ekranları gerçekçi hacimde test verisiyle deniyoruz. Test verisi gerçek kişisel veri içermiyor; üretilmiş veya maskelenmiş veri kullanıyoruz.
Yayına alma adımlarını da elle yapılan işlem olmaktan çıkarıyoruz. Otomatik iş akışları sayesinde aynı adımlar her seferinde aynı sırayla çalışıyor. Elle yapılan her adım er ya da geç unutuluyor; bu, deneyimle öğrenilmiş bir kural.
