Необходимый минимум для фронтенд-разработчика

April 15, 2015

На днях я подготовил описание README для одного проекта, который, надеюсь,
будет
интересен и поучителен для других разработчиков. Так вот, когда я его писал, я
понял, что несколько лет назад испугался бы до смерти, если бы наткнулся на
нечто подобное, со всякими упоминаниями о Node и его пакетном менеджере,
системах Homebrew и Git, всевозможных тестах, тестовых и финальных сборках.

Когда-то основная часть рабочего процесса фронтенд-разработчика состояла в редактировании
файлов, их локальном тестировании (в меру возможностей) и пересылке на
сервер через FTP. Мы измеряли свою крутость умением подчинить своей воле IE6
или
добиться пиксельного соответствия в различных браузерах. Многим членам нашего
сообщества — и мне тоже — не хватало опыта традиционного
программирования.
HTML, CSS и JavaScript — обычно в виде jQuery — осваивались самостоятельно.

За последние несколько лет кое-что изменилось. Возможно, причиной этому стало
то,
что люди начали воспринимать фронтенд-разработку серьезно; может быть, то, что
разработчики браузеров в большинстве своем наконец-то навели порядок в своих
творениях; а, может, просто фронтенд-разработчики, опять же, включая меня,
в конце концов постигли суть процесса разработки ПО.

Что бы там ни было, думаю, мы стали свидетелями смещения акцента с ценности
различных мелочей на ценность инструментов. Теперь, чтобы быть успешным
фронтенд-разработчиком, нужно обладать набором базовых навыков, а те
разработчики, которые не соответствуют этим требованиям, скоро начнут
всё сильнее чувствовать насколько сильно они отстали, по мере того как
источники
информации начинают подразумевать наличие некоторых знаний как само
собой разумеющееся.

Вот некоторые вещи, с которыми хотелось бы, чтобы все были знакомы и некоторые
источники, которые можно использовать, чтобы подтянуть свои навыки. (Спасибо
Полу Айришу (Paul Irish), Майку Тейлору (Mike Taylor), Ангусу Кролу (Angus
Croll) и Владу Филипову (Vlad Filippov) за их вклад.)

JavaScript


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

Это значит, что вы прочитали «JavaScript: Сильные стороны», желательно
больше одного раза. Что вы понимаете принцип работы структур данных вроде
объектов и массивов; функции, в том числе как и почему их нужно вызывать и
применять; умеете работать с наследованием через прототипы; и можете
справиться с асинхронностью.

Если ваши навыки работы с простым JavaScript оставляют желать лучшего, вот
некоторые ресурсы, которые вас выручат:

Система управления версиями файлов Git (и профиль на GitHub)


Если вас нет на GitHub, в общем и целом вы не можете участвовать в жизни
крупного сообщества с открытым исходным кодом, которое выросло вокруг
технологий
фронтенд разработки. Клонирование репозитория с целью испробовать его
возможности должно стать для вас привычным делом и вы должны понимать как
использовать ветки в совместных проектах.

Хотите повысить свои навыки работы с Git?

Модульный принцип организации, управление зависимостями и тестовые сборки


Те дни, когда управление зависимостями сводилось к добавлению дополнительного
скрипта или тега стилей на страницу, давно прошли. Даже если у вас не было
возможности внедрить замечательные инструменты вроде RequireJS в процесс
разработки на работе, вам стоит найти время изучить их в своем личном проекте
или проекте вроде Backbone Boilerplate, так как преимущества, которые
они
в себе несут, трудно переоценить. RequireJS, в частности, делает возможной
разработку с использованием небольших модульных файлов JS и CSS, а затем
конкатенирует и минифицирует их с помощью своего инструмента оптимизации для
дальнейшего использования.

Скептически настроены относительно разработки на основе модулей? Это не
причина
ничего не делать. По крайней мере, вам должны быть знакомы инструменты вроде
UglifyJS или Closure Compiler, которые грамотно сжимают ваш код, а
затем конкатенируют эти сжатые файлы перед выдачей результата.

