Как стать выдающимся фронтенд-разработчиком
Перевод статьи How to Become a Great Front-End Engineer с сайта philipwalton.com, c разрешения автора— Филипа Уолтона.
Недавно я получил электронное письмо от читателя моего блога, которое почему-то заставило меня всерьез задуматься. Вот что оно гласило:
Привет, Филип, можно спросить, как вы стали выдающимся фронтенд-разработчиком?
Что-нибудь посоветуете?
Должен признаться, что я удивился самой постановке вопроса, поскольку никогда не думал о себе как о «выдающемся» фронтендере. На самом деле в первые годы работы в отрасли я искренне не считал себя достаточно подготовленным для работ, на которые устраивался. Я предлагал свою кандидатуру лишь потому, что не понимал, как мало знаю, а брали на работу меня лишь потому, что люди, проводившие со мной собеседование, не знали, что спрашивать.
При всём при этом, в итоге я неплохо справлялся с каждой из своих ролей и становился ценным членом команды. Когда я в конце концов уходил (чтобы принять новый вызов, к которому я тоже был не подготовлен), мне обычно приходилось самому подыскивать себе замену. Оглядываясь с сегодняшних позиций на то, как я проводил те собеседования, я удивляюсь, какое большое значение я придавал знаниям — при том, что у меня самого поначалу их было маловато. Теперешний я вряд ли взял бы на работу тогдашнего меня, хоть я и знал по личному опыту, что успех возможен.
Чем дольше я работал в вебе, тем больше понимал, что хороших специалистов от действительно хороших специалистов отличает не то, что они знают, а то, как они думают. Конечно, знания важны — в некоторых случаях критичны — но в сфере, которая так быстро меняется, ваш подход к получению знаний всегда будет важнее (по крайней мере, в долгосрочной перспективе), чем то, что вы знаете в данный момент. И, пожалуй, важнее всего: как вы используете эти знания при решении повседневных проблем.
Есть множество статей, рассказывающих о языках, фреймворках и инструментах, нужных вам, чтобы найти работу. Я хотел подойти с другой стороны. В этой статье я собираюсь рассказать про мысленную установку фронтенд-программиста, и, надеюсь, дать более надежный ответ на вопрос «как стать выдающимся».
Не просто решайте проблемы, а вникайте в суть происходящего
Слишком многие из тех, кто пишет CSS и JavaScript, находят работающее решение «методом тыка» и тут же переходят к следующей задаче. Я знаю об этом, потому что постоянно вижу это, оценивая чей-либо код.
Я часто спрашиваю кого-нибудь: «Зачем ты поставил здесь float:left?» или «А этот overflow:hidden действительно необходим?», и мне отвечают: «Не знаю, но если это убрать, оно не работает».
То же самое справедливо для JavaScript. Я могу наткнуться на setTimeout для предотвращения «состояния гонки», или на то, как кто-то останавливает всплытие событий, не задумываясь, как это скажется на других обработчиках событий на странице.
Понимаю, что бывают моменты, когда нужно что-то работающее, и немедленно. Но если вы никогда не выкроите время, чтобы понять причины проблемы, вы будете наступать на одни и те же грабли снова и снова.
Выяснять, почему ваш хак работает, может показаться лишней тратой времени сейчас, но я ручаюсь, что это сбережет вам время в будущем. Более глубокое понимание систем, с которыми вы имеете дело, означает меньше проб и ошибок в дальнейшей работе.
Учитесь предвосхищать перемены в мире браузеров
Одно из главных отличий между кодом фронтенда и бэкенда в том, что код бэкенда обычно исполняется в окружении, которое целиком под вашим контролем. Фронтенд, напротив, полностью вам неподконтролен. Платформа или устройство у ваших пользователей может полностью смениться в любой момент, и ваш код должен уметь изящно отреагировать на это.
Я помню, как просматривал исходник популярного JavaScript-фреймворка в 2011-м и наткнулся на следующую строчку (упрощено для наглядности):
var isIE6 = !isIE7 && !isIE8 && !isIE9;
Здесь предполагалось, что любая версия IE, кроме явно перечисленных — это IE6 (возможно, чтобы хоть как-то обработать еще более старые его версии). Но едва лишь вышел IE10, как изрядная часть функциональности полностью отвалилась.
Я понимаю, что в реальном мире определение возможностей не всегда работает на 100%, и иногда приходится зависеть от глючной реализации или белого списка браузеров, в которых доступные возможности ошибочно определяются как отсутствующие и наоборот. Но каждый раз, когда вы такое делаете, абсолютно критически важно, чтобы вы были готовы к тому, что в будущем этих багов почти наверняка не будет.
Для многих из нас код, который мы пишем сегодня, переживет нашу теперешнюю должность. Многое из того кода, что я написал более 8 лет назад, всё еще работает на больших, активно используемых сайтах — мысль, одновременно приятная и пугающая.
Читайте спецификации
У браузеров всегда будут баги, но когда два браузера отображают один код по-разному, люди часто предполагают, не проверяя свою догадку, что так называемый «хороший» браузер прав, а «плохой» браузер ошибся. Но это не всегда так, и если вы ошиблись в своем предположении, то выбранный вами обходной путь почти наверняка в будущем перестанет работать.
Пример этого из наших дней — минимальная ширина флекс-элементов по умолчанию. По спецификации, исходное значение у min-width и min-height для флекс-элементов — auto (а не 0), что значит, что они не должны ужиматься меньше минимальной ширины своего содержимого. Последних 8 месяцев Firefox был единственным браузером, где это было реализовано правильно [1].
Если вы наткнулись на несоответствие между браузерами и заметили, что ваш сайт одинаково отображается в Chrome, IE, Opera и Safari, но иначе выглядит в Firefox, вы можете предположить, что неправ Firefox. Я много раз был тому свидетелем. Многие из проблем, о которых сообщили пользователи моего проекта «Флексбаги», на самом деле были из-за этого несоответствия, и предложенные обходные пути, будь они реализованы, перестали бы работать две недели назад, когда вышел Chrome 44. Вместо того, чтобы обходными путями добиваться следования спецификации, они по незнанию «наказывали» правильное поведение [2].
Когда два браузера и более отображают код по-разному, нужно найти время на то, чтобы разобраться, кто из них прав, и писать код с учетом этого. Тогда ваши обходные решения будут намного надежнее в будущем.
Кроме того, те, кого называют «выдающимися» фронтендерами — зачастую люди с «передовой» прогресса, которые осваивают технологии еще до того, как они станут мейнстримом, и даже участвуют в разработке этих технологий. Если вы разовьете умение смотреть в спецификацию и представлять себе, как технология будет работать, еще до того, как сможете «поиграть» с ней в браузере, вы попадете в группу избранных, кто может рассуждать о разработке спецификации и даже влиять на нее.
Читайте чужой код
Чтение чужого кода — для удовольствия — возможно, не самое лучшее развлечение для субботнего вечера, но без всяких сомнений один из лучших способов повысить свой профессиональный уровень.
Самостоятельное решение проблем — отличный способ учиться, но если вы будете заниматься только этим, вы достаточно быстро окажетесь на плато. Чтение чужого кода открывает ваш ум новым способам решения задач. А умение читать и понимать код, который вы не писали, при работе в команде или участии в опенсорсном проекте — самое важное.
Я действительно считаю, что одна из крупнейших ошибок компаний при найме новых программистов — то, что их заставляют лишь писать код, новый код с нуля. Мне не доводилось бывать на собеседованиях, где меня попросили бы прочитать существующий код, найти в нем проблемы и исправить их. Это очень плохо, поскольку больше всего времени у программиста уходит на дополнение и изменение существующего кода. Редко вам приходится писать что-то с нуля.
Работайте с теми, кто умнее вас
У меня сложилось впечатление, что фронтендеров, тяготеющих к фрилансу (и вообще к работе на себя), намного больше, чем бэкендеров, стремящихся к тому же. Возможно, это потому, что фронтендеры — чаще самоучки, а бэкендеры — чаще выпускники профильных вузов.
Проблема самоучек, работающих на себя, в том, что им обычно недоступны плюсы учёбы у более знающих людей. Нет того, кто помог бы очистить ваш код от глупостей или хотя просто оценить его.
Я настоятельно рекомендую вам, как минимум на начальном этапе карьеры, работать в команде, а именно — в команде людей, которые умнее и опытнее вас.
Если в какой-то момент своей карьеры вы перейдете к работе на себя, возьмите себе за правило участвовать в опенсорсных проектах. Активное участие в таких проектах дает многие те же плюсы, что и работа в команде, а порой даже больше.
Изобретайте велосипеды
Изобретать велосипеды — плохо для бизнеса, но замечательно для обучения. Как бы ни было соблазнительно взять некий готовый виджет для подсказок при наборе или библиотеку делегации событий из npm, представьте, сколькому вы научитесь, хотя бы попытавшись написать подобное самостоятельно.
Уверен, некоторые читатели этой статьи прямо сейчас готовы резко возразить. Не поймите меня превратно. Я не утверждаю, что никогда не нужно пользоваться сторонним кодом. Пользование проверенными библиотеками, с преимуществом в виде многих лет тестирования и отлова ошибок — почти всегда разумный шаг.
Но в этой статье я говорю от том, как из хорошего стать выдающимся. Многие из тех, кого я считаю выдающимися в этой отрасли — создатели и кураторы популярнейших библиотек, которыми я всё время пользуюсь.
Наверное, можно с успехом работать, не написав ни одной собственной JavaScript-библиотеки, но тогда вряд ли вам удастся в полной мере прочувствовать этот материал «на собственной шкуре».
Частый вопрос, который задают люди в этой отрасли: что бы такого написать еще? Если такой вопрос встал перед вами, то вместо того, чтобы выучить новый инструмент или создать какое-то новое приложение, почему бы не повторить что-то из ваших любимых JavaScript-библиотек или CSS-фреймворков? Приятный момент здесь в том, что если даже у вас возникнут трудности, то в исходнике существующей библиотеки найдутся ответы.
Пишите о том, чему вы научились
Последнее, но, безусловно, не менее важное — вам стоит писать о том, чему вы научились. Для этого есть масса хороших оснований, но, наверное, самая важная причина — это заставит вас лучше понять тему. Если вы не можете объяснить, как что-либо работает, есть изрядная вероятность, что вы сами в этом не разобрались. И зачастую трудно понять это, пока вы не опишите это в подробностях.
По моему опыту, писать статьи, читать доклады и создавать демки — один из лучших способов заставить себя самого углубиться во что-либо и понять его полностью, снаружи и изнутри. Даже если вашу писанину никто не будет читать, сам процесс более чем стоит того.
Примечания:
- Firefox отразил изменение спецификации в своей реализации в версии 34, 1 декабря 2014 г. Chrome реализовал его в версии 44, 21 июля 2015 г., а значит, вот-вот его получит и Опера. Edge вышел сразу с новой реализацией, 29 июня 2015 г. Реализация в Safari, видимо, еще в процессе.
- Можете заглянуть во флексбаг №1 за надежным в перспективе и кроссбраузерным способом обхода этой проблемы.
P.S. Это тоже может быть интересно:
Привет, спасибо за статью! Есть два довольно обьемных вопроса, интересно твое мнение и наблюдения с высоты твоего опыта.
1 Собственно вопрос первый, про скорость работы и как ее увеличить.
Тут дополнительно прокомментирую. Я осознаю, что скорость состоит из нескольких факторов, как минимум из:
— инструменты
— опыт
— природные данные
С инструментами понятно, чем они лучше и быстрее, тем лучше, а опыт позволяет лучше подобрать инструменты под задачу и быстрее решать типовые задачи, это мое мнение.
И самый интересный третий пункт, он коррелирует с первым пунктом твоей статьи. Сюда же относятся и скорость мышления, и инертность, и как человек мыслит при решении проблемы итд.
Как ты думаешь можно ли улучшать третий пункт (природные данные) ?
Из своего опыта, я пока извлек то, что это чертовски трудно, если вообще возможно, тк вопрос лежит в области способа мыслить и вероятно нервной системы.
2 Библиотеки, велики, бизнес
Исключительно согласен с тобой, что велики это неотъемлемая составляющая качественного обучения, но зло для бизнеса.
Неоднократно замечал, что условный заказчик гораздо выше катирует разраба который по-быстренькому может склепать нужный набор фич из готовых библиотек и фреймворков. И всем плевать на то, что 80% кода из библиотек не используется, и связаны они лапшой которую поди разбери.
И получается бизнесу не интересен толковый разраб, который может глубоко копнуть в проблему и решить ее комплексно, но при этом это будет не быстро и не дешево. (Окей может и интересен, но это как ремонт телевизора, не можешь сделать — зови мастера)
Мастерство жанглировать библиотеками и страсть все делать великами, это две крайности в которых нужно искать золотую середину.
Можешь поделиться как ты искал (или ищешь) середину ?
Интересно мнение переводчика?)
Эм… извините, что я встреваю, но если честно, я не понимаю к кому конкретно вы обращаетесь, кому вы, простите, всё время «ТЫ»-каете. Вы обращаетесь к автору статьи? Тогда вам нужен Филип Уолтон. Вот его твиттер, если хотите, можете задать ему интересующие вас вопросы, уверен, что он с радостью на них ответит!
Если вы обращаетесь к моему коллеге Илье (переводчик этой статьи), то так и скажите:)
Что касается конкретно ваших вопросов, то я позволю себе высказать своё мнение.
1. Можно ли улучшить природные данные?
Я считаю, что можно. Здесь всё заключается в желании и воли к победе. Для того, чтобы добиться своей цели, нужно очень много трудиться, уделять всё своё возможное время на повышения знаний. Нужно постоянно рыться, копаться, стараться добиться своей цели любой ценой.
Возможно я говорю очевидные вещи, но это действительно работает. Мозг — это такая же мышца, как и остальные. Вы же можете пойти в спортзал и прокачать своё тело за какой-то срок? Вот и мозг можно прокачивать также, только не гирями, а знаниями. Например, вы писали о скорости мышления? Согласитесь, что скорость решения той или иной задачи зависит от того, насколько хорошо вы знаете её детали, от опыта работы с ними, и задачами подобного рода в целом. Логично, что, если вы сталкиваетесь с подобной задачей впервые, то и решение вы будете искать намного дольше. И т.д. с иными вещами.
Я думаю, что, если всё делать правильно и не лениться, то шанс есть)
2. Что касается надобности в изобретении великов.
Я считаю, что не важно, нужны ли на вашей работе какие-то велики или нет, суть в набивании шишек и получения ценного опыта в процессе их изобретения вами лично. Вы пробовали написать какую-нить js-библиотеку? А попробуйте, очень советую. Пока вы будете колупаться с ней, вы приобретёте столько знаний, что ваш уровень точно поднимется. Проверено на личном опыте! Если на вашей работе начальнику плевать на это, то изобретайте велосипеды в свободное от работы время, а на работе выполняйте поставленные задачи. Ещё раз повторюсь, что акцент идёт именно на получении знаний, опыта и повышения уровня. С хорошей копилкой и рабочие задачи уже будут решаться легче.
Только не следует накидываться на всё подряд и сразу бежать лепить велосипеды, делайте всё с умом, и всё у вас получиться!
Мне, как переводчику и человеку, которому очень далеко до выдающегося фронтендера, трудно судить, но всё же постараюсь ответить:
1) Да, я думаю, что «природные данные» можно развивать. Как и физические способности — тренировкой. Не каждому удастся побить мировой рекорд, но каждый может здорово улучшить собственные показатели. Найти для себя оптимальный режим/ритм работы и отдыха, изучать чужие решения (как советует Филип) и пробовать их на собственных хобби-проектах, практиковаться в быстром решении проблем, отвечая на вопросы на stackoverflow и его аналогах… И накапливать собственный багаж типовых приемов для типовых случаев, а заодно учиться видеть в новых задачах аналогии с уже решенными, чтобы максимально эффективно этот багаж использовать.
2) Вот насчет «великов» и «повторения» существующих решений я с Филипом не совсем согласен. Не стоит увлекаться преждевременной оптимизацией, если решение на базе готовых компонентов удовлетворяет заказчика и пользователи не жалуются на его тормоза/глюки/etc. Потом ничто не мешает потихоньку рефакторить такое решение, убирая лишнее и улучшая скорость/юзабилити и др. показатели (если на это найдется время, с чем часто бывает напряженка). И делать «велики», имхо, есть смысл не просто с целью повторить существующее решение, а именно с целью исправить какой-то его недостаток: сделать свой аналог легче, или быстрее, или кроссбраузернее, или приятнее для пользователя.
А вообще бывает, когда избыток знаний сам по себе не ускоряет, а тормозит работу. Наверное, уметь отличать, где надо копнуть глубоко и пусть не сразу, но выдать красивое и универсальное решение, а где надо по-быстрому сделать хоть что-то работающее, а потом, если действительно надо и есть когда, пытаться его улучшить — особая программистская мудрость. Которой я сам, к сожалению, пока так и не овладел… Ну и как всегда, про это есть XKCD:)
Этот неловкий момент когда не заметил, что это перевод, сори.
Спасибо за Ваши пояснения! Мудрость, наверное, в умении выбирать главное :-)
Про скорость, я бы сказал что больше всего на скорость влияет частота запуска отладки. Попробуйте писать много кода сразу, если получится его делать с разумным количеством ошибок, то увеличивайте объем. Это одновременно увеличивает вашу продуктивность, приводит к запоминания api и тренирует мозг, позволяя делать больший объем работы.
Привет, ребята.
Спасибо за статьи и рассылки.
Добрый день, не силён в теме (возможно пока), которой посвящена статья, но хочу поделиться хоть и дилетантским, но все-таки основанным на любительском изучении вопроса мнением о возможности прокачки » природных данных». Зачастую их нужно не улучшать, а поближе с ними познакомиться. К примеру молчаливый медлительный человек не обязательно тормоз, возможно он просто склонен к анализу и тщательно выверенным действиям, и медлительность это просто обратная сторона личности, не плюс и не минус, так он устроен. И намного продуктивнее не пытаться это изменить, а учитывать- зная свои особенности, принимать решения, например если человек склонен с принятию быстрых спонтанных решений, тормознуть себя на старте при решении какой-то задачи и ещё раз проанализировать условия, или рассмотреть несколько вариантов решения. Это мнение может показаться философскими размышлениями, но работает на практике при разумном подходе.