Bilgili bir arkadaşım kısa bir süre önce lansmana yardım ettiğim bir web sitesine baktı ve "çok güzel bir site, kaynak koddaki satır içi komut dosyası hakkında utanç" gibi bir yorum yaptı.
Kesinlikle satır içi komut dosyası gerçekleştiği yerde kaldırabilirim; Bunun "kötü bir şey" olduğunun farkındayım. Sorum şu: satır içi komut dosyası oluşturma ile ilgili gerçek sorunlar nelerdir? Önemli bir performans sorunu var mı, yoksa çoğunlukla iyi bir stil meselesi mi? Sitede daha belirgin bir etki yaratabilecek başka şeyler olduğunda, satır içi komut dosyası oluşturma cephesi üzerindeki acil eylemi üstlerime haklı çıkarabilir miyim? Bir web sitesine gittiyseniz ve kaynak koduna göz attıysanız, hangi faktörler sizi "hmm, profesyonel iş burada" demeye götürür ve açıkça amatörce bir işten geri tepmenize neden olur?
Tamam, bu soru yazıda birden fazla soruya dönüştü. Ama temel olarak, satır içi komut dosyası oluşturma - anlaşma nedir?
satır içi komut dosyası oluşturmayla ilgili gerçek sorunlar nelerdir? Önemli bir performans sorunu var mı, yoksa çoğunlukla iyi bir stil meselesi mi?
Avantajlar performansa dayalı değildir, (Michael'ın yorumunda belirttiği gibi), görünüm ve denetleyicinin ayrılmasıyla daha ilgilidir. HTML/CSS dosyası ideal olarak yalnızca sunuyu içermeli ve komut dosyaları için ayrı dosyalar kullanılmalıdır. Bu, sizin (ve akranlarınızın) hem görsel hem de işlevsel yönleri okumasını ve korumasını kolaylaştırır.
Sitede daha belirgin bir etki yaratabilecek başka şeyler olduğunda, satır içi komut dosyası oluşturma cephesi üzerindeki acil eylemi üstlerime haklı çıkarabilir miyim?
Hayır muhtemelen değil. Saf bakım işindeki güçleri, uzun vadede para biriktireceğine inansanız bile, ikna etmek çok zor olabilir. Ancak bu durumda, her şeyi durdurmanız ve satır içi komut dosyalarınızdan kurtulmanızın o kadar önemli olduğunu düşünmüyorum. Bunun yerine, başka nedenlerle üzerinde çalışırken alanları düzeltmek için bilinçli bir çaba gösterdiğinizden emin olun. Yeniden düzenleme kodu düzenli olarak yaptığınız bir şey olmalıdır, ancak her seferinde sadece biraz.
Bir web sitesine gittiğinizde ve kaynak koduna bir göz attıysanız, hangi faktörler sizi "hmm, profesyonel iş burada" demeye götürür ve açıkça amatörce bir işten geri tepmenize neden olur?
Bana profesyonel olmadığını söyleyecek bir numaralı faktör, tabloların veya div'ların aşırı kullanımıdır. İşte bir makale neden ikisinin de fazla kullanılmaması gerektiğini açıklayan.
Şeytanın avukatı olmayacağım, ancak amatörce iş ve satır içi JavaScript arasında kesin bir ilişki yok. En bilinen birkaç web sitesinin kaynak kodunu görelim:
Ana sayfalarının her birinde satır içi JavaScript kullanılır. Bu şirketlerin ana sayfalarını oluşturmak için amatörce insanları işe aldıkları anlamına mı geliyor?
HTML içine JavaScript kodu koyamayan geliştiricilerden biriyim. Üzerinde çalıştığım projelerin içinde asla yapmam (muhtemelen
<a href="javascript:..."> göze batmayan JavaScript başından beri bir gereklilik değildi projeler için, ve ben başkasının kodunu yeniden refactor zaman her zaman inline JavaScript kaldırmak. Ama çabaya değer mi? Pek emin değilim.
Performans açısından, JavaScript'i ayrı bir dosyaya koyarken her zaman daha iyi performansa sahip olmazsınız. Genellikle, satır içi JavaScript atık bant genişliğini, önbelleğe alınamayacağı için dikkate almak isteriz (statik önbelleğe alınabilir HTML ile uğraşmanız durumu hariç). Tersine, bir extern .js dosyası sadece bir kez yüklenir.
Gerçekte, bu sadece başka bir erken optimizasyon: JavaScript'i harici hale getirmenin web sitenizi sabitleyeceğini düşünüyor olabilirsiniz, ancak tamamen yanlış olabilir:
Bu nedenle, zamanından önce optimizasyon yapmadan önce, ziyaretçilerinizle ilgili istatistikleri toplayın ve performansları satır içi JavaScript ile ve satır içi JavaScript olmadan değerlendirin.
Sonra son argüman gelir: kaynağınızda JavaScript ve HTML'yi karıştırdınız, böylece berbatsınız. Ama ikinizi de karıştırdığınızı kim söyledi? Tarayıcı tarafından kullanılan kaynak kodu her zaman yazdığınız kaynak kod değildir. Örneğin, kaynak kodu sıkıştırılabilir, küçültülebilir veya birkaç CSS veya JS dosyası tek bir dosyada birleştirilebilir, ancak bu değişkenlerinizi gerçekten adlandırdığınız anlamına gelmez
a,
b,
c ...
a1, vb. veya boşluklar veya yeni satırlar olmadan büyük bir CSS dosyası yazdınız. Aynı şekilde, şablonlar aracılığıyla derhal veya daha sonra HTML'ye harici JavaScript kaynak kodunu kolayca ekleyebilirsiniz.
Sonuç olarak, yazdığınız kaynak kodunda JavaScript ve HTML'yi karıştırırsanız, gelecekteki projelerinizde yapmamayı düşünmelisiniz.Ancak, tarayıcıya gönderilen kaynak kodunun satır içi JavaScript içerdiği anlamına gelmez, her zaman kötü.
web sitesinin nasıl yapıldığına dair hiçbir şey bilmeden sadece tarayıcıya gönderilen kaynağa bakarak "çok güzel site, kaynak kodundaki satır içi komut dosyası hakkında utanç" diyen kişiye utanç duyuyoruz.
HTML ve JS'yi genel olarak ayrı tutmaya çalışmak genellikle iyidir. HTML görünüm içindir, JS uygulama mantığı içindir. Ama benim tecrübelerime göre, html ve javascript'in aşırı ayrıştırılması (saflık uğruna) onu daha sürdürülebilir kılmaz; aslında daha az bakım yapılabilir.
Örneğin, bazen bu işleyiciyi (ASP.net'ten ödünç alınan) olay işleyicilerini ayarlarken kullanıyorum:
<input type="button" id="yourId" onclick="clickYourId()" />
veya
<input type="button" id="yourId" onclick="clickYourId(this)" />
Bir olayın gerçekleşmesini tetikleyen şeyin gizemi yoktur. Bunun nedeni, altı ay sonra öğeyi (ör. Chrome'da) inceleyip hemen hangi javascript etkinliğinin tetiklendiğini görebilirsiniz.
Öte yandan, yüz bin satırlık bir başkasının kodunu okuduğunuzu ve bir javascript etkinliğini başlatan büyülü bir öğeyle karşılaştığınızı hayal edin:
<input id="yourId" />
Bunun hangi javascript yöntemini çağırdığını kolayca nasıl anlarsınız? Chrome bunu kolaylaştırdı, ancak belki de etkinlik kimliğe veya belki de kapsayıcının ilk alt öğesine bağlıdır. Belki olay üst nesneye eklenir. Kim bilir? İyi şanslar buluyorum. :)
Ayrıca, javascript'i tamamen tasarımcıdan gizlemenin, bir güncellemede kırılma olasılığını artırabileceğini iddia ediyorum. Birisi sihirli bir şekilde etkin olan bir öğenin kodunu düzenlerse, kodda bunun sayfada etkin bir öğe olduğunu bildiren hangi göstergeye sahiptir?
Kısacası, en iyi uygulama HTML ve Javascript'i ayırmaktır. Ancak, aşırı kurallara taşındığında, başparmak kurallarının bazen olumsuz olduğunu da anlayın. Orta yollu bir yaklaşımı savunuyorum. Büyük miktarda satır içi js kaçının. Satır içi kullanıyorsanız, işlev imzası aşağıdaki gibi çok basit olmalıdır:
1. emptyFunction() 2. doCallWithThis(this) 3. atTheExtremOnlyPassOneNumber(2)
Burada eksik olduğum bir argüman siteler arası komut dosyası oluşturma saldırılarına karşı daha fazla koruma olasılığı.
Modern tarayıcıda satır içi JavaScript'in çalışmasını İçerik Güvenliği İlkesi aracılığıyla devre dışı bırakmak mümkündür. Bu, sitenizin XSS kurbanı olma riskini azalttı. Bu, yönetiminize satır içi komut dosyasını kaldırmaya yatırım yapmak için daha ikna edici bir argüman olabilir.
İşte birkaç neden.
Satır içi komut dosyası simge durumuna küçültülemez (simge küçültme yoluyla daha kısa bir sürüme dönüştürülür). Geniş bantla ilgili bir endişe değil, ancak düşük bant genişliği alanındaki bir mobil cihazı veya küresel veri dolaşımında olan kullanıcıları düşünün - her bayt sayılabilir.
Satır içi komut dosyası, sayfanın kendisi önbelleğe alınamazsa (çok sıkıcı bir sayfa yapar) tarayıcı tarafından önbelleğe alınamaz. Harici Javascript dosyaları, sayfa içeriği her seferinde değişse bile yalnızca bir kez alınmalıdır. Düşük bant genişliği bağlantılarındaki performansı ciddi şekilde etkileyebilir.
Satır içi komut dosyasında hata ayıklamak daha zordur, çünkü herhangi bir hatayla ilişkili satır numarası anlamsızdır.
Satır içi komut dosyasının erişilebilirlik (508/WAI) hususlarına müdahale ettiği söylenir, ancak bu tüm satır içi komut dosyalarının sorunlara neden olduğu anlamına gelmez. Komut dosyası içeriğini bildiren bir ekran okuyucu ile karşılaşırsanız, bir sorun var demektir! (Bunun olduğunu hiç görmedim).
Satır içi komut dosyası sayfasından bağımsız olarak test edilemez; harici Javascript dosyaları otomatik testler de dahil olmak üzere bağımsız testlerle çalıştırılabilir.
Satır içi komut dosyası, kaygıların zayıf bir şekilde ayrılmasına yol açabilir (buradaki diğer cevapların çoğu tarafından açıklandığı gibi).
Komut dosyasını satır içi dahil etmemeyi haklı gösterecek birden fazla neden vardır:
Her şeyden önce, bariz cevap, daha temiz, daha özlü, anlaşılması ve okunması kolay kodlar sağlar.
Daha pratik bir bakış açısından, genellikle komut dosyalarını/CSS/vb. web sitenizin her yerinde - bu bölümleri satırlamak, her küçük değişiklik yaptığınızda her sayfayı düzenlemek zorunda kalacağınız anlamına gelir.
Projeniz için bir SCM kullanırsanız, farklı bileşenlerinizin birbirinden iyi ayrılması, izleme değişikliklerini yapar ve ilgili herkes için daha kolay taahhüt eder.
Bildiğim kadarıyla performans bir endişe yaratmaz. Web sitenizin yapısı, sunucunuzun özellikleri vb. İle ilgili birçok şeye bağlıdır. Örneğin, web sayfanız çok fazla javascript kullanıyorsa, tarayıcınız komut dosyalarını önbelleğe alabilir ve kod birden fazla dosyada ayrılır. Öte yandan, bazı sunucuların tek bir büyük dosyayı birden çok küçük dosyadan daha hızlı sunabileceğini söylemeye cazip gelebilirim - bu durumda kodun ayrılmamasının daha iyi bir performans olduğunu iddia edebiliriz.
Bu alanda herhangi bir resmi testin farkında değilim, ancak birileri bunları yapmış olabilir.
Sonunda, bunun her şeyden çok iyi uygulamalar meselesi olduğunu ve okunabilirlik ve organizasyon açısından (özellikle w.r.t. nokta 2) avantajların, kodu farklı dosyalarda ayırmayı çok daha iyi bir seçenek haline getirdiğini söyleyebilirim.
Yanıt, satır içi kodun (javascript varsayarak) nasıl kullanıldığına bağlıdır.
İstediğimiz efektleri oluşturmak ve onClick olayları için sunucu dönüş yolculuklarını azaltmak için satır içi kod, SSI'lar (sunucu tarafı içerir), js dosyaları ve css dosyalarının bir kombinasyonunu kullandık.
Yani birisi için "satır içi kod" kullanımının nasıl kullanıldığını tam olarak anlamadan kötü olduğunu belirten bir açıklama yapmak yanıltıcı olabilir.
Söyledikten sonra, her sayfa aynı kopyaya sahip ve js dosyası yerine javascript kodunu yapıştırdıysa, bunun kötü olduğunu söylüyorum.
Her sayfanın kendi kopyası varsa ve css dosyası yerine CCS bölümü yapıştırılmışsa bunun kötü olduğunu söylüyorum.
Ayrıca, js kitaplığınızın tamamını her sayfaya dahil etmek, özellikle de bu sayfada işlevlerin hiçbiri kullanılmıyorsa, ek yükü vardır.
Burada satır içi javascript alacağım.
Kodu görmeden, emin olmak zor. İki şeyden birine atıfta bulunduğundan şüpheleniyorum:
<script>s sayfa boyunca dağılmış
Birincisi kötü bir tasarım kararı. Komut dosyalarını bir kaynak dosyaya yaymak, belirli bir komut dosyasını aramanız gerektiğinden sayfanın bakımını çok daha zor hale getirir. Tüm bu kodu tek bir yerde tutmak daha iyidir (Kaynak dosyanın üst kısmında tercih ederim).
İkincisi - bu mutlaka kötü bir şey değildir. Sayfaya özel kod bu sayfada olmalıdır. Sayfalar arasında yinelenen kod varsa,
<script src>. Ardından yeni bir sayfa oluşturmaya gittiğinizde, o dosyayı dahil edebilirsiniz ve düzelttiğiniz hataların yeniden gözden geçirilmesi gerekmez.
InLine Javascript'i (düğmelerde bile onclick = "DoThis (this)") kullanmamanın bir nedeni, web uygulamanızı Chrome App. web uygulamanızı bir Native Chrome App içine taşımak için, HERHANGİ BİR satır içi javascript dahil DEĞİLDİR) Bu, web uygulamanızdan neyi değiştirmeniz gerektiğini (zorunlu olarak) "Chrome etize" etmeyi planlıyorsunuz.
Satır içi komut dosyası oluşturmayla ilgili gerçek sorunlar nelerdir?
Satır içi komut dosyası yazmak kötüdür ve kodun okunmasını zorlaştırdığından kaçınılmalıdır.
Okunması zor olan kodun bakımı zordur. Kolayca okuyamaz ve neler olduğunu anlayamazsanız, hataları kolayca tespit edemezsiniz. Bakımı zorsa, sorun olduğunda daha fazla zaman harcayacaktır.
Zorluk genellikle iç içe kodlamalardan kaynaklanır. Kodun bir sonraki satırında bir sorun var, anlayabilir misiniz?
<a onclick='alert("What\'s going wrong here?")'>Alert!</a>
İdeal olarak kod, bir hata olduğunda fark edilmeyi kolaylaştıracak şekilde yazılır. Joel Spolsky, 2005'te bu noktayı vurgulayan harika bir makale yazdı . Kod örnekleri, yaşlarının 9 yaşında olduğunu gösterdikleri için bazı önemli iyileştirmeler kullanabilir, ancak temeldeki kavram hala güçlüdür: kodu, hataları seçmeyi kolaylaştıracak şekilde yazın.
Önemli bir performans sorunu var mı, yoksa çoğunlukla iyi bir stil meselesi mi?
Satır içi komut dosyaları tekrarlamaya yol açar. 100 sayfayı etkilemek için bir kod satırını değiştirmek yerine 100 sayfayı tek tek değiştirmeniz gerekecektir. Bu düşük okunabilirlik ile birlikte bakımcının performansını ciddi şekilde etkiler. Programlama süresi, bir işletmenin alt satırını çoğu kod optimizasyonundan birkaç milisaniyeden daha hızlı etkileyen gerçek bir maliyete sahiptir. Darboğazları kesinlikle optimize etmek önemlidir, ancak bu durumda kodun performans farkı ihmal edilebilir.
Sitede daha belirgin bir etki yaratabilecek başka şeyler olduğunda, satır içi komut dosyası oluşturma cephesi üzerindeki acil eylemi üstlerime haklı çıkarabilir miyim?
Hayýr. Eđer aptalca ve iţe yarýyorsa, aptal deđil.
Programlamanın sonucu: aptal kod ve eğer çalışıyorsa, aptal kod değildir. Kırık olmayan bir şeyi düzeltmeye çalışmadan önce gerçek sorunlara odaklanın. Satır içi kodun bir güncellemeye ihtiyacı olduğunda altı saat, altı ay veya altı yıl içinde olsun, kodu gelecekteki bakımları kolaylaştıracak şekilde düzeltin.
Hangi faktörler "hmm, profesyonel iş burada" demenize neden olur ve bariz bir şekilde amatörce bir işten geri tepmenize neden olur?
"Profesyonel" i sadece bir görevi yerine getirmesi için para ödenen biri olarak tanımlamayı tercih ediyorum. Birçok profesyonel kesinlikle iyi iş yapma yeteneğine sahiptir, ancak çoğu zaman bir amatörün ortaya çıkardığı bir şeyden ziyade diğer profesyonellerin yaptığı korkunç işte dehşet içinde geri teptiğimi görmüyorum. Bugüne kadar yaptığım çalışmaların çoğu, ilk geliştiriciler tarafından geliştirilen tren kazası projelerinin kurtarılmasını içeriyordu, bu nedenle kilometreniz değişebilir.