Bagaimana Seharusnya Desainer Belajar Membuat Kode? Git, HTML/CSS, Prinsip Teknik (Bagian 2)

Secara harfiah, buku-buku tebal telah ditulis pada kontrol versi. Namun demikian, saya akan mulai dengan berbagi penjelasan singkat dan konten pengantar lainnya untuk membangkitkan selera Anda untuk studi lebih lanjut.

Kontrol versi (jangan bingung dengan riwayat versi ) pada dasarnya adalah cara bagi orang untuk berkolaborasi di lingkungan mereka sendiri dalam satu proyek, dengan satu sumber kebenaran utama (sering disebut cabang "master").

Saya akan membahas hari ini adalah minimum yang perlu Anda ketahui untuk mengunduh proyek, membuat perubahan, dan kemudian mengirimkannya ke master.

Ada banyak jenis perangkat lunak kontrol versi dan banyak alat untuk mengelola dan menghosting kode sumber Anda (Anda mungkin pernah mendengar tentang GitLab atau Bitbucket). Git dan GitHub adalah salah satu pasangan yang lebih umum, contoh saya akan merujuk GitHub tetapi prinsipnya akan berlaku untuk sebagian besar pengelola kode sumber lainnya.

Selain :

• Untuk pengenalan yang lebih komprehensif dan teknis, lihat artikel Tobias Gunther.
• Jika Anda lebih suka pendekatan yang lebih praktis, GitHub memiliki panduan langkah demi langkah yang sangat baik.

Kontribusi Pertama Anda

Sebelum melakukan langkah-langkah ini, Anda perlu menyiapkan beberapa hal:

1. Akun GitHub,
2. Node dan NPM terinstal di komputer Anda,
3. Toleransi yang tinggi terhadap rasa sakit atau ambang batas yang rendah untuk meminta bantuan orang lain.

Langkah 1: Fork (Dapatkan Salinan Kode Di Akun GitHub Anda)

Di GitHub, Anda akan melakukan fork (fork = membuat salinan kode di akun Anda; dalam ilustrasi berikut, garis biru, oranye, merah, dan hijau menunjukkan fork) repositori (repo) yang bersangkutan.

Anda melakukan ini dengan menavigasi ke repo di GitHub dan mengklik tombol "Fork", saat ini di sudut kanan atas repo. Ini akan menjadi "asal" — garpu Anda di akun GitHub Anda.

Sebagai contoh, menavigasi ke https://github.com/yourGitHubUsername/liferay.design harus menunjukkan cabang repo Liferay.Design Anda.

Langkah 2: Klon (Unduh Kode Ke Komputer Anda)

Di terminal Anda, navigasikan ke tempat Anda ingin menyimpan kode. Secara pribadi, saya memiliki folder /github di folder /user saya — memudahkan saya untuk mengaturnya dengan cara ini. Jika Anda ingin melakukannya, berikut langkah-langkahnya — setelah mengetikkan perintah ini ke jendela terminal Anda, tekan tombol untuk menjalankan:

 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

Sekarang Anda berada di folder /github , Anda akan mengkloning (mengunduh salinan kode ke komputer Anda) repo.

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

Setelah Anda memasukkan perintah ini, Anda akan melihat banyak aktivitas di terminal — sesuatu seperti ini:

 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.

Langkah 3: Instal (Jalankan di Mesin Anda)

Arahkan ke folder /project . Dalam hal ini, kita akan memasukkan cd liferay.design . Sebagian besar proyek akan menyertakan file README.md di folder /root , ini biasanya merupakan tempat awal untuk menginstal dan menjalankan proyek. Untuk tujuan kami, untuk menginstal, masukkan npm install . Setelah terinstal, masukkan npm run dev .

Selamat! Anda sekarang memiliki situs yang tersedia di komputer lokal Anda — biasanya proyek akan memberi tahu Anda di mana situs itu berjalan. Dalam hal ini, buka browser dan buka localhost:7777 .

Langkah 4: Komit (Buat Beberapa Perubahan Dan Simpan Mereka)

Komit adalah kumpulan perubahan yang Anda buat; Saya pernah mendengarnya digambarkan sebagai menyimpan kemajuan Anda dalam permainan. Ada banyak pendapat tentang bagaimana komit harus disusun: pendapat saya adalah Anda harus membuat komit ketika Anda telah mencapai satu hal, dan jika Anda menghapus komit, itu tidak akan sepenuhnya merusak proyek (dengan alasan).

