Web Geliştiricilerinin Yaptığı En Yaygın 10 Hata: Geliştiriciler İçin Bir Eğitim

World Wide Web terimi 1990'da ortaya çıktığından beri, web uygulaması geliştirme, statik HTML sayfaları sunmaktan tamamen dinamik, karmaşık iş uygulamalarına dönüşmüştür.

Bugün, her türlü farklı web uygulamasını geliştirme konusunda adım adım talimatlar sağlayan binlerce dijital ve basılı kaynağımız var. Geliştirme ortamları, ilk geliştiricilerin düzenli olarak mücadele ettiği birçok hatayı yakalayıp düzeltecek kadar "akıllı"dır. Basit statik HTML sayfalarını kolayca yüksek düzeyde etkileşimli uygulamalara dönüştüren birçok farklı geliştirme platformu bile var.

Tüm bu geliştirme kalıpları, uygulamaları ve platformları ortak bir zemini paylaşır ve tümü, web uygulamalarının doğasından kaynaklanan benzer web geliştirme sorunlarına eğilimlidir.

Bu web geliştirme ipuçlarının amacı, web geliştirme sürecinin farklı aşamalarında yapılan bazı yaygın hatalara ışık tutmak ve daha iyi bir geliştirici olmanıza yardımcı olmaktır. Doğrulama, güvenlik, ölçeklenebilirlik ve SEO gibi neredeyse tüm web geliştiricilerinde ortak olan birkaç genel konuya değindim. Elbette bu kılavuzda anlattığım belirli örneklere bağlı kalmamalısınız, çünkü bunlar yalnızca karşılaşabileceğiniz olası sorunlar hakkında size bir fikir vermek için listelenmiştir.

Yaygın Hata No. 1: Eksik Girdi Doğrulaması

İstemci ve sunucu tarafında kullanıcı girdisini doğrulamak sadece bir zorunluluktur ! "Kullanıcı girdilerine güvenmeyin" bilgece tavsiyesinin hepimiz farkındayız, ancak yine de doğrulamadan kaynaklanan hatalar çok sık oluyor.

Bu hatanın en yaygın sonuçlarından biri, her yıl OWASP Top 10'da yer alan SQL Injection'dır .

Çoğu ön uç geliştirme çerçevesinin, kullanımı inanılmaz derecede basit olan, kullanıma hazır doğrulama kuralları sağladığını unutmayın. Ek olarak, çoğu büyük arka uç geliştirme platformu, gönderilen verilerin beklenen kurallara uyduğundan emin olmak için basit açıklamalar kullanır. Doğrulamayı uygulamak zaman alıcı olabilir, ancak standart kodlama uygulamanızın bir parçası olmalı ve asla bir kenara bırakılmamalıdır.

Yaygın Hata No. 2: Uygun Yetki Olmadan Kimlik Doğrulama

Devam etmeden önce, bu iki terim üzerinde uyumlu olduğumuzdan emin olalım. En Yaygın 10 Web Güvenlik Zafiyetinde belirtildiği gibi:

Kimlik Doğrulama: Bir kişinin güvenlik kimlik bilgilerini (parola, güvenlik sorularının yanıtları, parmak izi taraması vb.) doğru bir şekilde sağladığı için belirli bir kullanıcı olduğunun (veya en azından öyle göründüğünün) doğrulanması.

Yetkilendirme: Belirli bir kullanıcının belirli bir kaynağa erişimi olduğunu veya belirli bir eylemi gerçekleştirme izninin verildiğini onaylama.

Başka bir deyişle, kimlik doğrulama, bir varlığın kim olduğunu bilmek, yetkilendirme ise belirli bir varlığın neler yapabileceğini bilmektir.

Bu konuyu bir örnekle göstereyim:

Tarayıcınızın şu anda oturum açmış kullanıcı bilgilerini aşağıdakine benzer bir nesnede tuttuğunu düşünün:

 { username:'elvis', role:'singer', token:'123456789' }

Parola değişikliği yaparken, uygulamanız POST'u yapar:

 POST /changepassword/:username/:newpassword

/changepassword yönteminizde, kullanıcının oturum açtığını ve belirtecin süresinin dolmadığını doğrularsınız. Ardından :username parametresine göre kullanıcı profilini bulursunuz ve kullanıcı şifrenizi değiştirirsiniz.

Böylece, kullanıcınızın doğru bir şekilde oturum açtığını doğruladınız ve ardından isteğini yerine getirerek şifresini değiştirdiniz. İşlem tamam görünüyor, değil mi? Ne yazık ki, cevap hayır!

Bu noktada işlemi yapan kullanıcı ile şifresi değiştirilen kullanıcının aynı olduğunun doğrulanması önemlidir. Tarayıcıda saklanan herhangi bir bilgi üzerinde değişiklik yapılabilir ve herhangi bir ileri düzey kullanıcı, yerleşik tarayıcı araçları dışında başka bir şey kullanmadan username:'elvis' username:'Administrator' olarak kolayca güncelleyebilir.

