2009’da web geliştirmeye başladığımda araçlar, bağlantı hızları ve kullanıcı beklentileri bugünkünden çok farklıydı. Değişmeyen şey, iyi bir dijital ürünün insanlara açık bir değer sunma zorunluluğu oldu.
Web sürekli değişen bir üretim ortamı
Tarayıcı yetenekleri büyüdü, mobil kullanım merkeze yerleşti, dağıtım saniyelere indi ve bugün yapay zekâ geliştirme sürecinin aktif bir parçası. Her dönem kendi araçlarını ve ezberlerini getirdi.
Bu hızın içinde her yeni teknolojiyi takip etmek mümkün değil. Daha verimli yaklaşım, temel web prensiplerini anlamak ve yeni araçları gerçek bir probleme sağladıkları katkıyla değerlendirmek.
Araçlar katmanlaştı, beklentiler yükseldi
İlk yıllarda bir web sitesini yayına almak çoğunlukla birkaç dosyayı sunucuya taşımak demekti. Bugün aynı iş; tasarım sistemi, içerik modeli, uygulama katmanı, API’ler, analitik, güvenlik, gözlemlenebilirlik ve dağıtım hattı gibi birçok karar içeriyor. Bu gelişme bize güçlü imkânlar verdi, fakat basit bir problemi gereğinden büyük bir teknik sisteme dönüştürme riskini de artırdı.
Kullanıcının beklentisi de araçlarla birlikte değişti. İnsanlar artık yalnızca çalışan bir sayfa değil; hızlı açılan, telefonda kusursuz davranan, güven veren ve ne yapacağını açıkça anlatan bir deneyim bekliyor. Teknik kalite görünmez olduğunda bile hissediliyor: bir formun doğru geri bildirim vermesi, geri tuşunun beklenen biçimde çalışması veya zayıf bağlantıda içeriğin erişilebilir kalması ürün algısını doğrudan etkiliyor.
Bu nedenle geliştirmeye bir teknoloji seçerek değil, sistemin sınırlarını çizerek başlamayı tercih ediyorum. İçerik ne kadar sık değişecek? Kim yönetecek? Kullanıcının kritik görevi ne? Ürün hangi hızda büyüyebilir? Bu sorular cevaplandığında teknoloji seçimi daha sakin ve daha isabetli hâle geliyor.
Bir teknolojinin yeni olması, ürün için doğru olduğu anlamına gelmez. Doğru seçim bağlama göre yapılır.
Kalıcı prensipler
Hız, erişilebilirlik, açık bilgi mimarisi ve güvenilirlik yıllardır iyi web deneyiminin temelini oluşturuyor. Kullanıcı ne yapacağını anlamıyorsa ya da sayfa yavaşsa kullanılan teknoloji yığınının ne kadar güncel olduğunun önemi azalıyor.
Basitlik, eksiklik değil tasarım kararıdır
Basit bir sistem her zaman az özellikli sistem değildir. Doğru soyutlamaların doğru zamanda yapılmasıdır. Bir bileşeni yalnızca ikinci kez kullanacağım diye genelleştirmek yerine, tekrarın gerçekten bir örüntüye dönüşmesini beklemek çoğu zaman daha sağlıklı sonuç verir. Erken soyutlama kodu kısaltabilir; fakat zihinsel yükü ve değişiklik maliyetini büyütebilir.
Aynı ilke kullanıcı arayüzünde de geçerli. Bir ekrana daha fazla seçenek koymak ürünü daha güçlü göstermeyebilir. Kullanıcının karar vermesi gereken noktaları azaltmak, ana eylemi görünür kılmak ve geri bildirimleri zamanında sunmak çoğu zaman yeni bir özellik eklemekten daha değerlidir.
- Önce içeriği ve kullanıcı görevini netleştirmek
- Performansı sonradan eklenecek özellik olarak görmemek
- Semantik HTML ve erişilebilirliği temelde çözmek
- Sistemi bakım yapacak kişiyi düşünerek geliştirmek
Bakım yapılabilirlik benim için yalnızca temiz kod değildir. Dosya adlarının anlaşılır olması, kararların belgelenmesi, hata mesajlarının tanı koymaya yardım etmesi ve yeni bir geliştiricinin sistemi korkmadan değiştirebilmesi de aynı konunun parçalarıdır. Bugün yazılan kodun gelecekte farklı bir kişi tarafından, farklı bir bağlamda okunacağını kabul etmek kaliteyi belirgin biçimde yükseltir.
En öğretici hatalar
Gereğinden fazla soyutlama yapmak, erken ölçeklenmeye çalışmak ve kullanıcı geri bildirimini geç almak sık karşılaştığım hatalar arasında. Teknik olarak zarif görünen çözüm, ürünün aşamasına uymuyorsa fazladan maliyet oluşturabiliyor.
Bir başka hata da tasarım, içerik ve yazılımı birbirinden bağımsız düşünmek. Oysa kullanıcı bunları tek bir deneyim olarak yaşıyor.
Yanlış problemi kusursuz çözmek
En pahalı hata çoğu zaman bozuk kod değil, kullanılmayan özelliği kusursuz geliştirmektir. Gereksinimi yalnızca toplantı notundan alıp doğrudan uygulamaya çevirmek kolaydır. Daha zor olan, talebin arkasındaki ihtiyacı sorgulamaktır. Kullanıcının söylediği çözüm ile yaşadığı problem aynı şey olmayabilir.
Bu yüzden belirsiz bir özelliği önce akış, prototip veya hatta manuel bir operasyonla test etmeyi önemsiyorum. Böyle bir test teknik borç üretmez; aksine yanlış yönde aylarca ilerleme riskini düşürür. Kod yazmamak da bazen iyi bir mühendislik kararıdır.
Performansı sona bırakmak
Performans sorunları genellikle tek bir büyük hatadan değil, küçük kararların birikmesinden doğar: gereksiz font ağırlıkları, ölçülmeden eklenen animasyonlar, büyük görseller, kullanılmayan paketler ve kontrolsüz üçüncü taraf betikleri. Ürün bittikten sonra bunları temizlemek, baştan bir bütçe belirlemekten daha maliyetlidir.
Ben performans bütçesini tasarım kısıtı olarak görüyorum. Hareketin amacı, görselin katkısı ve her dış bağımlılığın bedeli konuşulduğunda deneyim fakirleşmez; daha bilinçli hâle gelir.
Yeni geliştiricilere notlar
Temelleri öğrenin; fakat yalnızca teknoloji öğrenmekle kalmayın. Bir ürünün neden var olduğunu, kime değer sunduğunu ve nasıl sürdürülebilir olacağını anlamaya çalışın. Kod kalitesi kadar iletişim, merak ve problemi doğru tarif etme becerisi de kariyer boyunca değer üretir.
Küçük ama tamamlanmış ürünler geliştirin
Eğitimleri izlemek başlangıç için yararlı, fakat gerçek öğrenme bir şeyi sonuna kadar götürürken oluşuyor. Alan adı almak, dağıtım yapmak, hata kaydı okumak, gerçek bir kullanıcıdan geri bildirim almak ve bir sürümü geri çekmek; yalnızca kod yazarken görünmeyen birçok beceriyi geliştiriyor.
Küçük projelerde bile üretim disiplini kurun: anlamlı commit’ler, erişilebilir formlar, temel güvenlik kontrolleri, yedekleme planı ve kısa bir kullanım belgesi. Bunlar portföyde kullanılan kütüphanenin adından daha güçlü bir olgunluk sinyali verir.
Teknoloji kimliğiniz olmasın
Bir framework’ü iyi bilmek değerlidir; fakat kariyeri tek bir araca bağlamak kırılganlık yaratır. HTTP’yi, tarayıcıyı, veri modellemeyi, hata ayıklamayı ve kullanıcı arayüzü prensiplerini öğrenmek araçlar değiştiğinde ayakta kalan temeli oluşturur. Yeni bir teknolojiye geçerken de sıfırdan başlamazsınız; bildiğiniz prensipleri yeni sözdizimine taşırsınız.
Son olarak, yaptığınız işi anlatmayı öğrenin. Bir teknik kararı neden verdiğinizi, hangi alternatifi elemek zorunda kaldığınızı ve sonucun kullanıcıya ne kazandırdığını açıklayabilmek ekip çalışmasını güçlendirir. İyi geliştirici yalnızca çözüm üretmez; çözümün etrafında ortak anlayış da kurar.
Web’in en güçlü tarafı hâlâ açıklığı. Küçük bir fikir doğru biçimde geliştirildiğinde dünyanın her yerinden erişilebilir bir ürüne dönüşebilir.