Jika Anda tidak datang ke repo dengan perubahan pikiran, tempat yang baik untuk pergi adalah tab 'Masalah'. Di sinilah Anda dapat melihat apa yang perlu dilakukan dalam proyek.

Jika Anda memiliki ide untuk beberapa perubahan, lakukanlah. Setelah Anda menyimpan file, berikut adalah langkah-langkah yang diperlukan untuk membuat komit:

 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

Tip : Rekomendasi terbaik yang pernah saya lihat untuk pesan komit adalah dari "Cara Menulis Pesan Komit Git" dari Chris Breams. Baris subjek komit Git yang dibentuk dengan benar harus selalu dapat melengkapi kalimat berikut: "Jika diterapkan, komit ini akan [baris subjek Anda di sini]." Untuk info lebih lanjut tentang commit, lihat “Mengapa Saya Membuat Atomic Commits In Git” oleh Clarice Bouwer.

Langkah 5: Dorong (Kirim Perubahan Anda Ke Asal Anda)

Setelah Anda membuat beberapa perubahan di komputer Anda, sebelum mereka dapat digabungkan ke dalam cabang master (ditambahkan ke proyek), mereka harus dipindahkan dari lokal Anda ke repo jarak jauh Anda. Untuk melakukan ini, masukkan git push origin di baris perintah.

Langkah 6: Tarik Permintaan (Minta Perubahan Anda Untuk Digabungkan Menjadi Upstream)

Sekarang perubahan Anda telah berpindah dari jari Anda ke komputer Anda, ke repositori jarak jauh Anda — sekarang saatnya meminta mereka untuk digabungkan ke dalam proyek melalui pull request (PR).

Cara termudah untuk melakukannya adalah dengan membuka halaman repo Anda di GitHub. Akan ada pesan kecil tepat di atas jendela file yang mengatakan "Cabang ini adalah X berkomitmen di depan repo-nama: cabang" dan kemudian opsi untuk "Tarik permintaan" atau "Bandingkan".

Mengklik opsi "Tarik permintaan" di sini akan membawa Anda ke halaman di mana Anda dapat membandingkan perubahan dan tombol yang mengatakan "Buat permintaan tarik" kemudian akan membawa Anda ke halaman "Buka permintaan tarik" di mana Anda akan menambahkan judul dan sertakan komentar. Singkat, tetapi cukup detail dalam komentar, akan membantu pengelola proyek memahami perubahan yang Anda usulkan.

Ada alat CLI seperti Node GH (GitHub juga baru-baru ini merilis beta alat CLI mereka) yang memungkinkan Anda untuk memulai dan mengelola permintaan tarik di terminal. Pada titik ini Anda mungkin lebih suka menggunakan antarmuka web, dan itu bagus! Begitu juga aku.

Langkah Bonus: Jarak Jauh (Tautkan Semua Repos)

Pada titik ini, kami memiliki tiga referensi repositori:

1. upstream : repo utama yang Anda lacak, seringkali repo yang Anda lacak;
2. origin : nama default remote yang Anda kloning;
3. local : kode yang saat ini ada di komputer Anda.

Sejauh ini, Anda memiliki #2 dan #3 — tetapi #1 penting karena itu adalah sumber utama. Menjaga ketiga hal ini sejalan satu sama lain akan membantu riwayat komit tetap bersih. Ini membantu pengelola proyek karena menghilangkan (atau setidaknya meminimalkan) konflik penggabungan saat Anda mengirim permintaan tarik (PR) dan ini membantu Anda mendapatkan kode terbaru dan menjaga repositori lokal dan asal Anda tetap mutakhir.

Setel Remote Upstream

Untuk melacak remote upstream, di terminal Anda masukkan yang berikut ini:

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

Sekarang, periksa untuk melihat remote apa yang Anda miliki — masukkan git remote -v ke terminal Anda, Anda akan melihat sesuatu seperti:

 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)

Ini akan memungkinkan Anda untuk dengan cepat mendapatkan versi terbaru dari apa yang upstream — jika Anda sudah lama tidak bekerja di repo dan tidak memiliki perubahan lokal yang ingin Anda pertahankan, ini adalah perintah praktis yang saya gunakan :

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

