“Kod” u tasarımcılardan uzak tutuyor musunuz?

Bir arkadaşımla oldukça fazla proje inşa ediyorum, ama hep aynı tuzağa tekrar tekrar geliyoruz. Ben PHP, Javascript ve her şeyi yazmayı biliyorum (ben de CSS ve HTML biliyorum) böylece gerçek işlevsellik oluşturma söz konusu olduğunda işin çoğunu yapabilirsiniz. Ancak yapamaz, ancak zar zor yapabileceğim bir şey yapabilir: siteleri tasarlayın.

Ancak her seferinde bir soruna rastlarız, kod yazmayı bilmediğinden, genellikle gelişimimizi biraz yavaşlatır. Şu anda bu bizim iş akışımız:

1. Bir özellik bulduk
2. Ön uç tasarımını inşa eder (nereye yerleştirilmesi gerektiği, nasıl görüneceği vb.)
3. Şablonun tamamını bana gönderiyor (Pinegrow'dan HTML dışa aktarma)
4. Yaptığı değişiklikleri arıyorum, sonra onları gerçek sitede uygularım (birkaç haftadan beri bunun için CakePHP kullanıyorum).
5. bir şey amaçlandığı gibi çalışmadığında (örneğin, bir nedenden dolayı planladığımız gibi çalışmadı), sorunu kendi tarafımda düzeltiyorum, sonra ona şablonu geri gönderiyorum
6. durulayın ve tekrarlayın

Tahmin edilebileceği gibi, bu süreç titizlikle yavaş ve verimsizdir. Benim sorum şu, bu süreci nasıl daha pürüzsüz hale getirebiliriz? React kullanmalı ve RESTful kullanmalıyız ve ne yapmamamız gerektiği hakkında çok şey gördüm, ama bunun için CakePHP kullanmak istiyoruz. Bazı insanlar bu konuda bazı yararlı kaynaklara rehberlik edebilir mi? Bunu bir süredir arıyordum ama bunun için asla iyi bir çözüme ulaşmadım.

Temel olarak, ortağımın yapabileceği tek şey siteyi tasarlamak. Docker'ı kullanamıyorum (Docker'ı her zaman kullanıyorum), PHP, Javascript ve hemen hemen başka bir şey (biraz CSS biliyor, ancak çoğunlukla bir WYSIWYGeditörle çalışıyor ) Onu öğrenmeye istekliyim, ama o ilgilenmiyorum (buna saygı duyuyorum). Umarım buradaki biri bana (ve muhtemelen bu soru ile daha sonra gelen) bu konuda yardımcı olabilir, çünkü bence bu çok önemli bir şey.

Front End Designer'ınızı koddan kurtarmak ister misiniz? Entegrasyonu hızlandırmak ister misiniz? En şık web siteleri tarafından kullanılan profesyonel teknikleri kullanmak ister misiniz? Şimdiye kadar, bunun için en iyi araç:

Boya.

Evet Boya. Zaten bazı çizim programı. Bırakın sitenizin ekran görüntülerini çekmesine, etrafta dolaşmasına ve başka bir yerde bulduğu şeyleri eklemesine izin verin. Bu, fikirlerinin hızında çalışmasına izin verecek ve ona ihtiyacı olan şekli verirken kodu sizin için en uygun şekle sokmanıza izin verecektir.

Bu hala çok yavaşsa, müşteri her ikiniz de sizinle odada olduğu için, çok daha gelişmiş bir araç seti tavsiye ederim:

Kağıt, makas ve bant.

Belki hırslı hissediyorsanız bir kalem.

Bu tekniği, Panera Ekmek'teki bir masada bir sitenin teması, stili, içeriği ve ana özellikleri hakkında kararlar almak için, herkes yemek yemediğimizi fark etmeden önce bir müşteriyle kullandım.