Bu durumda, kullanıcının güvenlik kimlik bilgilerini sağladığından emin olmak için Authentication ile ilgilendik. Hatta /changepassword yönteminin yalnızca Authenticated kullanıcılar tarafından yürütülebileceğini doğrulamasını da ekleyebiliriz. Ancak bu yine de kullanıcılarınızı kötü niyetli girişimlerden korumak için yeterli değildir.

/changepassword yönteminizde gerçek istekte bulunanı ve isteğin içeriğini doğruladığınızdan ve kullanıcının yalnızca verilerini değiştirebildiğinden emin olarak istek için uygun Authorization uyguladığınızdan emin olmanız gerekir.

Authentication ve Authorization aynı madalyonun iki yüzüdür. Onlara asla ayrı davranmayın.

Yaygın Hata No. 3: Ölçeklendirmeye Hazır Değil

Günümüzün yüksek hızlı geliştirme, başlangıç ​​hızlandırıcıları ve harika fikirlerin anında küresel erişim dünyasında, MVP'nizi (minimum uygulanabilir ürün) mümkün olan en kısa sürede piyasaya sürmek birçok şirket için ortak bir hedeftir.

Ancak bu sürekli zaman baskısı, iyi web geliştirme ekiplerinin bile belirli sorunları gözden kaçırmasına neden oluyor. Ölçeklendirme genellikle ekiplerin hafife aldığı şeylerden biridir. MVP konsepti harika, ancak çok ileri iterseniz ciddi problemleriniz olur. Ne yazık ki, ölçeklenebilir bir veritabanı ve web sunucusu seçmek ve tüm uygulama katmanlarını bağımsız ölçeklenebilir sunucularda ayırmak yeterli değildir. Uygulamanızın önemli kısımlarını daha sonra yeniden yazmaktan kaçınmak istiyorsanız düşünmeniz gereken birçok ayrıntı vardır - bu da büyük bir web geliştirme sorunu haline gelir.

Örneğin, kullanıcılarınızın yüklenen profil resimlerini doğrudan bir web sunucusunda saklamayı seçtiğinizi varsayalım. Bu tamamen geçerli bir çözümdür—dosyalara uygulama tarafından hızlı bir şekilde erişilebilir, dosya işleme yöntemleri her geliştirme platformunda mevcuttur ve hatta bu görüntüleri statik içerik olarak sunabilirsiniz, bu da uygulamanızda minimum yük anlamına gelir.

Ancak uygulamanız büyüdüğünde ve bir yük dengeleyicinin arkasında iki veya daha fazla web sunucusu kullanmanız gerektiğinde ne olur? Veritabanı depolama alanınızı, oturum durumu sunucularınızı ve web sunucularınızı güzel bir şekilde ölçeklendirmiş olsanız bile, profil görüntüleri gibi basit bir şey nedeniyle uygulama ölçeklenebilirliğiniz başarısız olur. Bu nedenle, dosyaların web sunucularınıza yayılmasını sağlamak için bir tür dosya senkronizasyon hizmeti (gecikmeli ve geçici 404 hatalarına neden olacak) veya başka bir geçici çözüm uygulamanız gerekir.

Sorunu en başta önlemek için yapmanız gereken, yalnızca paylaşılan dosya depolama konumu, veritabanı veya başka herhangi bir uzak depolama çözümü kullanmaktı. Bunların hepsini uygulamak muhtemelen birkaç saatlik fazladan çalışmaya mal olacaktı, ama bu zahmete değecekti.

4 No'lu Genel Hata: Yanlış veya Eksik SEO

Web sitelerinde yanlış veya eksik SEO en iyi uygulamalarının temel nedeni yanlış bilgilendirilmiş “SEO uzmanları”dır. Birçok web geliştiricisi, SEO hakkında yeterince bilgi sahibi olduklarına ve bunun özellikle karmaşık olmadığına inanıyor, ancak bu doğru değil. SEO uzmanlığı, en iyi uygulamaları ve Google, Bing ve Yahoo'nun web'i nasıl endekslediğiyle ilgili sürekli değişen kuralları araştırmak için önemli ölçüde zaman harcamayı gerektirir. Sürekli deneyip doğru izleme + analiz yapmadığınız sürece bir SEO uzmanı değilsiniz ve öyle olduğunuzu iddia etmemelisiniz.

Ayrıca, SEO, sonunda yapılan bir aktivite olarak çok sık ertelenir. Bu, web geliştirme sorunlarının yüksek bir fiyatıyla gelir. SEO sadece iyi içerik, etiketler, anahtar kelimeler, meta veriler, resim alt etiketleri, site haritası vb. ayarlamakla ilgili değildir. Aynı zamanda yinelenen içeriğin ortadan kaldırılmasını, taranabilir site mimarisine sahip olmayı, verimli yükleme sürelerini, akıllı geri bağlantı kurmayı vb. içerir.

