Bir web uygulamasının programcısı, siteyi herkese açık hale getirmeden önce hangi teknik ayrıntıları dikkate almalıdır?


2187

Bir web uygulamasının teknik ayrıntılarını uygulayan bir programcı, siteyi herkese açık hale getirmeden önce nelere dikkat etmelidir? Eğer Jeff Atwood unutabilirsiniz HttpOnly çerezleri , site haritaları , ve çapraz site saldırılara aynı sitedeki tüm , ben de önemli olan şey unutmadan olabilir?

Bunu bir web geliştiricisinin bakış açısından düşünüyorum, öyle ki başkası site için asıl tasarım ve içeriği yaratıyor. Dolayısıyla, kullanılabilirlik ve içerik platformdan daha önemli olsa da, programcının bu konuda çok az söz sahibi sizsiniz. Endişelenmeniz gereken şey, platformun uygulanmasının kararlı olması, iyi performans göstermesi, güvenli olması ve diğer tüm iş hedeflerine uymasıdır (çok pahalı değil, inşa etmesi çok uzun sürdü ve Google’ın olduğu gibi sıralanıyor). içerik destekler).

Bunu, intranet tipi uygulamalar için oldukça güvenilir bir ortamda bazı çalışmalar yapan ve ilk büyük şansını tüm dünyaya yayılmış ağlar için potansiyel olarak popüler bir site ortaya çıkarmak üzere olan bir geliştirici perspektifinden düşünün.

Ayrıca, belirsiz bir "web standartları" yanıtından yalnızca daha belirgin bir şey arıyorum. Demek istediğim, HTML üzerinden JavaScript ve CSS üzerinden HTTP, özellikle de profesyonel bir web geliştiricisi olduğunuzu belirttiğimde hemen hemen belli. Öyleyse bunun ötesine geçip, hangi standartlar? Hangi durumlarda ve neden? Standardın özelliklerine bir link verin.

Yanıtlar:


2645

Buradaki fikir, çoğumuzun bu listede olanların çoğunu zaten bilmesi gerektiğidir . Ancak, daha önce hiç incelemediğiniz, tam olarak anlamadığınız veya hatta hiç duymadığınız bir veya iki öğe olabilir.

Arayüz ve Kullanıcı Deneyimi

  • Tarayıcıların standartları tutarsız bir şekilde uyguladıklarını ve sitenizin tüm büyük tarayıcılarda oldukça iyi çalıştığından emin olun. En son bir Gecko motoruna ( Firefox ), bir WebKit motoruna ( Safari ve bazı mobil tarayıcılar), Chrome'a , desteklenen IE tarayıcılarınıza ( Uygulama Uyumluluğu VPC Görüntülerinden yararlanın ) ve Opera'ya karşı minimum bir testte . Ayrıca tarayıcıların sitenizi farklı işletim sistemlerinde nasıl oluşturduğunu da göz önünde bulundurun .
  • İnsanların siteyi büyük tarayıcılardan başka nasıl kullanabileceğini düşünün: örneğin cep telefonları, ekran okuyucular ve arama motorları. - Bazı erişilebilirlik bilgisi: WAI ve Section508 , Mobil gelişimi: MobiForge .
  • Aşamalandırma: Kullanıcılarınızı etkilemeden güncellemeler nasıl dağıtılır? Mimaride, kodlamaya veya kapsamlı içeriğe yapılan değişiklikleri uygulamak ve bunların hiçbir şeyi bozmadan kontrollü bir şekilde dağıtılmasını sağlamak için bir veya daha fazla test veya hazırlık ortamı hazırlayın. Canlı siteye onaylanmış değişiklikleri dağıtmanın otomatik bir yolunu kullanın. Bu, bir sürüm kontrol sisteminin (git, Subversion vb.) Ve otomatik bir yapım mekanizmasının (Ant, NAnt, vb.) Kullanılmasıyla birlikte en etkili şekilde uygulanır.
  • Dostça olmayan hataları doğrudan kullanıcıya göstermeyin.
  • Kullanıcıların e-posta adreslerini, düz bir metne koymayın; çünkü ölümle spam gönderir.
  • İstenmeyen postalardan kaçınmak için özelliği rel="nofollow"kullanıcı tarafından oluşturulan bağlantılara ekleyin .
  • Sitenize iyi düşünülmüş limitler koyun - Bu aynı zamanda Güvenlik kapsamındadır.
  • Aşamalı geliştirmenin nasıl yapıldığını öğrenin .
  • Bir yenilemenin tekrar gönderilmesini önlemek için, bir POST başarılı olmuşsa, bir POST'dan sonra yönlendir .
  • Erişilebilirliği hesaba katmayı unutmayın. Bu her zaman iyi bir fikirdir ve bazı durumlarda yasal bir zorunluluktur . WAI-ARIA ve WCAG 2 bu alanda iyi kaynaklar.
  • Oku Beni Düşündürme .