Если вы пишете на чистом CSS - то есть не используете препроцессор вроде Sass
или Stylus – RequireJS также поможет организовать ваши CSS файлы по модульному
принципу. Используйте операторы @import в основном файле, чтобы загрузить
зависимости для разработки и затем запустите средство оптимизации
RequireJS для основного файла чтобы создать готовый для использования файл.

Инструменты разработчика, встроенные в браузер


За последние несколько лет инструменты для разработчиков, встроенные в
браузеры, ощутимо усовершенствовались и теперь они могут существенно улучшить
ваш опыт разработки, если вы научитесь ими правильно пользоваться. (Подсказка:
если вы все еще отлаживаете код, используя alert, вы зря убиваете время.)

Вам наверняка стоит выбрать один браузер, чьи инструменты разработчика вы
будете использовать на постоянной основе — на данный момент я склоняюсь к
инструментам разработчика в Google Chrome - но не отказывайтесь полностью
от инструментов в других браузерах, так как в них время от времени на основе
откликов разработчиков добавляются новые полезные возможности. В Dragonfly
от Opera, в частности, были добавлены некоторые возможности, выделяющие её
инструменты разработчика на фоне других, например: (экспериментальный) CSS-
профилировщик, настраиваемые горячие клавиши, удалённая отладка без
необходимости USB-подключения, а также возможность сохранять и использовать
пользовательские цветовые палитры.

Если вы не очень хорошо разбираетесь в браузерных инструментах разработчика,
презентация «Чиним код jQuery» послужит отличным (и не слишком
сфокусированным на jQuery) обзором отладки, который включает в себя описание
процесса пошаговой отладки — того, что изменит вашу жизнь, если вы с этой презентацией
ещё не знакомы.

Командная строка


Если говорить о командной строке, её уверенное использование уже является
обязательным - вы непозволительно много упускаете, если не готовы тут же
зайти в окно терминала и погрузиться в работу. Я не говорю, что вам следует
делать всё через терминал - можете продолжать пользоваться графическим
интерфейсом Git, хотя думаю, в конце концов, вам же будет лучше, если вы от него
откажетесь - однако, несомненно, окно терминала должно быть постоянно открыто
для проекта, над которым вы работаете. Есть несколько задач, которые вы должны
выполнять через командную строку не задумываясь:

  • ssh для подключения к другой машине или серверу
  • scp для копирования файлов на другую машину или сервер
  • ack или grep для поиска файлов в проекте по строке или шаблону
  • find для обнаружения файлов, чьи названия совпадают с данным шаблоном
  • git для выполнения хотя бы базовых действий вроде add, commit, status
    и pull
  • brew для использования Homebrew для установки пакетов
  • npm для установки пакетов Node
  • gem для установки пакетов Ruby


Если какими-то командами вы пользуетесь особенно часто, отредактируйте свой .bashrc,
.profile или .zshrc (или что у вас там) и создайте для них альтернативные
имена
чтобы не набирать команды руками каждый раз. Также можно добавить альтернативные
имена в файл ~/.gitconfig. Файлы с точками от Джанни Чиаппетта (Gianni
Chiappetta) могут послужить отличным источником вдохновения.

Примечание: Если вы пользуетесь Windows, я не знаю, как вам помочь, разве что
могу посоветовать Cygwin. Возможно, я не прав, но принимать участие в
жизни сообщества фронтенд-разработчиков с открытым кодом на машине с Windows
существенно сложнее. Если посмотреть на вещи оптимистически, ноутбуки MacBook
Air не очень дорогие, мощные и на удивление портативные, кроме того существуют
Ubuntu или Unix.

Шаблонизация на стороне клиента


Не так давно для серверов было обычным делом отвечать на запрос XHR фрагментом
HTML-кода, однако за последние 12-18 месяцев сообщество фронтенд разработчиков
прозрело и начало требовать данных от сервера в чистом виде. Преобразование
таких данных в HTML, который затем можно добавить в дерево документа, может
оказаться трудоёмким и неудобным процессом, если иметь дело непосредственно с кодом.
Вот когда в дело вступают библиотеки шаблонизации на стороне клиента: они
позволяют использовать шаблоны, которые после добавления данных
превращаются в строку HTML. Вам нужна помощь в подборе инструмента для
шаблонизации? Схема для выбора шаблона от Герен Минс (Garann Means)
поможет вам найти подходящий.