Bantuan GitHub adalah sumber yang bagus untuk ini dan banyak pertanyaan lain yang mungkin Anda miliki.

HTML Dan CSS: Dimulai Dengan Semantik

Di web, ada persediaan sumber daya yang tak ada habisnya untuk mempelajari HTML dan CSS. Untuk keperluan artikel ini, saya membagikan apa yang saya rekomendasikan berdasarkan kesalahan yang saya buat bagaimana saya pertama kali belajar menulis HTML dan CSS.

Apa Itu HTML Dan CSS?

Sebelum kita melangkah lebih jauh, mari kita definisikan HTML dan CSS.

HTML adalah singkatan dari HyperText Markup Language.

Hiperteks:

“Hypertext adalah teks yang ditampilkan pada layar komputer atau perangkat elektronik lainnya dengan referensi (hyperlink) ke teks lain yang dapat langsung diakses oleh pembaca.”

— “Hypertext” di Wikipedia

Bahasa Markup:

“…sebuah sistem untuk memberi anotasi pada dokumen dengan cara yang secara sintaksis dapat dibedakan dari teks.”

— “Bahasa Markup” di Wikipedia

Jika Anda juga tidak tahu apa arti banyak dari kata-kata itu — singkatnya, HTML adalah kombinasi dari referensi (tautan) antara dokumen di web, dan tag yang Anda gunakan untuk memberi struktur pada dokumen tersebut.

Untuk pengenalan menyeluruh tentang HTML dan CSS, saya sangat merekomendasikan langkah pertama Pengenalan HTML dan CSS, keduanya di dokumen web Jaringan Pengembang Mozilla (MDN) . Itu, bersama dengan artikel luar biasa yang disediakan situs web seperti Trik CSS, 24 Cara dan banyak lainnya, pada dasarnya berisi semua yang Anda perlukan untuk referensi sehubungan dengan HTML/CSS.

Ada dua bagian utama dari dokumen HTML : <head> dan <body> . - <head> berisi hal-hal yang tidak ditampilkan oleh browser — metadata dan tautan ke lembar gaya dan skrip yang diimpor. - <body> berisi konten aktual yang akan dirender oleh browser. Untuk merender konten, browser membaca HTML, menyediakan lapisan gaya dasar tergantung pada jenis tag yang digunakan, menambahkan lapisan gaya tambahan yang disediakan oleh situs web itu sendiri (gaya disertakan dalam/direferensikan dari <head> , atau inline), dan itulah yang kita lihat pada akhirnya. (Catatan: Sering juga ada lapisan tambahan JavaScript tetapi itu di luar cakupan artikel ini.)

CSS adalah singkatan dari Cascading Style Sheets — digunakan untuk memperluas HTML dengan membuatnya lebih mudah untuk memberikan tampilan dan nuansa khusus pada dokumen. Lembar gaya adalah dokumen yang memberi tahu HTML elemen apa yang seharusnya terlihat (dan bagaimana mereka harus diposisikan) dengan menetapkan aturan berdasarkan tag, kelas, ID, dan pemilih lainnya. Cascading mengacu pada metode untuk menentukan aturan mana dalam lembar yang diprioritaskan dalam peristiwa konflik aturan yang tak terhindarkan.

"'Cascading' berarti bahwa gaya dapat turun (atau berjenjang) dari satu lembar gaya ke lembar gaya lainnya, memungkinkan beberapa lembar gaya digunakan pada satu dokumen HTML."

— Kaskade — Desain Maks

CSS sering mendapat reputasi buruk — di situs dengan banyak lembar gaya, CSS dapat dengan cepat menjadi berat, terutama jika tidak ada metode konsisten yang didokumentasikan (lebih lanjut tentang itu nanti) — tetapi jika Anda menggunakannya secara terorganisir dan mengikuti semua praktik terbaik, CSS dapat menjadi teman terbaik Anda. Terutama dengan kemampuan tata letak yang sekarang tersedia di sebagian besar browser modern, CSS tidak lagi diperlukan untuk meretas dan bertarung seperti dulu.

Rachel Andrew menulis panduan hebat, Cara Mempelajari CSS — dan salah satu hal terbaik yang perlu diketahui sebelum Anda mulai adalah:

“Anda tidak perlu berkomitmen untuk menghafal setiap Properti dan Nilai CSS.”

— Rachel Andrew

Sebaliknya, jauh lebih penting untuk mempelajari dasar- dasarnya — pemilih, pewarisan, model kotak, dan yang terpenting, cara men-debug kode CSS Anda (petunjuk: Anda akan memerlukan alat pengembang browser).

Jangan khawatir tentang menghafal sintaks untuk properti background , dan jangan khawatir jika Anda lupa tentang bagaimana tepatnya menyelaraskan hal-hal di Flexbox (Panduan Trik CSS untuk Flexbox mungkin salah satu dari 10 halaman teratas saya yang paling banyak dikunjungi, pernah! ); Google dan Stack Overflow adalah teman Anda dalam hal properti dan nilai CSS.

Beberapa editor kode bahkan memiliki pelengkapan otomatis bawaan sehingga Anda bahkan tidak perlu mencari di web untuk dapat mengetahui semua kemungkinan properti perbatasan, misalnya.

Salah satu fitur baru favorit saya di Firefox 70 adalah indikator aturan CSS tidak aktif. Ini akan menghemat waktu Anda berjam-jam untuk mencari tahu mengapa gaya tidak diterapkan.

Semantik

Mari kita mulai dengan kode semantik . Semantik mengacu pada makna kata, kode semantik mengacu pada gagasan bahwa ada makna pada markup dalam bahasa tertentu.

Ada banyak alasan mengapa semantik itu penting. Jika saya dapat meringkas ini, saya akan mengatakan bahwa jika Anda belajar dan menggunakan kode semantik, itu akan membuat hidup Anda jauh lebih mudah karena Anda akan mendapatkan banyak hal gratis — dan siapa yang tidak suka barang gratis?

Untuk pengenalan kode semantik yang lebih lengkap, lihat posting blog singkat Paul Boag tentang topik tersebut.

Semantik memberi Anda banyak manfaat:

1. Gaya default
   Misalnya, menggunakan tag headline <h1> untuk judul dokumen Anda akan membuatnya menonjol dari konten dokumen lainnya, seperti halnya headline.
2. Konten yang dapat diakses
   Kode Anda akan dapat diakses secara default, artinya kode tersebut akan berfungsi dengan pembaca layar dan akan lebih mudah dinavigasi dengan keyboard.
3. Manfaat SEO
   Markup semantik lebih mudah dibaca oleh mesin, yang membuatnya lebih mudah diakses oleh mesin pencari.
4. Manfaat kinerja
   HTML bersih adalah dasar untuk situs berkinerja tinggi. Dan HTML yang bersih juga kemungkinan akan menghasilkan CSS yang lebih bersih yang berarti lebih sedikit kode secara keseluruhan, membuat situs atau aplikasi Anda lebih cepat.

Catatan: Untuk melihat lebih mendalam tentang semantik dan HTML, Heydon Pickering menulis "Semantik Struktural: Pentingnya Elemen Bagian HTML5" yang sangat saya rekomendasikan untuk dibaca.

Prinsip dan Paradigma Rekayasa: Dasar-dasar

Abstraksi

Ada banyak aplikasi, garis singgung, dan level yang dapat kita jelajahi tentang konsep abstraksi — terlalu banyak untuk artikel ini yang dimaksudkan untuk memberi Anda pengenalan singkat tentang konsep sehingga Anda menyadarinya saat Anda terus belajar.

Abstraksi adalah paradigma rekayasa dasar dengan berbagai aplikasi — untuk tujuan artikel ini, abstraksi memisahkan bentuk dari fungsi. Kami akan menerapkan ini di tiga area: token, komponen, dan prinsip Jangan Ulangi Diri Sendiri.

Token

Jika Anda telah menggunakan alat desain modern untuk waktu yang lama, Anda mungkin menemukan ide tentang token . Bahkan Photoshop dan Illustrator sekarang memiliki ide gaya bersama ini di perpustakaan terpusat — alih-alih mengkodekan nilai-nilai ke dalam desain, Anda menggunakan token. Jika Anda terbiasa dengan konsep variabel CSS atau SASS, Anda sudah terbiasa dengan token.