Güvenlik

Verim

  • Gerekirse önbelleğe alma işlemini uygulayın, HTTP önbelleğe almanın yanı sıra HTML5 Manifest'i de uygun şekilde anlayın ve kullanın .
  • Görüntüleri optimize et - yinelenen bir arka plan için 20 KB görüntü kullanmayın.
  • Hız için içeriği sıkıştırın, bkz. Brotli , gzip / deflate ( deflate daha iyidir ).
  • Tarayıcı bağlantı sayısını azaltmak ve dosyalar arasındaki kopyaları sıkıştırmak için gzip özelliğini geliştirmek için birden çok stil sayfasını veya birden fazla komut dosyasını birleştirin / birleştirin.
  • Bir göz atın Yahoo Olağanüstü Performans sitesinde, ön uç performansı ve onların iyileştirilmesi dahil olmak üzere büyük kılavuzlar, çok sayıda YSlow aracını (Firefox, Safari, Chrome veya Opera gerektirir). Ayrıca, Google sayfa hızı ( tarayıcı uzantısıyla birlikte kullanılır ) performans profili oluşturmak için başka bir araçtır ve resimlerinizi de optimize eder.
  • Araç çubukları gibi küçük ilgili görüntüler için CSS Image Sprites kullanın ("HTTP isteklerini en aza indir" noktasına bakın)
  • Araç çubukları gibi küçük ilgili görüntüler için SVG görüntü sprite kullanın . SVG boyama biraz zor. Buradan okuyabilirsiniz .
  • Meşgul web siteleri bileşenleri etki alanlarına bölmeyi düşünmelidir . Özellikle ...
  • Statik içerik (yani görüntüler, CSS, JavaScript ve genellikle çerezlere erişmesi gerekmeyen içerik) çerez kullanmayan ayrı bir alana gitmelidir , çünkü bir alan adı ve alt alan adları için tüm çerezler her istek için gönderilir. etki alanı ve alt alanları. Buradaki iyi bir seçenek, İçerik Dağıtım Ağı'nı (CDN) kullanmaktır, ancak alternatif CDN'ler veya bunun yerine sunulabilecek yerel kopyalar ekleyerek CDN'nin başarısız olabileceği durumlarını düşünün.
  • Bir tarayıcının sayfayı oluşturması için gereken toplam HTTP isteği sayısını en aza indirin.
  • Bir şablon motoru seçin ve gulp veya grunt gibi görev-kaçakçılarını kullanarak oluşturun / önceden derleyin
  • favicon.icoSitenin kökü içinde bir dosya olduğundan emin olun /favicon.ico. HTML’de simgesi belirtilmemiş olsa bile tarayıcılar bunu otomatik olarak ister . Eğer sahip değilseniz /favicon.ico, bu, sunucunuzun bant genişliğini boşaltarak 404'lerin çoğuna neden olur.

SEO (Arama Motoru Optimizasyonu)

  • Kullanmak, yani URL'ler "arama motoru dostu" kullanın example.com/pages/45-article-titleyerineexample.com/index.php?page=45
  • #Dinamik içerik için kullanılırken ve sonrasında sunucuda değişiklik #yapmak yerine googlebot'un yerine kullanır . Başka bir deyişle, olur . Ayrıca, FF.b4 veya Chromium kullanıyor olabilecek kullanıcılar için harika bir komut. Dolayısıyla, adres çubuğu değişmiş olsa bile sayfa yeniden yüklenmiyor. Bu, dinamik içeriği tutmak yerine kullanmanıza izin verir ve ayrıca bu sayfadan sonra geldiğimiz bağlantıyı e-postayla gönderdiğinizde sunucuya söyler ve AJAX'ın başka bir ek istek yapması gerekmez.#!$_REQUEST["_escaped_fragment_"]#!./#!page=1./?_escaped_fragments_=page=1history.pushState({"foo":"bar"}, "About", "./?page=1");?#!
  • "Buraya tıkla" yazan bağlantıları kullanmayın . Bir SEO fırsatını boşa harcıyorsunuz ve ekran okuyucuları olan insanlar için işleri zorlaştırıyor.
  • Tercihen varsayılan konumda bir XML site haritası oluşturun/sitemap.xml .
  • <link rel="canonical" ... />Aynı içeriğe işaret eden birden fazla URL’niz varsa kullanın , bu sorun Google Web Yöneticisi Araçları’ndan da çözülebilir .
  • Google Web Yöneticisi Araçları ve Bing Web Yöneticisi Araçları'nı kullanın .
  • Google Analytics'i en baştan yükleyin (veya Piwik gibi bir açık kaynak analiz aracı ).
  • Robots.txt ve arama motoru örümceklerinin nasıl çalıştığını bilin .
  • Google sıralamasını her iki site arasında paylaştırmayı önlemek 301 Moved Permanentlyiçin istekte www.example.combulunma isteklerini (kullanarak ) yönlendirme isteyin ( example.comveya diğer tarafa).
  • Dışarıda kötü davranış gösteren örümceklerin olabileceğini bilin.
  • Metin olmayan içeriğiniz varsa Google'ın video vb. Site haritası uzantılarını inceleyin. Bu konuda Tim Farley'nin cevabında bazı iyi bilgiler var .