Ölçeklenebilirlikte olduğu gibi, web uygulamanızı oluşturmaya başladığınız andan itibaren SEO hakkında düşünmelisiniz veya SEO uygulama projenizi tamamlamanın tüm sisteminizi yeniden yazmak anlamına geldiğini görebilirsiniz.

5 No'lu Ortak Hata: İstek İşleyicilerde Zaman veya İşlemci Harcama Eylemleri

Bu hatanın en iyi örneklerinden biri, bir kullanıcı işlemine dayalı olarak e-posta göndermektir. Geliştiriciler genellikle bir SMTP araması yapmanın ve doğrudan kullanıcı istek işleyicisinden bir mesaj göndermenin çözüm olduğunu düşünür.

Diyelim ki bir çevrimiçi kitapçı kurdunuz ve günlük birkaç yüz siparişle başlamayı umuyorsunuz. Sipariş alım sürecinizin bir parçası olarak, bir kullanıcı her sipariş gönderdiğinde onay e-postaları gönderirsiniz. Bu ilk başta sorunsuz çalışacak, ancak sisteminizi ölçeklendirdiğinizde ve aniden onay e-postaları gönderen binlerce istek aldığınızda ne olur? Ya SMTP bağlantı zaman aşımları alırsınız, kota aşılır ya da artık kullanıcılar yerine e-postaları ele aldığı için uygulama yanıt süreniz önemli ölçüde düşer.

HTTP isteklerinizi mümkün olan en kısa sürede serbest bırakırken, herhangi bir zaman veya işlemci tüketen eylem, harici bir işlem tarafından gerçekleştirilmelidir. Bu durumda, siparişleri alan ve bildirim gönderen harici bir posta hizmetiniz olmalıdır.

6 No'lu Genel Hata: Bant Genişliği Kullanımını Optimize Etmemek

Çoğu geliştirme ve test, yerel bir ağ ortamında gerçekleşir. Bu nedenle, her biri 3MB veya daha fazla olan 5 arka plan görüntüsü indirirken, geliştirme ortamınızda 1Gbit bağlantı hızıyla ilgili bir sorun tespit edemeyebilirsiniz. Ancak kullanıcılarınız akıllı telefonlarına 3G bağlantıları üzerinden 15 MB'lık bir ana sayfa yüklemeye başladığında, kendinizi bir şikayet ve sorun listesine hazırlamalısınız.

Bant genişliği kullanımınızı optimize etmek size harika bir performans artışı sağlayabilir ve bu artışı elde etmek için muhtemelen yalnızca birkaç numaraya ihtiyacınız vardır. Aşağıdakiler de dahil olmak üzere birçok iyi web geliştiricisinin varsayılan olarak yaptığı birkaç şey vardır:

1. Tüm JavaScript'in küçültülmesi
2. Tüm CSS'lerin küçültülmesi
3. Sunucu tarafı HTTP sıkıştırması
4. Görüntü boyutu ve çözünürlüğünün optimizasyonu

7 No'lu Ortak Hata: Farklı Ekran Boyutları İçin Geliştirmemek

Duyarlı tasarım, son birkaç yılda büyük bir konu olmuştur. Akıllı telefonların farklı ekran çözünürlüklerine sahip olması, birçok web geliştirme sorunuyla birlikte gelen çevrimiçi içeriğe erişmenin birçok yeni yolunu getirdi. Akıllı telefonlardan ve tabletlerden gelen web sitesi ziyaretlerinin sayısı her geçen gün artıyor ve bu trend hızlanıyor.

Sorunsuz gezinme ve web sitesi içeriğine erişim sağlamak için, kullanıcıların her tür cihazdan içeriğe erişmesini sağlamalısınız.

Duyarlı web uygulamaları oluşturmak için çok sayıda model ve uygulama vardır. Her geliştirme platformunun kendi ipuçları ve püf noktaları vardır, ancak platformdan bağımsız bazı çerçeveler vardır. En popüler muhtemelen Twitter Bootstrap. Her büyük geliştirme platformu tarafından benimsenen açık kaynaklı ve ücretsiz bir HTML, CSS ve JavaScript çerçevesidir. Uygulamanızı oluştururken Bootstrap kalıplarına ve uygulamalarına bağlı kalın ve hiçbir sorun yaşamadan duyarlı web uygulamasına sahip olacaksınız.

Genel Hata No. 8: Tarayıcılar Arası Uyumsuzluk