Satu lapisan abstraksi dengan token adalah memberi nama pada warna — misalnya, $blue-00 dapat dipetakan ke nilai hex (atau nilai HSL, atau apa pun yang Anda inginkan) — katakanlah #0B5FFF . Sekarang, daripada menggunakan nilai hex di stylesheet Anda, Anda menggunakan nilai token — dengan cara itu jika Anda memutuskan bahwa blue-00 sebenarnya #0B36CE , maka Anda hanya perlu mengubahnya di satu tempat. Ini adalah konsep yang bagus.

Jika Anda mengambil paradigma abstraksi yang sama dan melangkah lebih jauh, Anda dapat menerima token — dan menetapkan variabel ke nilai fungsional. Ini sangat berguna jika Anda memiliki sistem yang kuat dan ingin memiliki tema yang berbeda di dalam sistem. Contoh fungsionalnya adalah menetapkan variabel seperti $primary-color dan memetakannya ke $blue-00 — jadi sekarang Anda dapat membuat markup dan alih-alih mereferensikan biru, Anda mereferensikan variabel fungsional. Jika Anda ingin menggunakan markup yang sama, tetapi dengan gaya (tema) yang berbeda, maka Anda hanya perlu memetakan $primary-color ke warna baru, dan markup Anda tidak perlu diubah sama sekali! Sihir!

Komponen

Dalam 3-4 tahun terakhir, ide komponen dan komponenisasi menjadi lebih relevan dan dapat diakses oleh desainer. Konsep simbol (dipelopori oleh Macromedia/Adobe Fireworks, kemudian diperluas oleh Sketch, dan kemudian dibawa ke tingkat berikutnya oleh Figma dan Framer), sekarang lebih banyak tersedia di sebagian besar alat desain (Adobe XD, InVision Studio, Webflow, dan banyak lagi). yang lain). Komponenisasi, bahkan lebih dari sekadar token, dapat memisahkan bentuk sesuatu dari fungsinya — yang membantu meningkatkan baik bentuk maupun fungsinya.

Salah satu contoh awal yang lebih menonjol adalah komponen objek media Nicole Sullivan. Sepintas Anda mungkin tidak menyadari bahwa seluruh halaman pada dasarnya terdiri dari satu komponen, dirender dengan cara yang berbeda. Dengan cara ini, kita dapat menggunakan kembali markup (form) yang sama, memodifikasinya sedikit dengan meneruskan opsi atau parameter, dan gaya — dan membuatnya memberikan berbagai nilai (fungsi).

Jangan Ulangi Diri Sendiri

KERING (Jangan Ulangi Diri Sendiri) adalah salah satu prinsip favorit saya — menciptakan hal-hal yang dapat digunakan kembali berulang kali adalah salah satu kemenangan kecil yang dapat Anda peroleh saat membuat kode.

Meskipun Anda sering tidak dapat (dan boleh dibilang tidak boleh) berusaha menerapkan prinsip KERING 100% setiap saat — setidaknya bermanfaat untuk menyadari hal ini sehingga saat Anda bekerja, Anda dapat mempertimbangkan bagaimana Anda dapat membuat apa pun yang Anda kerjakan lebih dapat digunakan kembali.

Catatan tentang Aturan Tiga: Akibat wajar dari prinsip KERING adalah aturan tiga — pada dasarnya, setelah Anda menggunakan kembali (menyalin/menempel) sesuatu tiga kali, Anda harus menulis ulang menjadi komponen yang dapat digunakan kembali. Seperti Pirate's Code, ini lebih merupakan pedoman daripada aturan keras dan cepat, dan dapat bervariasi dari komponen ke komponen dan dari proyek ke proyek.

CSS Dan Metodologi Penataan: Atom vs. BEM

Ada banyak cara berbeda untuk mengatur dan menulis kode CSS — Atomic dan BEM hanyalah dua dari banyak cara yang mungkin Anda temui. Anda tidak harus "memilih" satu pun, Anda juga tidak harus mengikuti mereka dengan tepat. Sebagian besar tim tempat saya bekerja biasanya memiliki perpaduan unik mereka sendiri, berdasarkan proyek atau teknologi. Akan sangat membantu untuk mengenal mereka sehingga seiring waktu, Anda dapat mempelajari pendekatan mana yang harus diambil tergantung pada situasinya.