teknoloji

  • HTTP ve GET, POST, oturumlar, çerezler ve "vatansız" olmanın ne demek olduğunu anlayın .
  • Senin yazın XHTML / HTML ve CSS göre W3C özelliklere ve onlar emin olun doğrulamak . Buradaki amaç tarayıcı tuhaflık modlarından kaçınmak ve bir bonus olarak ekran okuyucu ve mobil cihazlar gibi geleneksel olmayan tarayıcılarla çalışmayı çok daha kolaylaştırıyor.
  • Tarayıcıda JavaScript'in nasıl işlendiğini anlayın.
  • Sayfanızın kullandığı JavaScript, stil sayfaları ve diğer kaynakların nasıl yüklendiğini anlayın ve bunların algılanan performans üzerindeki etkilerini göz önünde bulundurun . Artık, genellikle analiz uygulamaları veya HTML5 şimleri gibi şeyler içeren istisnalar dışında , komut dosyalarını sayfalarınızın altına taşımak uygun olarak kabul edilir .
  • JavaScript sanal alanının nasıl çalıştığını, özellikle iframe'leri kullanmayı düşünüyorsanız, anlayın.
  • JavaScript’in devre dışı bırakılabileceğini ve devre dışı bırakılacağını ve bu nedenle AJAX’ın bir taban çizgisi değil, bir uzantısı olduğunu unutmayın. Çoğu normal kullanıcı bunu açık bıraksa bile , NoScript'in daha popüler hale geldiğini, mobil cihazların beklendiği gibi çalışmayabileceğini ve Google’ın siteyi dizine eklerken JavaScript’inizin çoğunu çalıştırmayacağını unutmayın.
  • 301 ve 302 yönlendirmeleri arasındaki farkı öğrenin (bu aynı zamanda bir SEO sorunudur).
  • Dağıtım platformunuzla ilgili mümkün olduğu kadar çok şey öğrenin.
  • Bir Stil Sayfasını Sıfırla veya normalize.css kullanmayı düşünün .
  • DOM manipülasyonu için JavaScript kullanırken birçok tarayıcı farkını gizleyecek olan JavaScript çerçevelerini (örneğin, jQuery , MooTools , Prototype , Dojo veya YUI 3 gibi ) düşünün .
  • Algılanan performansı ve JS çerçevelerini bir araya getirerek, çerçeveleri yüklemek için Google Kütüphaneleri API'sı gibi bir hizmeti kullanmayı düşünün, böylece bir tarayıcı sitenizden yinelenen bir kopya indirmek yerine zaten önbelleğe almış olduğu çerçevenin bir kopyasını kullanabilir.
  • Tekerleği yeniden icat etme. HERHANGİ BİR şey yapmadan önce, nasıl yapılacağına ilişkin bir bileşen veya örnek arayın. Birinin bunu yapma ve kodun bir OSS sürümünü yayınlama olasılığı% 99'dur.
  • Bunun yanında, ihtiyaçlarınızın ne olduğuna karar vermeden önce 20 kütüphaneyle başlamayın. Özellikle, işleri hafif, hızlı ve esnek tutmanın neredeyse her zaman daha önemli olduğu müşteri tarafı ağında.