Bu onu hızlı hale getirecek, sizi "kodundan" kurtaracak ve aslında bir kullanıcı arayüzü geliştirmenin en güçlü yolu. Bir kod satırı yazmadan önce kullanılabilirlik testleri yapmaya başlayabilir.

"Ah başlamak bu iyi ama site geliştirildikten sonra bunu kullanmıyorsunuz" diye düşünüyor olabilirsiniz. Doğru değil. Kararlı sitelerde de çalışır. Ama şimdi ekran görüntülerinin çoğu kendi sitenizden geliyor.

Ön Uç Tasarımcınız, modelini oluşturmak için bazı kod oluşturma araçlarını kullanmak isterse ne olur? Güzel ama bir saniye bile onun "kodunu" kullanmak zorunda olduğunu düşünmeyin. Saygı duymanız gereken şey bakış, akış ve sunum hakkındaki kararlarıdır. Bunu gerçekleştirmek için perdenin arkasında olan şey onun uzmanlık alanı değil. Sizin. Bunun için sorumluluk al.

İşine yeterince saygı gösterin, işiniz bittiğinde ona nasıl ortaya çıktığını gösterin. Kullanıcının deneyimleyeceği her şeyi seçmesine izin verin. Yeni fikirlerden etkilenmeye hazır olun.

Bu yinelemeli bir gelişmedir. Sormadan önce çok şey yapmayın. Mümkün olduğunca az yapın. Mümkün olduğunca sık sorun. En son fikrini uygularken onu eğlendirmek için masanıza oyuncak koyun, böylece yüklenir yüklenmez onu gözden geçirebilirsiniz. Müşteriyle görüşme zamanı gelene kadar böyle devam edin.

Front End Designer'ınızın ürettiği kod gerçekten sorun değerse, kodunuzu onunla entegre etmeyi öğrenmeniz gerekir. Bunun için kaynak kontrolünü öğrenmenizi şiddetle tavsiye ederim . Ön Uç Tasarımcısına nasıl kullanılacağını öğretebileceğiniz kadar iyi öğrenin.

Her ikiniz de bir kaynak kontrol aracını güvenilir bir şekilde kullanabildiğinizde entegrasyon planınızı kod birleştirme üzerine dayandırmanızı öneririm. Bu noktada arkadaşınız Front End Designer'dan Front End Developer'a bir başlık değişikliğini hak eder.

Şimdi bunu yapsanız bile, ekrandaki karalamalar çekim tekniği hala ikinizin işbirliği yapmanın en hızlı yolu olmayacaksa beni şaşırtmaz.

Belki de tüm bu değişikliklerin kaosunu alamazsınız. Çok fazla iş yaratıyor. Buna yazılım denir çünkü değişikliği kabul eder. Aksi takdirde, bir Elektrik Mühendisi uzman bir çip üzerinde yapardık. Kullanıcı arabirimi değişiklikleri temel iş kurallarınızı etkilemeyeceği için, davranış mantığınızı kullanıcı arayüzünün dışına taşımak için seçeneğe ihtiyacınız olabilir . Ön Uç Tasarımınızı hızlandırırsanız, bunlara ayak uydurmaya hazır olmanız gerekir.

Bir Ön Uç Tasarımcısını kod üretmeye zorlamanın tek iyi nedeni, yorgun olmanız ve bunları yavaşlatmak istemenizdir. Sanırım bu gerçekten "iyi" bir sebep değil.

Araçlar açısından gördüğüm en uygun iş akışı Sketch ve Zeplin kullanıyor. Sketch, düz bir tasarım aracıdır. Photoshop veya InDesign ile eşdeğerdir, ancak uygulamalar ve web siteleri tasarlamak için optimize edilmiştir. Zeplin, Sketch (veya Photoshop) içindeki tasarımları paylaşmak ve onaylamak için bir araçtır. CSS veya diğer düzen kodu için kesin piksel ölçümleri ve hatta kod snippet'leri verebilir ve grafik varlıkları dışa aktarabilir. Bir tasarım belirlendikten sonra geliştiriciye dağıtılır. Bu noktada, geliştirici onu alır ve kullanıcı arayüzünü oluşturur. Daha sonra görsel KG için tasarımcıya geri dönebilir. Onunla yanlış bulduğu her şey, sizin tarafınızdan önceliklendirilmesi ve çözülmesi için bir hata olarak kaydedilmelidir.