Semua pendekatan ini melampaui CSS dan gaya "hanya", dan sering kali dapat memengaruhi alat yang Anda gunakan, cara Anda mengatur file, dan kemungkinan markup.

CSS atom

Jangan bingung dengan Atomic Web Design — Atomic (mungkin lebih tepat disebut sebagai "fungsional") CSS, adalah metodologi yang pada dasarnya lebih menyukai penggunaan kelas kecil dengan tujuan tunggal untuk mendefinisikan fungsi visual. Beberapa perpustakaan terkenal:

1. CSS Atom oleh Steve Carlson;
2. Tachyons oleh Adam Morse;
3. Tailwind CSS oleh Adam Wathan.

Apa yang saya sukai dari metode ini adalah memungkinkan Anda untuk dengan cepat menata dan tema sesuatu — salah satu kelemahan terbesar adalah markup Anda bisa menjadi sangat berantakan, cukup cepat.

Lihat artikel John Polacek tentang trik CSS untuk pengenalan lengkap tentang Atomic CSS.

BEM

Filosofi BEM adalah pendahulu yang bagus untuk banyak kerangka kerja JavaScript modern seperti Angular, React, dan Vue.

“BEM (Block, Element, Modifier) ​​adalah pendekatan berbasis komponen untuk pengembangan web.”

— BEM: Mulai Cepat

Pada dasarnya, segala sesuatu yang dapat digunakan kembali adalah sebuah blok. Blok terdiri dari elemen, sesuatu yang tidak dapat digunakan di luar blok, dan kemungkinan blok lainnya. Pengubah adalah hal-hal yang menggambarkan status sesuatu atau cara terlihat atau berperilaku.

Secara pribadi, saya menyukai teori dan filosofi BEM. Apa yang saya tidak suka adalah cara sesuatu diberi nama. Terlalu banyak garis bawah, tanda hubung, dan itu bisa terasa tidak perlu berulang ( .menu , .menu__item , dll).

Bacaan yang direkomendasikan : BEM Untuk Pemula yang ditulis oleh Inna Belaya

Terima Kasih, Selanjutnya(.js)

Setelah Anda cukup menguasai topik-topik ini, jangan khawatir, masih banyak yang harus dipelajari. Beberapa saran:

1. Pemrograman fungsional dan berorientasi objek
   Kami menyentuhnya dengan ringan, tetapi masih banyak lagi yang harus dipelajari selain CSS.
2. Bahasa dan kerangka kerja tingkat tinggi
   TypeScript, Ruby, React, Vue adalah hal-hal berikutnya yang akan Anda tangani setelah Anda memiliki pemahaman yang kuat tentang HTML dan CSS.
3. Mengkueri bahasa dan menggunakan data
   Mempelajari tentang GraphQL, MySQL, REST API akan membawa kemampuan pengkodean Anda ke tingkat berikutnya.

Kesimpulan: Desainer yang Membuat Kode != Insinyur Perangkat Lunak

Semoga artikel ini menunjukkan kepada Anda bahwa belajar coding tidak sesulit yang Anda bayangkan sebelumnya. Ini bisa memakan banyak waktu, tetapi jumlah sumber daya yang tersedia di internet sangat mencengangkan, dan tidak berkurang — justru sebaliknya!

Satu poin penting yang ingin saya tekankan adalah bahwa "pengkodean" tidak sama dengan "rekayasa perangkat lunak" — kemampuan untuk melakukan fork repo dan menyalin/menempel kode dari Stack Overflow dapat membawa Anda jauh, dan sementara sebagian besar, jika tidak semua, insinyur perangkat lunak yang saya tahu telah melakukan itu — Anda harus menggunakan keterampilan baru Anda dengan kebijaksanaan dan kerendahan hati. Untuk semua yang sekarang dapat Anda akses dengan beberapa kecakapan teknik, masih banyak lagi yang tidak Anda ketahui. Meskipun Anda mungkin berpikir bahwa fitur atau gaya mudah dicapai karena — "Hei, saya membuatnya bekerja di devtools!" atau “Saya membuatnya bekerja di Codepen.” — ada banyak proses rekayasa, dependensi, dan metode yang mungkin tidak Anda ketahui yang tidak Anda ketahui.

