Arka uç geliştiricilerin daha kolay çalışmasını sağlamak için HTML, CSS ve JavaScript'i nasıl yazabilirim?

Bir tasarımcıdan bir tasarım aldığımda, onu bir PSD (Photoshop) dosyası olarak alıyorum. Her zaman uygun katman ve klasör adları, temelde temiz ve yönetilen bir PSD bekliyoruz. Bu tasarımdan HTML, CSS ve JavaScript geliştiriyorum ve bunu arka uç geliştiricilere ulaştırıyorum. Anlamalarını kolaylaştırmak için,

• anlamsal kod yazma,
• JavaScript ve CSS'yi harici dosyalarda saklayabilir
• HTML, CSS ve JS dosyalarına yararlı yorumlar ekleyebilir,
• CSS spritelarını kullanın (geliştiriciler hoşlanmasa da),
• HTML5 kazan plakası kullanın,
• JavaScript için jQuery kullanın,
• mümkün olduğunda yeni HTML5 etiketleri ve CSS3 kullanmaya çalışın ve
• HTML, CSS, JS ve resimleri içeren bir Zip dosyası gönderdi.

Düzende küçük değişiklikler yapılması gerekiyorsa, geliştiricilerin bunu başarabileceğini umuyorum.

Arka uç geliştiricilerden ve diğer CSS ninjalarından, arka uç sistemleriyle entegrasyonu kolaylaştırmak için dosya organizasyonu ve işaretleme konusunda daha neler yapabileceğini duymak istiyorum (yani arka uç teknolojileri, PHP, .NET , Ruby vb.) Farklı istemci farklı sistemler kullanır.

Bu cevapların birçoğu geniş fikir yığınlarını kapsayacak, ama işte benim kişisel cevaplarım:

• Hata iletileri için form tasarımında yer bırakın.
• Giriş kutularına etiket koymayın!
• Ne yaptığınızı bilmiyorsanız ve bu konuda düzgün bir şekilde kötü hissetmiyorsanız, CSS ve JavaScript'inizi ayrı bir dosyaya koyun.
• Tasarım öğelerini sayfalar arasında aynı tutun. Bir tasarım bileşeninin ("son görüntülenen" bir kutu gibi) her sayfada farklı bir işaretlemesi olduğunda sinir bozucu olur.
• Senin için kolay olanı yapma, doğru olanı yapma. <button>Etiketler emmek. backround-imagegerçekten <img>etiketleri emmek gereken şeyler için .
• Bir sayfa bileşeni oluşturuyorsanız, ölçeklenebildiğinden emin olun. En iyi ön uç geliştiricilerinin bunu yaptığını biliyorum, ancak birisinin üst / alt kapak durumunda olması gereken tek bir görüntüyü kullandığı çok sayıda örneğim vardı. Programcılar Photoshop'u açmayı sevmezler.
• Şablonlarınızı düzeltin. Programcılar (iyi olanlar) özel, detay odaklı insanlar. Tasarımınızdaki sorunları görmeye başlarlarsa (altbilgi gezinmesinin yazım hataları veya tutarsız yazımları olabilir) soru sormalarını ve çalışmalarını yavaşlatmalarını sağlayacaktır.

Son olarak ve belki de en önemlisi:

• Arka uçta geliştirilmekte olan dilin temel kurallarını öğrenin. Bir PHP şablonuna bakabilmek ve bir foreachveya ififadenin arkasındaki temel sözdizimini ve bir ifadeyi nasıl biçimlendireceğinizi echoveya bir <?php ?>etiketi nasıl taşıyacağınızı anlamak, bir ön uç geliştirici olarak değerinizi büyük ölçüde artıracaktır - Bir ön uç geliştiricisinin ihtiyacı olduğunda seviyorum basit bir değişiklik yapmak ve bana tüm dosyalarının yeni bir zip vermek yerine şablonda yapabilirsiniz .
• Ek olarak, sürüm kontrol yazılımını kullanmayı öğrenin. Bir uzman olmanıza gerek yok, ancak iki zip dosyası arasında neyin değiştiğini denemek ve bulmak yerine bir diff'e bakabilirsem, işimi yüz kat daha kolay hale getiriyor.

Bunlar sadece birkaçı - Eminim çok daha fazlası var, ancak bunların hepsini gerçekleştirirseniz, şablonlarınızı bir web sitesine dönüştürenlerin saygısını ve takdirini kazanacaksınız.

Bunun arka uçtaki bir adamın hayatını kolaylaştırabileceği açık şeyler davranıştaki sadeliktir. Bir web sayfasının çeşitli davranışları (roll-over, menüler, vb.) Öğeleri tasarlarken, geliştiricinin hangi işlevi belirlemek için sürekli olarak bir grafiğe geri dönmesine gerek kalmaması için bu davranışların tümü ortak bir şekilde standartlaştırılmalıdır. bir sayfanın davranması için çağırmanız gerekir.

