Tasarımcılar Kodlamayı Nasıl Öğrenmeli? Git, HTML/CSS, Mühendislik İlkeleri (Bölüm 2)

Kelimenin tam anlamıyla, sürüm kontrolü üzerine ciltler yazılmıştır. Yine de, daha fazla çalışma isteğinizi uyandırmak için kısa bir açıklama ve diğer giriş içeriğini paylaşarak başlayacağım.

Sürüm kontrolü ( sürüm geçmişi ile karıştırılmamalıdır) temel olarak, insanların kendi ortamlarında tek bir proje üzerinde, tek bir ana kaynak (genellikle "ana" dal olarak adlandırılır) ile işbirliği yapmalarının bir yoludur.

Bugün üzerinden geçeceğim, bir projeyi indirmek, bir değişiklik yapmak ve sonra onu master'a göndermek için bilmeniz gereken minimum şey.

Kaynak kodunuzu yönetmek ve barındırmak için birçok sürüm kontrol yazılımı türü ve birçok araç vardır (GitLab veya Bitbucket'i duymuş olabilirsiniz). Git ve GitHub en yaygın çiftlerden biridir, benim örneklerim GitHub'a atıfta bulunacaktır ancak ilkeler diğer kaynak kod yöneticilerinin çoğu için geçerli olacaktır.

Kenara :

• Daha kapsamlı ve teknik bir giriş için Tobias Gunther'in makalesine bakın.
• Daha uygulamalı bir yaklaşımı tercih ederseniz, GitHub'ın adım adım mükemmel bir kılavuzu vardır.

İlk Katkınız

Bu adımları uygulamadan önce, birkaç şeyin ayarlanması gerekir:

1. GitHub hesabı,
2. Bilgisayarınızda yüklü olan düğüm ve NPM,
3. Acıya karşı yüksek tolerans veya başkalarından yardım istemek için düşük bir eşik.

Adım 1: Fork (GitHub Hesabınızdaki Kodun Bir Kopyasını Alın)

GitHub'da, söz konusu depoyu ( fork = hesabınızdaki kodun bir kopyasını oluşturun; aşağıdaki çizimde mavi, turuncu, kırmızı ve yeşil çizgiler çatalları gösterir) çatallayacaksınız.

Bunu GitHub'daki depoya giderek ve şu anda bir deponun sağ üst köşesinde bulunan "Çatal" düğmesine tıklayarak yapabilirsiniz. Bu "köken" olacaktır - GitHub hesabınızdaki çatalınız.

Örnek olarak, https://github.com/yourGitHubUsername/liferay.design adresine gitmek Liferay.Design deposundaki çatalınızı göstermelidir.

2. Adım: Klonlayın (Kodu Bilgisayarınıza İndirin)

Terminalinizde, kodu saklamak istediğiniz yere gidin. Şahsen, /user klasörümde /github klasörüm var - bu şekilde düzenlememi kolaylaştırıyor. Bunu yapmak isterseniz, işte adımlar - bu komutları terminal pencerenize yazdıktan sonra yürütmek için ↵ tuşuna basın:

 cd ~/ ## you'll usually start in your root directory, but just in case you don't this will take you there mkdir github ## this creates a "github" folder — on OSX it will now be located at users/your-username/github cd github ## this command navigates you inside the github folder

Artık /github klasöründe olduğunuza göre, depoyu klonlayacaksınız (kodun bir kopyasını bilgisayarınıza indireceksiniz).

 clone https://github.com/yourGitHubUsername/liferay.design

Bu komutu girdikten sonra, terminalde bir grup aktivite göreceksiniz - bunun gibi bir şey:

 Cloning into 'liferay.design'... remote: Enumerating objects: 380, done. remote: Total 380 (delta 0), reused 0 (delta 0), pack-reused 380 Receiving objects: 100% (380/380), 789.24 KiB | 2.78 MiB/s, done. Resolving deltas: 100% (189/189), done.

3. Adım: Kurun (Makinenizde Çalıştırın)

/project klasörüne gidin. Bu durumda cd liferay.design . Çoğu proje /root klasöründe bir README.md dosyası içerecektir, bu genellikle projeyi kurmak ve çalıştırmak için başlangıç ​​noktasıdır. Bizim amaçlarımız için, yüklemek için npm install girin. Kurulduktan sonra npm run dev .

Tebrikler! Artık yerel bilgisayarınızda siteye sahipsiniz - genellikle projeler size sitenin nerede çalıştığını söyleyecektir. Bu durumda, bir tarayıcı açın ve localhost:7777 adresine gidin.

Adım 4: Taahhüt (Bazı Değişiklikler Yapın ve Bunları Kaydedin)

Taahhüt, yaptığınız değişikliklerin bir koleksiyonudur; Bir oyunda ilerlemenizi kaydetmek olarak tanımlandığını duydum. Taahhütlerin nasıl yapılandırılması gerektiğine dair birçok görüş var: benimki, bir şeyi başardığınızda bir taahhüt oluşturmanız gerektiği ve taahhüdü kaldıracak olsaydınız, projeyi (sebep dahilinde) tamamen bozmazdı.

Bir depoya fikir değişikliği ile gelmiyorsanız, gitmek için iyi bir yer 'Sorunlar' sekmesidir. Projede yapılması gerekenleri buradan görebilirsiniz.

Biraz değişiklik için bir fikriniz varsa, devam edin ve yapın. Dosyaları kaydettikten sonra, bir taahhüt oluşturmak için gereken adımlar şunlardır:

 git status ## this will print out a list of files that you've made changes in git add path/to/folder/or/file.ext ## this will add the file or folder to the commit git commit -m 'Summarize the changes you've made' ## this command creates a commit and a commit message

İpucu : Taahhüt mesajları için şimdiye kadar gördüğüm en iyi öneri Chris Breams'in “Git Taahhüt Mesajı Nasıl Yazılır”dan. Düzgün oluşturulmuş bir Git taahhüt konu satırı her zaman şu cümleyi tamamlayabilmelidir: "Uygulanırsa, bu taahhüt [konu satırınız burada] olacaktır." Taahhütler hakkında daha fazla bilgi için Clarice Bouwer tarafından yazılan "Neden Git'te Atomik Taahhütler Oluşturuyorum" bölümüne bakın.

Adım 5: Push (Değişikliklerinizi Origin'inize Gönderin)

Bilgisayarınızda bazı değişiklikler yaptıktan sonra, bunların ana dalda birleştirilmeden (projeye eklenmeden) önce, yerel deponuzdan uzak deponuza taşınmaları gerekir. Bunu yapmak için komut satırına git push origin girin.

Adım 6: Çekme Talebi (Değişikliklerinizin Yukarı Akışla Birleştirilmesini İsteyin)

Değişiklikleriniz parmaklarınızdan bilgisayarınıza, uzak deponuza geçtiğine göre, şimdi bunların bir çekme talebi (PR) yoluyla projeyle birleştirilmesini istemenin zamanı geldi.

Bunu yapmanın en kolay yolu, Repo'nuzun GitHub'daki sayfasına gitmektir. Dosya penceresinin hemen üzerinde "Bu dal X taahhüt ileri repo-adı:dal" yazan ve ardından "Talebi çek" veya "Karşılaştır" seçeneklerini yazan küçük bir mesaj olacaktır.

Buradaki “Pull request” seçeneğine tıklamak sizi değişiklikleri karşılaştırabileceğiniz bir sayfaya götürecek ve “Create request” yazan bir buton sizi başlık ekleyeceğiniz “Pull request” sayfasına götürecektir. ve bir yorum ekleyin. Kısa, ancak yorumda yeterince ayrıntılı olmak, proje yürütücülerin önerilen değişiklikleri anlamalarına yardımcı olacaktır.

Terminalde çekme isteklerini başlatmanıza ve yönetmenize izin veren Node GH (GitHub ayrıca yakın zamanda CLI araçlarının bir beta sürümünü yayınladı) gibi CLI araçları vardır. Bu noktada web arayüzünü kullanmayı tercih edebilirsiniz ve bu harika! Ben de.

Bonus Adım: Uzak (Tüm Depoları Bağlayın)

Bu noktada, üç depo referansımız var:

1. upstream : takip ettiğiniz ana depo, genellikle çatalladığınız depodur;
2. origin : klonladığınız uzaktan kumandanın varsayılan adı;
3. local : şu anda bilgisayarınızda bulunan kod.

Şimdiye kadar, 2 ve 3 numaranız var - ancak 1 numara önemlidir çünkü birincil kaynaktır. Bu üç şeyi birbiriyle uyumlu tutmak, taahhüt geçmişinin temiz kalmasına yardımcı olacaktır. Bu, çekme istekleri (PR'ler) gönderdiğinizde birleştirme çakışmalarını ortadan kaldırdığı (veya en azından en aza indirdiği) için proje yürütücülerine yardımcı olur ve en son kodu almanıza ve yerel ve kaynak depolarınızı güncel tutmanıza yardımcı olur.

Yukarı Yönde Bir Uzaktan Kumanda Ayarlayın

Yukarı akış uzaktan kumandasını izlemek için terminalinize aşağıdakileri girin:

 git remote add upstream https://github.com/liferay-design/liferay.design

Şimdi, hangi uzaktan kumandalara sahip olduğunuzu kontrol edin - terminalinize git remote -v yazın, şöyle bir şey görmelisiniz:

 origin https://github.com/yourGitHubUsername/liferay.design (fetch) origin https://github.com/yourGitHubUsername/liferay.design (push) upstream https://github.com/liferay-design/liferay.design (fetch) upstream https://github.com/liferay-design/liferay.design (push)

Bu, yukarı yönde olanın en son sürümünü hızlı bir şekilde almanızı sağlar - uzun süredir bir depoda çalışmadıysanız ve saklamak istediğiniz herhangi bir yerel değişiklik yoksa, bu benim kullandığım kullanışlı bir komuttur. :

 git pull upstream master && git reset --hard upstream/master

GitHub Yardım, bu ve aklınıza gelebilecek diğer birçok soru için harika bir kaynaktır.

HTML ve CSS: Semantikle Başlamak

Web'de HTML ve CSS öğrenmek için sonsuz kaynak var. Bu makalenin amaçları doğrultusunda, tavsiye edebileceğim şeyleri paylaşıyorum. yaptığım hatalar HTML ve CSS yazmayı ilk nasıl öğrendim.

Html-ve-css-nedir?

Daha fazla ilerlemeden önce, HTML ve CSS'yi tanımlayalım.

HTML, Köprü Metni İşaretleme Dili anlamına gelir.

Köprü metni:

“Köprü metin, okuyucunun hemen erişebileceği diğer metne referanslar (köprüler) içeren bir bilgisayar ekranında veya diğer elektronik cihazlarda görüntülenen metindir.”

- Wikipedia'da "Köprü"

İşaretleme Dili:

“…bir belgeye metinden sözdizimsel olarak ayırt edilebilecek şekilde açıklama eklemek için bir sistem.”

- Wikipedia'da "İşaretleme Dili"

Bu kelimelerin çoğunun ne anlama geldiğini de bilmiyorsanız - kısaca söylemek gerekirse, HTML web'deki belgeler arasındaki referansların (bağlantıların) ve bu belgelere yapı vermek için kullandığınız etiketlerin birleşimidir.

HTML ve CSS'ye kapsamlı bir giriş için, her ikisi de Mozilla Developer Network (MDN) web belgelerinde bulunan HTML ve CSS'ye Giriş ilk adımlarını şiddetle tavsiye ederim. Bu, CSS Tricks, 24 Ways ve sayısız diğerleri gibi web sitelerinin sağladığı mükemmel makalelerin yanı sıra, HTML/CSS ile ilgili olarak başvurmanız gereken her şeyi içerir.

Bir HTML belgesinin iki ana bölümü vardır: <head> ve <body> . - <head> , tarayıcı tarafından görüntülenmeyen şeyleri içerir - meta veriler ve içe aktarılan stil sayfalarına ve komut dosyalarına bağlantılar. - <body> , tarayıcı tarafından oluşturulacak gerçek içeriği içerir. İçeriği oluşturmak için tarayıcı HTML'yi okur, kullanılan etiket türlerine bağlı olarak bir temel stil katmanı sağlar, web sitesinin kendisi tarafından sağlanan ek stil katmanları ekler (stiller <head> öğesinde bulunur/buradan başvurulur veya satır içi) ve sonunda gördüğümüz şey bu. (Not: Genellikle JavaScript'in ek katmanı da vardır ancak bu, bu makalenin kapsamı dışındadır.)

CSS , Basamaklı Stil Sayfaları anlamına gelir - belgelere özel bir görünüm ve his vermeyi kolaylaştırarak HTML'yi genişletmek için kullanılır. Stil sayfası, etiketleri, sınıfları, kimlikleri ve diğer seçicileri temel alan kurallar ayarlayarak HTML'ye öğelerin nasıl görünmesi gerektiğini (ve nasıl konumlandırılması gerektiğini) söyleyen bir belgedir. Basamaklama , kaçınılmaz bir kural çakışması durumunda, bir sayfadaki hangi kuralların öncelikli olduğunu belirleme yöntemini ifade eder.

“'Basamaklama', stillerin bir stil sayfasından diğerine düşebileceği (veya kademeli olarak düzenlenerek), bir HTML belgesinde birden çok stil sayfasının kullanılmasına olanak tanıdığı anlamına gelir.

— Kademeli — Maks Tasarım

CSS genellikle kötü bir üne sahiptir - çok sayıda stil sayfası içeren sitelerde, özellikle belgelenmiş, tutarlı yöntemler kullanılmamışsa (daha sonra daha fazlası) - hızlı bir şekilde hantal hale gelebilir - ancak onu düzenli bir şekilde kullanırsanız ve hepsini takip ederseniz en iyi uygulamalar, CSS en iyi arkadaşınız olabilir. Özellikle artık çoğu modern tarayıcıda bulunan düzen yetenekleriyle, CSS bir zamanlar olduğu gibi hacklemek ve savaşmak için neredeyse gerekli değildir.

Rachel Andrew, CSS Nasıl Öğrenilir adlı harika bir kılavuz yazdı ve başlamadan önce bilmeniz gereken en iyi şeylerden biri şudur:

"Her CSS Özelliğini ve Değerini ezberlemenize gerek yok."

-Rachel Andrew

Bunun yerine, seçiciler, kalıtım, kutu modeli ve en önemlisi CSS kodunuzda nasıl hata ayıklayacağınız gibi temel bilgileri öğrenmek çok daha önemlidir (ipucu: tarayıcı geliştirici araçlarına ihtiyacınız olacaktır).

background özelliğinin sözdizimini ezberleme konusunda endişelenmeyin ve Flexbox'ta öğeleri tam olarak nasıl hizalayacağınızı unutursanız da endişelenmeyin (Flexbox için CSS Püf Noktaları Kılavuzu muhtemelen şimdiye kadar en çok ziyaret edilen 10 sayfamdan biridir! ); Google ve Stack Overflow, CSS özellikleri ve değerleri söz konusu olduğunda arkadaşlarınızdır.

Hatta bazı kod düzenleyicilerde yerleşik otomatik tamamlama özelliği vardır, bu nedenle örneğin bir sınırın tüm olası özelliklerini anlayabilmek için web'de arama yapmanız bile gerekmez.

Firefox 70'teki en sevdiğim yeni özelliklerden biri, etkin olmayan CSS kuralları göstergesidir. Bir stilin neden uygulanmadığını anlamaya çalışırken size saatler kazandıracak.

anlambilim

Anlamsal kodla başlayalım. Semantik, kelimelerin anlamlarını ifade eder, semantik kod, herhangi bir dilde işaretlemenin anlamı olduğu fikrini ifade eder.

Semantiğin önemli olmasının birçok nedeni vardır. Bunu özetleyecek olursam, semantik kodu öğrenir ve kullanırsanız, hayatınızı çok daha kolay hale getireceğini söyleyebilirim çünkü birçok şeyi ücretsiz alacaksınız - ve kim ücretsiz şeyleri sevmez ki?

Anlamsal koda daha eksiksiz bir giriş için, Paul Boag'ın konuyla ilgili kısa blog gönderisine bakın.

Semantik size birçok fayda sağlar:

1. Varsayılan stiller
   Örneğin, belgenizin başlığı için <h1> bir başlık etiketi kullanmak, tıpkı bir başlığın yapacağı gibi, belgenizin geri kalan içeriğinden farklı olmasını sağlar.
2. Erişilebilir içerik
   Kodunuza varsayılan olarak erişilebilir olacak, yani ekran okuyucularla çalışacak ve bir klavyeyle gezinmek daha kolay olacak.
3. SEO faydaları
   Semantik işaretleme, bir makinenin okuması daha kolaydır, bu da onu arama motorları için daha erişilebilir hale getirir.
4. Performans avantajları
   Temiz HTML, yüksek performanslı bir sitenin temelidir. Ayrıca temiz HTML, büyük olasılıkla daha temiz CSS'ye yol açacaktır, bu da genel olarak daha az kod anlamına gelir ve sitenizi veya uygulamanızı daha hızlı hale getirir.

Not: Anlambilim ve HTML'ye daha derinlemesine bakmak için Heydon Pickering, okumanızı şiddetle tavsiye ettiğim "Yapısal Anlambilim: HTML5 Bölümleme Öğelerinin Önemi"ni yazdı.

Mühendislik İlkeleri ve Paradigmalar: Temel Bilgiler

Soyutlama

Soyutlama kavramı üzerinde keşfedebileceğimiz tonlarca uygulama, teğet ve seviye var - öğrenmeye devam ederken bunların farkında olmanız için size kavramlara kısa bir giriş yapmayı amaçlayan bu makale için çok fazla.

Soyutlama, çok çeşitli uygulamalara sahip temel bir mühendislik paradigmasıdır - bu makalenin amaçları doğrultusunda soyutlama, formu işlevden ayırmaktır. Bunu üç alanda uygulayacağız: belirteçler, bileşenler ve Kendinizi Tekrar Etme ilkesi.

Jetonlar

Herhangi bir süre için modern bir tasarım aracı kullandıysanız, muhtemelen bir token fikriyle karşılaşmışsınızdır. Photoshop ve Illustrator'da bile artık merkezi bir kitaplıkta paylaşılan stiller fikri var - değerleri bir tasarıma sabit kodlamak yerine bir simge kullanıyorsunuz. CSS veya SASS değişkenleri kavramına aşinaysanız, belirteçlere zaten aşinasınızdır.

Belirteçlerle bir soyutlama katmanı, bir renge bir ad atamaktır - örneğin, $blue-00 bir onaltılık değere (veya bir HSL değerine veya ne isterseniz) eşlenebilir - diyelim ki #0B5FFF . Şimdi, stil sayfalarınızda onaltılık değeri kullanmak yerine belirteç değerini kullanırsınız - bu şekilde blue-00 00'ün aslında #0B36CE olduğuna karar verirseniz, onu yalnızca tek bir yerde değiştirmeniz gerekir. Bu güzel bir konsept.

Aynı soyutlama paradigmasını alır ve bir katman daha ileri giderseniz, belirteç algılaması yapabilir ve işlevsel bir değere bir değişken atayabilirsiniz. Bu, özellikle sağlam bir sisteminiz varsa ve sistem içinde farklı temalara sahip olmak istiyorsanız kullanışlıdır. Bunun işlevsel bir örneği, $primary-color gibi bir değişkeni atamak ve bunu $blue-00 eşlemek olabilir - böylece artık işaretleme oluşturabilirsiniz ve maviye atıfta bulunmak yerine bir işlevsel değişkene atıfta bulunuyorsunuz. Aynı işaretlemeyi farklı bir stille (tema) kullanmak isterseniz, yalnızca $primary-color yeni bir renge eşlemeniz gerekir ve işaretlemenizin hiç değişmesi gerekmez! Büyü!

Bileşenler

Son 3-4 yılda, bileşenler ve bileşenleştirme fikri tasarımcılar için daha alakalı ve erişilebilir hale geldi. Sembol kavramı (Macromedia/Adobe Fireworks tarafından öncülük edildi, daha sonra Sketch tarafından genişletildi ve daha sonra Figma ve Framer tarafından bir sonraki düzeye taşındı) artık çoğu tasarım aracında (Adobe XD, InVision Studio, Webflow ve diğer birçok) daha yaygın olarak kullanılabilir. diğerleri). Bileşenleştirme, belirteçlerden bile daha fazla, bir şeyin biçimini işlevinden ayırabilir - bu da hem biçimin hem de işlevin geliştirilmesine yardımcı olur.

Daha dikkate değer erken örneklerden biri, Nicole Sullivan'ın medya nesnesi bileşenidir. İlk bakışta, bütün bir sayfanın temelde farklı şekillerde oluşturulmuş tek bir bileşenden oluştuğunu fark etmeyebilirsiniz. Bu şekilde, aynı işaretlemeyi (formu) yeniden kullanabilir, seçenekler, parametreler ve stiller ileterek biraz değiştirerek - ve çeşitli değerler (fonksiyon) sağlamasını sağlayabiliriz.

Kendinizi Tekrar Etmeyin

KURU (Kendini Tekrar Etme) en sevdiğim ilkelerden biridir — tekrar tekrar kullanılabilecek şeyler yaratmak, kodlama yaparken elde edebileceğiniz küçük zaferlerden biridir.

Çoğu zaman DRY ilkesini her zaman %100 uygulamak için çaba gösteremeseniz de (ve muhtemelen yapmamalısınız) - en azından bunun farkında olmak faydalıdır, böylece çalışırken, nasıl yapacağınızı düşünebilirsiniz. üzerinde çalıştığınız her şeyi yeniden kullanılabilir hale getirebilir.

Üçlü Kural hakkında bir not: DRY ilkesinin bir sonucu, üç kuralıdır - esasen, bir şeyi üç kez yeniden kullandığınızda (kopyala/yapıştır), onu yeniden kullanılabilir bir bileşene yeniden yazmalısınız. Korsan Kuralları gibi, katı ve hızlı bir kuraldan çok bir kılavuzdur ve bileşenden bileşene ve projeden projeye değişebilir.

CSS ve Şekillendirme Metodolojileri: Atomik vs. BEM

CSS kodunu düzenlemenin ve yazmanın birçok farklı yolu vardır - Atomic ve BEM, karşılaşabileceğiniz birçok yöntemden yalnızca ikisidir. Tek bir tanesini “seçmek” veya tam olarak takip etmek zorunda değilsiniz. Çalıştığım ekiplerin çoğu, projeye veya teknolojiye dayalı olarak genellikle kendi benzersiz karışımlarına sahiptir. Zaman içinde duruma bağlı olarak hangi yaklaşımı izleyeceğinizi öğrenebilmeniz için onlara aşina olmak yararlıdır.

Tüm bu yaklaşımlar "sadece" CSS ve stilin ötesine geçer ve sıklıkla kullandığınız araçları, dosyalarınızı düzenleme şeklinizi ve potansiyel olarak işaretlemeyi etkileyebilir.

atomik CSS

Atomik Web Tasarımı ile karıştırılmaması gereken - atom (belki de daha uygun bir şekilde "işlevsel" olarak anılır) CSS, görsel işlevleri tanımlamak için esasen küçük, tek amaçlı sınıfları kullanmayı tercih eden bir metodolojidir. Birkaç önemli kitaplık:

1. Steve Carlson'dan Atomik CSS;
2. Adam Morse tarafından Takyonlar;
3. Adam Wathan'dan Tailwind CSS.

Bu yöntemle ilgili sevdiğim şey, şeyleri hızlı bir şekilde şekillendirmenize ve temalandırmanıza izin vermesidir - en büyük dezavantajlardan biri, işaretlemenizin oldukça karmaşık, oldukça hızlı olabilmesidir.

Atomic CSS'ye tam bir giriş için John Polacek'in CSS hileleri hakkındaki makalesine bakın.

BEM

BEM felsefesi, Angular, React ve Vue gibi birçok modern JavaScript çerçevesinin büyük bir öncüsüdür.

“BEM (Block, Element, Modifier), web geliştirme için bileşen tabanlı bir yaklaşımdır.”

— BEM: Hızlı Başlangıç

Temel olarak, yeniden kullanılabilen her şey bir bloktur. Bloklar, bir bloğun dışında kullanılamayan öğelerden ve potansiyel olarak diğer bloklardan oluşur. Değiştiriciler, bir şeyin durumunu veya nasıl göründüğünü veya nasıl davrandığını tanımlayan şeylerdir.

Şahsen, BEM'in teorisini ve felsefesini seviyorum. Sevmediğim şey, şeylerin adlandırılma şekli. Çok fazla alt çizgi, kısa çizgi var ve gereksiz yere tekrar ediyormuş gibi görünebilir ( .menu , .menu__item , vb.).

Önerilen okuma : Inna Belaya tarafından yazılan BEM Yeni Başlayanlar İçin

Teşekkürler U, Sonraki(.js)

Bu konulara yeterince hakim olduktan sonra merak etmeyin, daha öğrenecek çok şey var. Bazı öneriler:

1. Fonksiyonel ve nesne yönelimli programlama
   Hafifçe değindik, ancak CSS'nin ötesinde öğrenilecek daha çok şey var.
2. Daha yüksek seviyeli diller ve çerçeveler
   TypeScript, Ruby, React, Vue, HTML ve CSS'yi güçlü bir şekilde kavradıktan sonra ele alacağınız sonraki şeylerdir.
3. Dilleri sorgulama ve verileri kullanma
   GraphQL, MySQL, REST API'leri hakkında bilgi edinmek, kodlama yeteneğinizi bir sonraki seviyeye taşıyacaktır.

Sonuç: Kod Yazan Tasarımcılar != Yazılım Mühendisleri

Umarım bu makale size kodlamayı öğrenmenin daha önce düşündüğünüz kadar zor olmadığını göstermiştir. Çok zaman alabilir, ancak internette mevcut kaynakların miktarı şaşırtıcı ve azalmıyorlar - tam tersi!

Vurgulamak istediğim önemli bir nokta, "kodlamanın" "yazılım mühendisliği" ile aynı şey olmadığıdır - bir depoyu çatallayabilmek ve Stack Overflow'tan kodda kopyalayıp/yapıştırabilmek size uzun bir yol kat edebilir ve çoğu, eğer hepsi değil, bildiğim yazılım mühendisleri bunu yaptı - yeni edindiğiniz becerilerinizi bilgelik ve alçakgönüllülükle kullanmalısınız. Artık biraz mühendislik becerisiyle erişebileceğiniz her şey için, bilmediğiniz çok daha fazlası var. Bir özelliği veya stili gerçekleştirmenin kolay olduğunu düşünebilirsiniz, çünkü — "Hey, onu devtools'ta çalıştırdım!" veya "Codepen'de çalışmasını sağladım." — muhtemelen bilmediğiniz ve bilmediğiniz birçok mühendislik süreci, bağımlılık ve yöntem vardır.

Tüm bunlar, bizim hala tasarımcı olduğumuzu unutmayın. Birincil işlevimiz, müşteri veya kullanıcı sorunlarını anlamak ve bunları tasarım kalıpları, yöntemleri ve süreçleri konusundaki bilgimizle sentezleyerek iş değeri katmaktır. Evet, "kod yazan bir tasarımcı" olmak çok faydalı olabilir ve bu değeri ekleme yeteneğinizi genişletecektir - ancak yine de mühendislerin mühendislik kararlarını vermesine izin vermemiz gerekiyor.

Eksik bir şey var mı?

Bu gönderideki bir şeyin belirsiz, geniş ve/veya modası geçmiş olması için iyi bir şans var ve bunu daha iyi hale getirme fırsatını çok isterim! Lütfen aşağıya bir yorum bırakın, bana DM atın veya Twitter'da benden @bahsedin, böylece kendimi geliştirebilirim.

Daha fazla okuma

1. Kodlama Eğitim Kampları ve Bilgisayar Bilimi Dereceleri: İşverenlerin İstedikleri ve Diğer Perspektifler (Kyle Thayer)
2. Sketch ve Framer X'i Kullanmaya Nasıl Başlanır (Martina Perez, Smashing Magazine )
3. Linux Komutlarına Giriş (Paul Tero, Smashing Magazine )
4. Oh My ZSH ve Z ile Komut Satırında Yetkili Kullanıcı Olun (Wes Bos, Smashing Magazine tarafından)
5. PowerShell'de kullanabileceğiniz ortak cmd.exe ve Unix komutlarının listesi ( Microsoft Docs )
6. normal-expressions.info (Jan Goyvaerts tarafından)
7. regexone.com (basit etkileşimli alıştırmalarla düzenli ifadeleri öğrenin)
8. Komut Satırı ve ImageMagick Kullanarak Toplu Yeniden Boyutlandırma (Vlad Gerasimov, Smashing Magazine )
9. Sublime Text ile Verimliliğinizi Artırmak İçin Kısayollar ve İpuçları (Jai Pandya, Smashing Magazine tarafından)
10. Visual Studio Kodu Bunu Yapabilir mi? (Burke Holland, Smashing Magazine tarafından)
11. Sürüm geçmişi neden sürüm kontrolü değil (Josh Brewer tarafından)
12. Git ile Modern Versiyon Kontrolü (Tobias Gunther, Smashing Magazine )
13. "Merhaba Dünya" (adım adım GitHub kılavuzu)
14. Mac'te Node.js ve NPM Nasıl Kurulur (Dave McFarland tarafından)
15. Windows'ta Node.js ve NPM Nasıl Kurulur (Dejan Tucakov tarafından)
16. Neden Git'te Atomik Taahhütler Oluşturuyorum (Clarice Bouwer tarafından)
17. Git Taahhüt Mesajı Nasıl Yazılır (Chris Breams tarafından)
18. Semantik kod: Ne? Niye ya? Nasıl? (Paul Boag tarafından)
19. Yapısal Semantik: HTML5 Bölümleme Öğelerinin Önemi (Heydon Pickering, Smashing Magazine tarafından)
20. Performans için Tasarlama: Bölüm 4. İşaretleme ve Stilleri Optimize Etme (Lara C. Hogan, O'Reilly Media tarafından)
21. Medya nesnesi yüzlerce kod satırı kaydeder (Nicole Sullivan tarafından)
22. Atomik CSS'nin Ne Olduğunu Tam Olarak Tanımlayalım (John Polacek, CSS Tricks )
23. Yeni Başlayanlar İçin BEM: Neden BEM'e İhtiyacınız Var (Inna Belaya, Smashing Magazine )
24. Kediler için Javascript: Yeni Programcılar İçin Bir Giriş
25. Roadmap.sh: Ön Uç Geliştirici
26. Fonksiyonel Programlama vs OOPS: Beş Yaşım Gibi Açıklayın
27. Semantik HTML ve ARIA Neden, Nasıl ve Ne Zaman Kullanılmalı (Adam Silver, CSS Tricks )
28. HTML Semantics ( Smashing Magazine tarafından hazırlanan bir e-Kitap)
29. Temel Bilgiler - HTML + CSS ( Syntax.fm'de )
30. Cascade ve kalıtım ( westciv.com )
31. CSS Püf Noktaları (Chris Coyier tarafından)
32. CSS Düzenine Başlarken (Rachel Andrew, Smashing Magazine tarafından)
33. HTML'ye Giriş (MDN web belgeleri)
34. CSS ilk adımları (MDN web belgeleri)
35. JavaScript İlk Adımları (MDN web belgeleri)
36. 24 Yol (Drew McLellan tarafından)