Як стати гарним фронт-енд розробником

{full-post-img}

Не так давно я отримав листа від одного з моїх читачів, який змусив мене трохи задуматись. Ось як воно виглядає:

Привіт, Філіп, я хочу спитати, як стати гарним фронт-енд розробником? Є якісь поради?

Повинен визнати, що я був здивованим такого роду питанню, бо ніколи не вважав себе "гарним" фронт-ендером. У перші роки моєї роботи у даній сфері я справді не думав, що я досвідчений. Я лише подавав своє резюме, бо не уявляв, на скільки мало я знаю, і був прийнятий лише тому, що люди, які брали в мене інтерв'ю не знали, які питання задавати. Але усе закінчилося тим, що я розвивався за той час своєї роботи там і став невід'ємним членом своєї команди. Згадуючи, як я ставився до тих інтерв'ю, я просто був вражений, як для мене було важливо мати достатньо знань, не зважаючи на те, що я їх майже не мав, коли тільки починав працювати. Мій "я" зараз точно б не найняв такого мене минулого, хоча із свого власного досвіду я знаю, що шанси на успіх завжди є.

Чим довше я працюю у веб-індустрії, тим краще я усвідомлюю, що відділяють професійних людей від дуже професійних не знання, які в них є, а їх спосіб мислення. Звичайно, знання теж дуже важливі, у деяких випадках просто критично необхідні, але у середовищі, яке змінюється з такою надзвичайною швидкістю, спосіб, яким ви будете добувати їх - набагато важливіше, більш того, найнеобхідніше мати уявлення, як саме ви будете використовувати здобуте, щоб розв'язувати повсякденні проблеми.

В інтернеті існує безліч статтей про мови програмування, фреймворки та інструменти, які вам слід знати, щоб отримати роботу. Але тут я збираюся розказати про те, як думає фронт-енд інженер, і, принаймні сподіваюся дати цим відповідь на питання "Як стати профі?".

Не треба просто розв'язувати проблеми, з'ясуйте, що взагалі відбувається

Занадто багато людей, які пишуть CSS та JavaScript, мучаться до тих пір, поки вони не знайдуть код, який працює, і тільки тоді вони продовжують свою роботу. Я знаю, це відбувається часто, тому що бачу подібне постійно під час перевірки коду.

Я питаю їх "Чому ти тут додав float:left?" або "Чому overflow:hidden тут такий важливий?" і не рідко отримую у відповідь щось типу "Я не знаю, але якщо це прибрати, то нічого не буде працювати".

Бувають часи, коли ви потребуєте чогось, що працює, і ви потребуєте це негайно. Але якщо ви не можете знайти час, щоб зрозуміти сам корінь даної проблеми, ви будете у ситуаціях, описаних вище, дуже часто.

Може здатися, що виділити час на те, щоб з'ясувати, чому саме ваш код не працює, потребує багато жертв. Але я обіцяю, що це врятує купу вашого часу у майбутньому.

Ви маєте навчитися передбачати зміни структури браузера

Одна з найбільших відмінностей між кодом у фронт-енді та кодом у бек-енді є саме робоче середовище, з яким ви маєте працювати. Платформи девайсів користувачів можуть бутии різними у будь-який час, а ваш код повинен з цим вправно справлятися.

Я згадую, як я проходився повз вихідний код популярного JavaScript фреймворку ще у 2011 році і побачив такий рядок:

var isIE6 = !isIE7 && !isIE8 && !isIE9;

Так, версія для IE6 була "всеосяжна" для усіх IE версій. Але пізніше вийшов IE10 і більшість наших продуктів просто переставали на ньому працювати.

Я розумію, що у реальному житті таке передбачення не діє на усі 100%, і часто доводиться орієнтуватися на кількість багів у результаті, але рекомендовано хоча б приблизно прогнозувати, як можна виправити їх, щоб у майбутньому вони більше не з'являлися.

Для багатьох з нас код, який ми пишемо, перебуває у наших руках тільки на період, коли ми на одній роботі. Деякий код, який я писав ще вісім років тому назад досі працює і я від цього відчуваю як насолоду, так і суцільний жах.

Читайте документацію

У світі завжди будуть баги у браузерах, але коли два браузери читають один і той самий код по-різному, люди не будуть думати над тим, який браузер є "добрим", а який - "поганим".