Izgaralar veri veya işlevsellik hücre manipülasyonu ile bir hücre gerektirmemelidir. Sayfaların blok öğeleri, ortak kod olarak kolayca tanımlanabilmelidir, böylece arkadaki kodda kolayca bölünebilirler. Bu, geliştiricinin kodu yeniden kullanmasına ve / veya sayfanın çeşitli yönleri arasındaki iletişimi kolaylaştırmasına yardımcı olacaktır.

Sayfanın alanları belirli tasarım sınırlarını aşmamalıdır. Bir öğedeki öğeler, başka bir öğedeki öğelere girmemelidir.

Bununla birlikte, geliştiricilerin yanan çemberlerden atlamasını engelleyemeyeceğiniz bir nokta var. Bazı arayüz öğeleri doğası gereği inşa etmek zor olacaktır.

Bazen, bir arka uç geliştirici için bir çözümü değiştirmeyi kolaylaştırmak ve optimize edilmiş bir şey yapmak arasında bir seçim yapmanız gerektiğini unutmayın.

Alıntıladığınız CSS spriteları iyi bir örnektir. Ölçeklenebilirlik ve performans önemli olduğunda birisinin nasıl web sitesi oluşturabileceğini anlamıyorum ve her sayfadan 100 resim, 5 CSS ve 15 JavaScript dosyasına bağlantı var. Öte yandan, CSS spritelarının bakımı kolay değildir ve tasarımdaki küçük değişiklikler çok fazla iş gerektirebilir.

Örneğin, biri diğerinin altında olmak üzere üç durum simgeniz varsa ve dördüncü bir durum eklemeniz gerekiyorsa, dördüncü simgeyi diğerlerinden ayrı olarak görüntünün altına ekler misiniz? Veya üçüncü simgeden sonra ekleyerek, boş alan olması için diğer her şeyi alta mı hareket ettiriyorsunuz?

Aynı şey CSS ve JavaScript dosyalarını birleştirme ve küçültme ile birlikte gelir. Belirli bir web sitesi için yapmalısınız, ancak ekstra çaba gerektirecektir.

CDN için de aynı şey geçerli. Büyük web siteleri için kullanmalısınız, ancak değişiklik yapmak daha zor olacaktır. Eğer bir CSS dosyası değişirse Örneğin, için dosyaya URI değiştirerek, yeni bir tane indirmek için tarayıcıları zorlamak zorunda cdn.example.com/g.css?r=2, o zaman cdn.example.com/g.css?r=3, vb

Ayrıca, "daha kolay" görecelidir . Örneğin, CSS kodu yazma yönergelerine bakın: kişisel olarak, boşluk olmadan, satır başına bir stil tercih ederim:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

çoğu insan bu sözdiziminden nefret eder ve nefret ettiğim ve okuması zor olanı tercih eder (hayır, deli değilim):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

Aynı şekilde, jQuery kullanmak, arka uç geliştiricinin dosyalarınızı değiştirmesini kolaylaştıracağınız anlamına gelmez, çünkü bazı geliştiriciler Prototip veya diğer çerçevelerle daha deneyimlidir.

Her durumda, geliştirici okumak istiyorsa (çoğu okumaz) ayrıntılı bir belge yararlıdır. Ayrıca, belirli geliştiriciye ne yapmayı tercih ettiğini tam olarak sorarak ve bir çerçeve oluştururken başlangıçta yan yana çalışarak (örneğin, küçültmek için kullanılacak iş akışını tasarlayarak) geliştiricinin hayatını kolaylaştırabilirsiniz. ve dosyaları birleştirin).

Tüm dünyaların en iyisi, tasarımcının bir zip dosyasını bir duvarın üzerinden atmaması ve aslında projede geliştiricilerden biri olarak çalışmasıdır. Kurulum için biraz tutamak gerekir, ancak tasarım ve geliştir arasında herhangi bir çeviri olmadığında ve herkes aynı iterasyonlarda yer alabildiğinde gerçekten harika. Eğer iyi bir sürtünmesiz çevik süreciniz varsa, bunu gerçekleştirmek çok zor değildir.

Çoğu durumda, sürüm kontrollü bir şekilde çalışan ve bunu dağıtım mekanizması olarak kullanan tasarımcılara yerleşirim. Gerçekten küçük bir değişiklik olduğunda büyük bir yağ zip dosyası ile uğraşmak istemiyorum.

Sizin için esneklik tipik olarak onlar için esnekliktir. İzlediğiniz tüm bu en iyi uygulamalar uygulamanın her iki tarafındaki kazançlardır.