Semua itu untuk mengatakan — jangan lupa bahwa kita masih desainer. Fungsi utama kami adalah untuk menambah nilai bisnis melalui lensa pemahaman masalah pelanggan atau pengguna dan mensintesiskannya dengan pengetahuan kami tentang pola desain, metode, dan proses. Ya, menjadi "desainer yang menulis kode" bisa sangat berguna dan akan memperluas kemampuan Anda untuk menambahkan nilai ini — tetapi kita tetap harus membiarkan para insinyur membuat keputusan teknis.

Ada yang salah?

Ada kemungkinan besar bahwa sesuatu dalam posting ini tidak jelas, tumpul, dan/atau usang dan saya ingin kesempatan untuk membuatnya lebih baik! Silakan tinggalkan komentar di bawah, DM saya, atau @mention saya di Twitter agar saya bisa berkembang.

Bacaan lebih lanjut

1. Coding Bootcamps vs. Gelar Ilmu Komputer: Apa yang Diinginkan Pengusaha dan Perspektif Lainnya (Kyle Thayer)
2. Cara Mulai Menggunakan Sketch Dan Framer X (oleh Martina Perez, Smashing Magazine )
3. Pengantar Perintah Linux (oleh Paul Tero, Smashing Magazine )
4. Menjadi Pengguna Kekuatan Baris Perintah Dengan Oh My ZSH Dan Z (oleh Wes Bos, Smashing Magazine )
5. Daftar perintah cmd.exe dan Unix umum yang dapat Anda gunakan di PowerShell ( Microsoft Docs )
6. regular-expressions.info (oleh Jan Goyvaerts)
7. regexone.com (pelajari ekspresi reguler dengan latihan interaktif sederhana)
8. Mengubah Ukuran Batch Menggunakan Command Line dan ImageMagick (oleh Vlad Gerasimov, Smashing Magazine )
9. Cara Pintas Dan Tips Untuk Meningkatkan Produktivitas Anda Dengan Sublime Text (oleh Jai Pandya, Smashing Magazine )
10. Kode Visual Studio Dapat Melakukan Itu? (oleh Burke Holland, Majalah Smashing )
11. Mengapa riwayat versi bukan kontrol versi (oleh Josh Brewer)
12. Kontrol Versi Modern Dengan Git (oleh Tobias Gunther, Smashing Magazine )
13. “Hello World” (panduan langkah demi langkah GitHub)
14. Cara Menginstal Node.js dan NPM di Mac (oleh Dave McFarland)
15. Cara Install Node.js dan NPM di Windows (oleh Dejan Tucakov)
16. Mengapa Saya Membuat Atomic Commits Di Git (oleh Clarice Bouwer)
17. Cara Menulis Pesan Git Commit (oleh Chris Breams)
18. Kode semantik: Apa? Mengapa? Bagaimana? (oleh Paul Boag)
19. Semantik Struktural: Pentingnya Elemen Pemotongan HTML5 (oleh Heydon Pickering, Smashing Magazine )
20. Merancang untuk Performa: Bab 4. Mengoptimalkan Markup dan Gaya (oleh Lara C. Hogan, O'Reilly Media )
21. Objek media menyimpan ratusan baris kode (oleh Nicole Sullivan)
22. Mari Mendefinisikan Apa Itu Atomic CSS (oleh John Polacek, CSS Tricks )
23. BEM Untuk Pemula: Mengapa Anda Membutuhkan BEM (oleh Inna Belaya, Majalah Smashing )
24. Javascript for Cats: Pengenalan untuk Pemrogram Baru
25. Roadmap.sh: Pengembang Frontend
26. Pemrograman Fungsional vs OOPS: Jelaskan Seperti Saya Lima
27. Mengapa, Bagaimana, dan Kapan Menggunakan HTML Semantik dan ARIA (oleh Adam Silver, Trik CSS )
28. Semantik HTML (sebuah eBook oleh Smashing Magazine )
29. Dasar-dasar - HTML + CSS (di Syntax.fm )
30. Kaskade dan warisan ( westciv.com )
31. Trik CSS (oleh Chris Coyier)
32. Memulai Dengan Tata Letak CSS (oleh Rachel Andrew, Smashing Magazine )
33. Pengantar HTML (dokumen web MDN)
34. Langkah pertama CSS (dokumen web MDN)
35. Langkah Pertama JavaScript (dokumen web MDN)
36. 24 Cara (oleh Drew McLellan)