CSS-препроцессоры


На днях Пол Айриш отметил, что мы стали свидетелями того, что фронтенд-
разработчики пишут код, сильно отличающийся от того, который в результате
оказывается в готовой сборке и ярким примером тому является код, написанный с
помощью CSS-препроцессоров. Всё еще есть крикливая компания, которая считает,
что только чистый CSS имеет право на жизнь, но они начинают менять
мнение
. Эти инструменты дают нам возможности, которые, по мнению некоторых,
уже должны были быть добавлены в CSS — переменные, математические выражения,
логику, миксины, а также они могут помочь справиться с префиксами свойств.

Тестирование


Одна из радостей написания модульного, свободно сопряжённого кода состоит в
том, что такой код намного легче тестировать, а с инструментами вроде
Grunt,
подготовка проекта со встроенными тестами вообще стала проще простого. В Grunt
интегрирован QUnit, однако существует много фреймворков для тестирования, из
которых вы можете выбрать те, что вам по душе — моими любимыми на данный
момент являются Jasmine и Mocha — в зависимости от стиля, который
вы предпочитаете, и остальных составляющих вашей подборки.

В то время, как тестирование модульного, свободно сопряжённого кода является
приятным, тестирование плохо организованного кода может быть чем-то средним
между сложным и невозможным. С другой стороны, если принудить себя написать
тесты, возможно, даже до того, как вы напишете код - это поможет вам
систематизировать свой подход и код. Это также даст вам возможность
перестроить код с большей уверенностью в будущем.

Автоматизация процессов (rake/make/grunt/и т.д.)


Возможность с помощью Grunt настроить проект со встроенной поддержкой модульного
тестирования — это один из примеров автоматизации процессов. Реальность
фронтенд-разработки такова, что нам приходится выполнять множество
повторяющихся действий, но, как однажды сказал мне друг: хороший разработчик —
ленивый разработчик. Советую придерживаться золотого правила:
если вы выполняете какое-либо действие больше трёх раз, пора его
автоматизировать.

Уже довольно давно нам в этом помогают инструменты вроде make, кроме него
существуют также rake, grunt и другие. Если вы хотите автоматизировать
выполнение заданий связанных с файловыми системами, исключительно полезно
будет изучить язык, отличный от JavaScript, так как асинхронная природа Node
может стать неподъемным грузом, если вы умеете только управлять файлами.
Существует также множество других инструментов автоматизации, созданных под
конкретные задачи: инструменты для развёртывания, генерирования сборки,
проверки качества кода, и др.

Качество кода


Если вам когда-либо приходилось ощущать негативные последствия от пропущенной
точки с запятой или лишней запятой, вы знаете сколько времени можно потерять
из-за мелких ошибок в коде. Поэтому вы пропускаете свой код через инструмент
вроде JSHint, верно? Он поддаётся настройке и может быть
интегрирован в ваш редактор или процесс сборки несколькими способами.

Хорошее руководство


К сожалению, руководства по фронтенд-разработке не существует, однако ресурс
MDN
вполне подходит на эту роль. Хорошие фронтенд разработчики знают, что
в каждый поисковый запрос нужно добавлять префикс mdn — например, mdn
массивы javascript
— чтобы избежать коммерческой чумы, которой является ресурс
w3schools.

Конец


Как всегда, просто почитав обо всех этих инструментах, вы не научитесь ими
пользоваться на уровне эксперта или хотя бы любителя, единственный верный
способ научиться что-то делать — начать пробовать это делать. Удачи вам.


Логотип компании «Одноклассники»
Статья переведена благодаря спонсорской поддержке компании «Одноклассники».


Source: http://frontender.info/

Комментарии

comments powered by Disqus