Гарний приклад до цього – мінімальний розмір змінюваних блоків за умовчуванням. По документації, значення min-width та min-height є auto, що означає, що за замовчуванням вони не повинні бути менше ніж мінімальний розмір контенту, який в них знаходиться. За останні вісім місяців, Firefox – це єдиний браузер, який робить це правильно.

Якщо ви помітите, що ваш код читається однаково у Chrome, Opera, IE та Safari, але по-іншому у Firefox, то вам може здатися, що сам Firefox просто читає ваш код не правильно. Багато подібних "проблем" я помітив на своєму досвіді, хоча розв'язок на них завжди один – читати документацію.

Коли два браузери виводять ваш код не однаково, то виділіть час на те, щоб з'ясувати, який браузер показує ваш код правильно та орієнтуватися по ньому.

Також додам, що так звані "гарні" фронт-ендери – це ті люди, які здатні звикати до нових технологій ще до того, як вони починають використовувати їх у роботі. Якщо ви зможете розвинути своє вміння уявляти в голові, як усе буде працювати, зразу після того, як прочитали документацію, то ви є одним з тих людей, які здатні змінювати світ веб-розробки.

Читайте чужий код

Читання коду інших людей точно не є ідеєю для відпочинку на суботню ніч, але є одним з накращих способів стати кращим розробником.

Розв'язання своїх проблем є чудовим способом вчитися, але якщо це ваше постійне заняття, то ви дуже швидко перестанете розвиватися. Читання коду інших людей допомагає вам відкрити свій розум для нових методів творити певні речі. І взагалі, вміння читати та розуміти код, який не був вами написаний просто необхідне у командній роботі.

На мою думку, одна з найбільших помилок, які роблять різні компанії, коли наймають до себе робітників, у тому, що вони просять їх просто написати новий код. Я ще не був ні на одному інтерв'ю, де мене б попросили прочитати існуючий код, знайти помилки у ньому і виправити їх. Це дуже погано, бо найбільше часу ми, інженери, додаємо або змінюємо вже існуючу базу і дуже рідко просто створюємо щось з нуля.

Працюйте з людьми, які розумніші за вас

У мене з'явилося таке відчуття, наче занадто багато фронт-енд розробників бажають працювати на фрілансі, що не скажеш про бек-енд розробників. Напевно фронт-ендери зазвичай бажають займатися самоосвітою, а бек-ендерів зазвичай треба навчати.

{full-post-img}

Великим мінусом у даному способі є те, що людина відмовляється від можливостей навчатися у людей, які розумніші за неї. Вона просто не має того, хто б зміг допомогти, або перевірити код.

Я дуже рекомендую, хоча б на період початку вашої кар'єри фронт ендера, працювати у команді, де люди більш досвідчені за вас. Якщо ви все ж таки волієте працювати самі на себе, то я б порекомендував хоча б брати участь в open source проектах.

Самі відкривайте Америки

Повторюватись – погано для бізнеса, але добре для вивчення чогось нового. Так, ви можете спокійно вставити чужий код у свій проект, але уявіть, скільки всього ви будете вміти, якщо спробуєте зробити усе це самі.

Не зрозумійте мене не правильно, я не кажу, що вам не слід взагалі брати готовий код. Використання бібліотек, які тестувалися роками – це завжди гарний спосіб зробити проект якісно. Але у цій статті я розказую про те, як стати "гарним" фронт-енд розробником. Багато людей, яких я вважаю профі у своїй справі – це люди, які самі створюють свої бібліотеки, які я сам використовую весь час.

Постійним питанням людей у такій індустрії – це "Що мені зробити далі?".Якщо ви задаєтесь цим питанням замість того, щоб вивчати якийсь новий інструмент для розробки, або створювати додаток, то чому б не відтворити самому якийсь існуючий CSS фреймворк або JavaScript бібліотеку? Кожен раз, коли ви відчуєте, що застрягли на якомусь моменті, завжди буде готовий результат, який допоможе вам знайти правильну відповідь.

Пишіть про те, що саме ви вивчили

Діліться тим, що ви вивчили декілька днів тому. Існує так багато причин це зробити, але найбільша – ви зможете побачити усю картину краще. Якщо ви не можете пояснити, як щось працює, то можливо ви ще не зрозуміли усе до кінця. Ви не зможете з'ясувати точно, чи вивчили ви дану тему на усі 100%, поки не запишете вивчене.

З мого досвіду, написати, розказати, або просто зробити приклад – найкращі способи заглибитися у сферу, яку ви вивчаєте, і зрозуміти її повністю.