Bununla birlikte, kritik ve sıklıkla kaçırılan bir nokta, sağlam UI yazmaktır. Çok fazla UI bileşeni bir bağlama veya aşırı titiz bir HTML kümesine aşırı derecede tutturulmuş ve başarısız olacak şekilde ayarlanmış CSS'leri var.

Örneğin, bir açılır listeniz varsa, göreli küme (koordinasyon gerekli değildir) tıklatılan bir kapsayıcıya mutlak konumlu bir bırakma bileşenini sabitlemek, JQuery çekiçini çekip koordinatların üzerine gelmesini sağlamaktan çok daha az JS çalışmasıdır. ve yerine yapıştırın. Sayfanın kaydığı veya bazı yeni tarayıcı özelliklerinin konumlandırma bilgilerini attığı durumlarda kırılma olasılığı daha düşüktür. JS çalışmasını önlemek için HTML / CSS becerilerine ne kadar güvenirseniz, kullanıcı arayüzünüz genellikle o kadar sağlam olur.

Genel bir kural olarak, UI bileşenlerimin ihtiyacı olan tek şeyin uygun bir kimlik veya sınıfla yaşamak için bir HTML etiketi olduğundan emin olmaya çalışıyorum. Bu kapsayıcı içinde UI kırılmadan veya kap boyutları ile kap boyutları değiştikçe sığacak şekilde genişletme / küçültme gibi daha fazla şey yapabildikçe, bir istemci tarafına ihtiyaç duymadan uygulamanın herhangi bir parçasına kolayca uygulanabilir uzman. Tek yapmaları gereken üzerine bir sınıf yapıştırmak.

Düğmeler gibi uç nokta düğümlerine dinleyicileri doğrudan atamak için kullanıcı arabirimindeki olay temsilcisini tercih edin. Bu UI bileşeni artık statik HTML ile çalışabilir, ancak birisinin içerideki HTML'yi innerHTML veya başka bir şeyle yeniden yazmak ve yeniden yazmak isteyeceğini asla bilemezsiniz. Kap sağlamsa ve tüm olaylar için yetki verildiyse (bkz. Jquery 'on' yöntemi) bunun için endişelenmenize gerek yoktur ve HTML dinleyicilerini değiştirmenin zor yolunu asla öğrenemezler.

Temsilciliği bir seçenek olarak tutmak için stopPropagate'i uç nokta düğümleri dışında hiçbir yerde kullanmayın ve her yere spam gönderen salak çerçeve geliştiricilerine nefret postası gönderin.

Düzen kadar HTML, minimal, anlamsal tutun ve div sarmalayıcılar kaçının. Ne kadar az HTML olursa, düzen çerezlerinin teşhis etmesi için düzen sorunları o kadar kolay olur.

Yardımcı program CSS için kendinden açıklamalı sınıf adları kullanın. "Satır" sınıfının CSS noobs için "clearfix" ten daha açık olması muhtemeldir.

Her zaman benzersiz kesit öğeleri, benzersiz kimlikler verin. Bir bölüme özgü şeylerin nerede olduğunu tanımlamayı çok daha kolay hale getirir, şeyleri geçersiz kılmak daha kolaydır ve ayrıca okunabilirlik ve performans JS kazancı olabilir.

Açıkçası bir sınıf şemasında aşırı almak kötü bir haberdir, ancak bir arka uç geliştirici şeylere doğru sınıfları ekleyerek ne kadar çok ayarlayabilirse, mevcut sayfada değişiklikler yapmaları o kadar kolay olacaktır.

Ve elbette projenin başında en azından bu tek şey üzerinde mutabakata varmalarını sağlayın: Arka ve ön uç sadece HTML ve JSON ile bağlanın. "JavaScript'i sizin için yazan!" Bu kanlı bir karmaşa ve bir bakım kabusu.

Gelişimle ilgili her şeyde olduğu gibi, KURU ve minimalizmi tercih edin.

Yine de sadece (çok aptal) yorum yapmama izin vermeyecek, ancak kişisel bir not olarak, her gün bir PHP kodlayıcıyla (işine yardımcı olmanın yanı sıra) arka arkaya çalışıyorum ve bulduğumuz en kolay araç Komodo araç kutusunu kullanmak ve araç kutusu içinde her görünüm / denetleyici / model "aktarılan" değişkenleri listeleme, böylece herhangi bir zamanda, eğer o sayfaya gönderilen bir veri kümesi etrafında bir sayfa tasarlamaya çalışıyorum, ben araç kutusuna bakabilir ve tam olarak hangi verilerin gönderildiğini ve hangi "tip" "olarak gönderildiğini görebilir, bunun yanı sıra bunun tersini de yapabilir.