Geliştirme süreci çoğu durumda ağır bir zaman baskısı altındadır. Her uygulamanın mümkün olan en kısa sürede piyasaya sürülmesi gerekir ve iyi web geliştiricileri bile genellikle tasarım yerine işlevsellik sunmaya odaklanır. Çoğu geliştiricinin Chrome, Firefox, IE yüklü olmasına rağmen, zamanın %90'ında bunlardan yalnızca birini kullanıyorlar. Geliştirme sırasında bir tarayıcı kullanmak yaygın bir uygulamadır ve uygulama tamamlanmak üzereyken onu diğer tarayıcılarda test etmeye başlayacaksınız. Bu, bu aşamada ortaya çıkan sorunları test etmek ve düzeltmek için çok zamanınız olduğunu varsayarsak, bu tamamen mantıklıdır.

Ancak, uygulamanız tarayıcılar arası test aşamasına ulaştığında size önemli ölçüde zaman kazandırabilecek bazı web geliştirme ipuçları vardır:

1. Geliştirme sırasında tüm tarayıcılarda test etmeniz gerekmez; zaman alıcı ve etkisizdir. Ancak bu, tarayıcıları sık sık değiştiremeyeceğiniz anlamına gelmez. Birkaç günde bir farklı bir tarayıcı kullanın ve en azından geliştirme aşamasının başlarında büyük sorunları fark edeceksiniz.
2. Bir tarayıcıyı desteklememeyi haklı çıkarmak için istatistikleri kullanırken dikkatli olun. Yeni yazılımı benimsemede veya yükseltmede yavaş olan birçok kuruluş var. Orada çalışan binlerce kullanıcının hala uygulamanıza erişmesi gerekebilir ve dahili güvenlik ve iş politikaları nedeniyle en son ücretsiz tarayıcıyı yükleyemezler.
3. Tarayıcıya özel kodlardan kaçının. Çoğu durumda, tarayıcılar arası uyumlu zarif bir çözüm vardır.

9 No'lu Ortak Hata: Taşınabilirliği Planlamamak

Varsayım, tüm sorunların anasıdır! Taşınabilirlik söz konusu olduğunda, bu söz her zamankinden daha doğru. Web geliştirmede, sabit kodlanmış dosya yolları, veritabanı bağlantı dizeleri veya belirli bir kitaplığın sunucuda bulunacağına dair varsayımlar gibi sorunları kaç kez gördünüz? Üretim ortamının yerel geliştirme bilgisayarınızla eşleşeceğini varsaymak tamamen yanlıştır.

İdeal uygulama kurulumu bakım gerektirmemelidir:

1. Uygulamanızın ölçeklenebildiğinden ve yük dengeli birden çok sunucu ortamında çalıştığından emin olun.
2. Basit ve net yapılandırmaya izin verin – muhtemelen tek bir yapılandırma dosyasında.
3. Web sunucusu yapılandırması beklendiği gibi olmadığında istisnaları işleyin.

10 Numaralı Ortak Hata: RESTful Anti Patterns

RESTful API'ler web geliştirmede yerlerini aldılar ve burada kalacaklar. Hemen hemen her web uygulaması, ister dahili kullanım için isterse harici sistemle entegre olsun, bir tür REST hizmeti uygulamıştır. Ancak yine de, beklenen uygulamalara uymayan bozuk RESTful kalıpları ve hizmetleri görüyoruz.

RESTful API yazarken yapılan en yaygın hatalardan ikisi şunlardır:

1. Yanlış HTTP fiilleri kullanmak. Örneğin, veri yazmak için GET kullanmak. HTTP GET, yetersiz ve güvenli olacak şekilde tasarlanmıştır, yani aynı kaynak üzerinde GET'i kaç kez çağırırsanız çağırın, yanıt her zaman aynı olmalıdır ve uygulama durumunda hiçbir değişiklik olmamalıdır.

2. Doğru HTTP durum kodlarını göndermiyor. Bu hataya en iyi örnek, yanıt kodu 200 ile hata mesajları göndermektir.

    HTTP 200 OK { message:'there was an error' }

Yalnızca istek bir hata oluşturmadığında HTTP 200 OK göndermelisiniz. Bir hata durumunda 400, 401, 500 veya oluşan hataya uygun başka bir durum kodu göndermelisiniz.

Standart HTTP durum kodlarına ayrıntılı bir genel bakış burada bulunabilir.

Sarmak

Web geliştirme, bir web sitesinin, web hizmetinin veya karmaşık web uygulamasının geliştirilmesini yasal olarak kapsayabilen son derece geniş bir terimdir.

Bu web geliştirme kılavuzunun ana çıkarımı, kimlik doğrulama ve yetkilendirme konusunda her zaman dikkatli olmanız, ölçeklenebilirlik için plan yapmanız ve hiçbir zaman aceleyle hiçbir şey üstlenmemeniz veya uzun bir web geliştirme sorunları listesiyle uğraşmaya hazır olmanız gerektiğini hatırlatmasıdır!