bir şey amaçlandığı gibi çalışmadığında (örneğin, bir nedenden dolayı planladığımız gibi çalışmadı), sorunu kendi tarafımda düzeltiyorum, sonra ona şablonu geri gönderiyorum

Sorunlarınızın kökü bu. Tasarımın akışı her zaman olmalı Designer to Developerve asla tersine çevrilmemelidir. Düzeltmeler ve değişiklikler tasarımcı tarafından yapılmış ve daha sonra web sitesinde uygulanması için size itilmiş olmalıdır. Her zaman hızlı düzeltmeler yapabilirsiniz, ancak bu hızlı düzeltmelerin sadece geçici olduğunu kabul etmeye çalışın. Tasarımcının tasarımlarına geri dönmesi ve uygun çözümü bulması gerekiyor. Daha sonra değişikliği size iter ve hızlı düzeltmenizle aynı olursa harika olur, aksi takdirde tasarımlarından güncelleme yaparsınız.

Şablonun tamamını bana gönderiyor (Pinegrow'dan HTML dışa aktarma)

Çalışabileceğiniz HTML'yi almak için bağımlı olmayın. Web sitesi teknolojisini (Bootstrap, CSS, jQuery, React, PHP, vb .. vb .. vb.) İhtiyacınız olan şekilde uygularsanız daha iyi olur. Daha sonra tasarımlarını bu araçları kullanarak yeniden üretiyorsunuz. Verdiği HTML hızlı bir başlangıç ise harika, ancak daha sonra proje büyüdükçe çok fazla faydası olmayacak. Değişiklikleri kendiniz yapmanız gerekir çünkü şablonlama motorunuzu yalnızca siz anlarsınız (yani CakePHP görünümleri, şablonlar, eklentiler, bileşen vb. Vb.)

Tahmin edilebileceği gibi, bu süreç titizlikle yavaş ve verimsizdir.

Her zaman böyle olmuştur. Tasarımcılar programcı değil. Kullanıcı için neyin en iyi olduğunu bulmak için zaman ayırırlar ve bazen hata yaparlar. Bileşenler, çerçeveler ve benzeri kavramları anlamıyorlar. Programcı olarak tasarımcınızla konuşmalı ve tasarımınızı nasıl uyguladığımı paylaşmalısınız .

Tasarımcı ortada kalmış. Bir tarafta programcının ihtiyaçlarını, diğer tarafta kullanıcının ihtiyaçlarını karşılamaları gerekir.

Benim sorum şu, bu süreci nasıl daha pürüzsüz hale getirebiliriz?

Fiziksel olarak tasarımcının yanında oturmanın ve orada programlamanın iletişime gerçekten yardımcı olduğunu buldum. İkiniz uzaktan çalışıyorsanız, yüz gününü birkaç gün çalışmaya devam edin. Gerçekten işleri hızlandırmaya yardımcı olur.

React kullanmalı ve RESTful kullanmalıyız ve ne yapmamamız gerektiği hakkında çok şey gördüm, ama bunun için CakePHP kullanmak istiyoruz.

CakePHP, gezegendeki en iyi çerçevelerden biridir (tam açıklama, CakePHP çekirdek ekibindeyim).

Cake, özelliklerin web sitelerini hızlı bir şekilde oluşturmak için tasarlandığı bir tavşan geliştirme çerçevesidir. Kulağa bir satış konuşması gibi geldiğini biliyorum, ama bu olarak sınıflandırılıyor. Tavşan olarak sınıflandırılan başka birçok çerçeve var. Java, tavşandan daha kurumsal olan bir çerçeveye örnek olacaktır. Eğer o dili kullansaydın, o zaman değiştirmek için bir tavsiyede bulunmuş olurdum. CakePHP kullandığınız için. Onunla kalman gerektiğini savunuyorum.

RESTful API'lere ihtiyacınız varsa CakePHP iyi bir arka uç sunucusu sağlar.

React / Angular / Vue, popüler ve trend ön uç çerçevelerdir, ancak çok uzun süredir etrafta değiller. CakePHP ise 13 yıldan fazladır var. Demek istediğim bir eleştiri değil. Bu JavaScript kitaplıklarının kısa bir raf ömrüne sahip olması gerçektir. 5 yıl içinde hepimiz yeni bir şeyden bahsedeceğiz, ancak CakePHP'nin hala etrafta olacağından şüpheleniyorum.

Öyle diyorum. React / Angular / Vue'yu şimdi sıcakken kullanın, ancak onlara bağlı kalmayın. Yeni ve daha iyi bir şey kısa süre içinde olacak. Sanırım artık onlarsız iyi web siteleri oluşturamayacağınız bir dünyada yaşıyoruz.

Bazı insanlar bu konuda bazı yararlı kaynaklara rehberlik edebilir mi?

Liste istekleri burada konu dışıdır. Afedersiniz.

DÜZENLE :

Tasarım değişikliklerini takip etme kısmını kaçırdım.

Tasarımcınızın HTML çıktısını BitBucket'e kaydetmesini sağlayın (ücretsiz özel depoları var). Daha sonra BitBucket web sitesini kullanarak karşılaştırmaları izleyebilir ve yapabilirsiniz. Tasarımcı her büyük değişiklik yaptığında sürüm numarasıyla yeni bir şube ekler.

Bunu yapması nispeten kolay olmalı ve bu, söz konusu değişiklikler hakkında yorum yapabileceğiniz bir yere sahip olmanızı sağlayacaktır. Örneğin; birleştirilmeden önce değişiklikleri gözden geçirdiğiniz depoyu güncellemek için bir istekte bulunabilir.

Bu iki şeyi ayırmanız gerekir:

1. UX ve UI tasarımı, kodlama yapmayan bir etkinlik
2. Uygulama, kesinlikle bir kodlama faaliyeti

Tasarımcı, Marvel gibi sadece tasarım için olan yaratıcı araçları kullanmalıdır . Tasarımcının kod, HTML, CSS vb.

Programcı varlıkları ve maketi (etkileşimler ve animasyonlarla) almalı ve yazılımı programlayarak bunu gerçekleştirmelidir. Buna HTML ve CSS de dahildi. Programcı kendi tarafında jeneratör araçları da kullanabilir.

Görev akışını hızlandırmak için Trello gibi minimal bir araç kullanmanızı ve her çalışma birimi için her şeyi bağlamanızı / belgelemenizi öneririm .

bu süreci nasıl daha pürüzsüz hale getirebiliriz?

Sürüm kontrolünde ısrar etmek

Yazılım Dallanma ve Paralel Evrenler

• Sürüm kontrolünde olmayan hiçbir kod üzerinde çalışın. tam durak. Yani proje tamamen VCS'de olana kadar greve git.
• Resmi, liberal, yerel olarak şube
  • Resmi olarak: sürümler ve sürümlerin alt bölümleri için dallanma, resmi test düzeltmesi, vb. Resmi bir versiyon kontrol planı geliştirin, yani yazın.
  • Liberal olarak: 4 parçalı resmi sürüm numarasının ötesinde, bağırsağınız size iyi bir fikir olabileceğini söylüyorsa dal.
  • Yerel olarak: Hiçbir zaman takım tüketimi için tasarlanmamış şubeleri olan kişisel bir repo tuttum çünkü bir takım olarak ilk önce şubeye girmedik ve sık sık deneylerim, keşiflerim, her ihtimale karşı vs.

Ara katman yazılım API'larınızdan kurtulun

Yararları:

• Kararlılık - temel kod gelişirken bile.
• Test edilebilir kod
• Yeniden kullanım
• Bir ekip iletişim aracı
• Bu bir sözleşme. Sunulan hizmetlerin vaadi (pun amaçlı)
• SOLID == mutlu bakım programcısı alanında kodlama

Bu sormaktır, prensibi olması gerektiği gibi obsesif kompulsif şekilde uygulamayın. Kullanıcı arayüzü tek bir iş katmanı özelliğini kullanıyorsa, bu yanlıştır.

İş nesneleri ile ilgili her şey ve her şey BO'da olmalıdır. Kullanıcı arayüzünde en iyi şekilde görünebilecek önemsiz şeyler bile - tek bir LOC bile. Minuita, kullanıcı tarafından sağlanan 2 değer eklemeyi sever - doğrulama dahil tüm ilişkili mantık iş katmanı API'sında olmalıdır. IMO yedekliliği bazen sorun yaratmaz. Fazlalığı azaltmak için, kullanıcı arayüzünün tam erişime izin verdiği küçük, odaklanmış iş katmanı nesneleri olabilir.

Kullanıcı arayüzünün iş nesnelerinden ihtiyaç duyduğu her şey ve her şey API'lenmelidir. Örneğin, bağımsız değişkenlerini olay işleyicilerine bağlayan açık yöntemler vardır.

Koltuk değneği olarak çerçevelere dikkat edin

Vasıfsızların elinde, çerçeveler ve IDE'ler yarattıkları B-film canavarlarının önünde engel oluşturmazlar.

React gibi çerçevelerle, her şeyin istemci tarafı olduğunu söyleyebilirsiniz, arka uç iş mantığı katmanı yoktur. Buradaki ana fikir, kullanıcının gördüklerini programın yaptıklarından ayırmaktır. Bu yapılabilir. Sadece fiziksel bir sunucu vs kullanıcıların tarayıcı şey değil.

Bence bu, tasarım yapamayan insanların yapamayacağını kabul ettiğimiz, meslek ve uygulamadaki olgunlaşmamışlığın iyi bir göstergesi.

Bu neredeyse başka bir meslekte kabul edilemez.

Web sitesi / uygulama tasarımı konusunda uzmanlaşmış bir tasarımcının CSS ve HTML'yi size bu tür çalışan ve kullanılabilir dosyalar sağlayacak kadar iyi bilmesini beklemek mantıklıdır.

WYSIWYG grafik editörleri sunan tasarımcı görsel veya grafik tasarımcıdır. Birçok farklı tasarımcı var.

Bununla birlikte, birçok farklı beceri seviyesi, yetenek ve deneyim de vardır. Mobilya tasarlayan kişi bunu sadece 3B tasarım araçları olan bir bilgisayarda yapabilir, bu durumda bir torna tezgahının nasıl döndürüleceği veya bir CNC yönlendiricinin nasıl çalıştırılacağı konusundaki bilgileri tamamen teorik olabilir. Tasarımlarını yaparlar ve sonra başkaları tarafından yapılması için gönderirler.

Tersine, bazı uzman tasarımcılar tüm süreç üzerinde kontrole sahip olabilir ve mobilyalarını her ayrıntıya, hatta el işçiliğine bakacak şekilde inşa etme yeteneğine ve bilgisine sahip olabilir.

Arkadaşınızı çalışma şeklini değiştirmeye ikna edemezsiniz. Kendi tasarımlarını oluşturmak için HTML ve CSS becerilerine sahip bir web tasarımcısına sahip olmayı tercih ederseniz, bir tane bulmanız gerekecektir.