Hata düzeltme

  • Zamanınızın% 20'sini kodlayarak ve% 80'ini koruyarak geçireceğinizi anlayın, öyleyse buna göre kodlayın.
  • İyi bir hata raporlama çözümü kurun.
  • İnsanların öneri ve eleştirilerinizle sizinle iletişim kurabilecekleri bir sisteme sahip olun.
  • Uygulamanın gelecekteki destek personeli ve bakım yapan kişiler için nasıl çalıştığını belgeleyin.
  • Sık yedekleme yapın! (Ve bu yedeklemelerin işlevsel olduğundan emin olun) Yalnızca bir yedekleme stratejisi değil, bir geri yükleme stratejisine sahip olun.
  • Subversion , Mercurial veya Git gibi dosyalarınızı saklamak için bir sürüm kontrol sistemi kullanın .
  • Kabul Testinizi yapmayı unutmayın. Selenyum gibi çerçeveler yardımcı olabilir. Özellikle testinizi tamamen otomatikleştiriyorsanız, belki de Jenkins gibi bir Sürekli Entegrasyon aracı kullanarak .
  • Log4j , log4net veya log4r gibi çerçeveler kullanarak yeterli giriş yaptığınızdan emin olun . Canlı sitenizde bir şeyler ters giderse, ne olduğunu öğrenmenin bir yoluna ihtiyacınız olacaktır.
  • Günlük kaydı sırasında, hem işlenen istisnaları hem de işlenmeyen istisnaları yakaladığınızdan emin olun. Günlük çıktısını raporlayın / analiz edin, çünkü sitenizdeki temel sorunların nerede olduğunu gösterir.

Diğer

  • Hem sunucu tarafında hem de istemci tarafında izleme ve analitik uygulayın (biri reaktif değil proaktif olmalıdır).
  • Kullanıcılarınızla sürekli iletişimde olmak için, UserVoice ve Intercom (veya benzeri bir araç) gibi hizmetleri kullanın.
  • Takip Vincent Driessen 'ın Git dallanma modeli

Faydalı cevaplar olmadıkları için pek fazla şey atlamak zorunda değillerdi, ancak ya çok ayrıntılı olduklarından, kapsam dışında olduklarından ya da bilmeleri gereken şeylerin bir özetini almak isteyen biri için biraz fazla ileri gittiklerinden. Lütfen bunu da düzenlemek için çekinmeyin, muhtemelen bazı şeyleri özledim veya bazı hatalar yaptım.


7
SEO önerilerinizden bazıları kötü. Tablo veya divs kullanmanız farketmez (Google bunu kendileri onayladı). Bu SEF URL olayı ... Bu "sahte URL'lerden" nefret ediyorum, burada kimlik gerçekten sayfayı belirleyen tek şeydir. "45-falan" aynı sayfa olurdu. Kullanıcı dostu da değil.
DisgruntledGoat

152
Sonra düzenleyin. Bunların çoğunu yazmadım: Ben sadece bunu sürdürüyorum - miras aldığım bir iş, çünkü soruyu sordum, özellikle daha büyük bir cevabı talep ettim ve ne bulabileceğimizi görmekle gerçekten ilgileniyorum . Daha fazla katkı daha iyi.
Joel Coehoorn

327
Bir not daha: geri gelir ve bunu düzenlerseniz, yazılanlara saygılı olmaya çalışın. Sadece aynı fikirde olmadığın parçaları sökmekle kalmaz, gerçekte kısa olanları ele almak ve daha iyi bir şeyler sunmak için zaman ayır.
Joel Coehoorn

16
Güvenlik bölümüne eklemenizi önerdiğim bir şey, sunduğunuz tüm dosyaların izin verilen klasörlerin bir beyaz listesiyle karşılaştırılması veya web sunucusunu "hapse atması" olmasıdır. Bu birini kullanarak durur http://server/download.php?file=../../etc/password. Dosya yollarını asla kullanıcıya maruz bırakmayın.
Philluminati

10
Örnek olarak, sadece bir arabaya atlayıp sürmeye başlamazsınız. Bunun yerine, o arabanın doğru çalışmasıyla ilgili dersler alıyorsunuz ve sonunda kullanabileceğinizi kanıtlayan bir testi geçmek zorundasınız. Bazıları için, bu çalışma çok, çok, çok saatlerce sürer . Ve evet, düzgün bir uygulama oluşturmada bir araba uygulaması yapmayı öğrenme ile bir web uygulamasının nasıl düzgün bir şekilde yapıldığını öğrenmekle eşitlemek isterim ki, insanların yaşamlarını basit bir çamurluk bükücüsünden daha büyük ölçüde bozabilir; finansal kayıp. Ölüm? Peki, geliştiricinin ne tür bir uygulamayı bozduğuna bağlı.
04
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.