Недавно я получил письмо от читателя моего блога, которое, по какой-то причине, заставило меня задуматься. Письмо гласило:
Привет Филип, можно спросить, как ты стал отличным front-end-разработчиком? Можешь дать совет?
Признаться, я был удивлен тем, что подобный вопрос задают мне, так как я никогда не считал себя «отличным» front-end-разработчиком. На самом деле, я не уверен, что был достаточно квалифицирован для всего, за что брался, когда только начинал работать в этой сфере. Я подавал заявки на работу только потому, что не понимал, как мало я знаю, а получал её, потому что люди, на собеседование к которым я приходил, не знали, какие вопросы задавать.
Однако я, в конце концов, справлялся с каждой из своих ролей и становился ценным членом команды. Когда я собирался уходить (за новыми вызовами, к которым я также не был подготовлен), меня обычно просили подобрать себе замену. Оглядываясь назад и вспоминая те интервью, я поражаюсь, как много значения я придавал знаниям – несмотря на то, что поначалу мне самому их не хватало. Нынешний я, вероятно, не нанял бы прошлого себя, хотя теперь я знаю, что, теоретически, успех возможен.
Чем дольше я работаю в web-сфере, тем больше понимаю, что основное отличие хороших и очень хороших специалистов заключается не в объеме их знаний, а в том, как они мыслят. Разумеется, знания важны, иногда даже очень, но в среде, которая меняется настолько быстро, способность получать новые знания всегда перевешивает (по крайней мере, в долгосрочной перспективе) те знания, которыми вы уже обладаете. Но важнее всего то, как вы используете эти знания для решения каждодневных задач.
Существует множество статей, в которых рассказывается про языки, фреймворки и инструменты, необходимые для получения работы. Я хотел применить другой подход. В этой статье я собираюсь рассказать о складе ума front-end-разработчика и надеюсь, что смогу дать наиболее полный и развернутый ответ на вопрос: «Как стать отличным разработчиком?»
Не просто решайте проблемы – пытайтесь понять, что на самом деле происходит с вашим кодом
Слишком многие из тех, кто работает с CSS и JavaScript, что-то мастерят до тех пор, пока это «что-то» не заработает, а затем двигаются дальше. Я наблюдаю подобную картину постоянно, когда просматриваю чей-то код.
Я часто спрашиваю: «Почему вы добавили сюда float: left?» или «overflow: hidden действительно здесь необходим?» В ответ на это часто звучит фраза: «Я не знаю, но если я уберу это, то ничего не заработает».
Та же история с JavaScript. Я вижу, как setTimeout используется, чтобы предотвратить состояние гонки, или как кто-нибудь останавливает распространение событий, не заботясь о том, что это действие повлияет на другие обработчики событий страницы.
Я понимаю, что есть ситуации, когда вам нужно, чтобы что-то работало, причем немедленно. Но если вы не будете тратить время на то, чтобы разобраться в своей проблеме, то продолжите наступать на одни и те же грабли.
Вы можете считать, что пытаться понять, почему ваш способ решения проблемы сработал – это пустая трата времени, но я обещаю, что это поможет вам сохранить время в будущем. Если вы полностью разобрались в системе, с которой работаете, то при решении проблем не будете угадывать, но будете понимать, почему нужно сделать так, а не иначе.
Учитесь предугадывать будущие изменения технологий
Одно из главных отличий front-end и back-end кода заключается в том, что back-end код чаще всего выполняется в среде, находящейся под вашим контролем. Front-end, наоборот, находится за пределами вашего контроля. Платформа или устройство пользователя может полностью измениться в любой момент, поэтому ваш код должен уметь непринужденно с этим справляться.
В 2011 году я как-то читал исходный код одного популярного JavaScript-фреймворка и увидел там нижеследующую строчку (я её немного упростил): var isIE6 = !isIE7 && !isIE8 && !isIE9;
В этом случае код обрабатывал все версии IE старше шестой, но как только вышла версия IE10, значительные части нашего приложения полностью перестали работать.
Я понимаю, что в реальном мире feature detection не дает 100% гарантий, и иногда вам приходится учитывать неправильное поведение браузеров и считаться с теми из них, у которых feature detection ошибочно возвращает положительные (или отрицательные) значения. Но если вы делаете это, необходимо гарантировать такое будущее, где эти баги больше не проявятся.
Код, который мы пишем сегодня, будет существовать еще долго – даже после того, как мы уйдем с текущей работы. Часть кода, который я писал более 8 лет назад, все еще работает на крупных сайтах – эта мысль одновременно дает повод для гордости и беспокойства.
Читайте спецификации
Баги в браузерах были, есть и будут, но когда два браузера обрабатывают один и тот же код по-разному, люди часто предполагают, никак не проверяя, что так называемый «хороший браузер» прав, а «плохой» неправ. Но это не всегда так, и если такое предположение окажется ошибочным, любые вносимые вами изменения практически наверняка приведут к краху в будущем.
Злободневным примером этого может послужить стандартный размер flex-элементов. На основании спецификации, начальные значения min-width и min-height для flex-элементов равны auto (но не нулю), а это означает, что по умолчанию они не должны становиться меньше минимального размера их содержимого. Последние восемь месяцев FireFox был единственным браузером, в котором это было реализовано корректно [1].
Если бы вы столкнулись с такой кросс-браузерной несовместимостью и заметили, что ваш сайт выглядит одинаково в Chrome, IE, Opera и Safari, но по-другому в FireFox, то, вероятно, предположили бы, что FireFox неправ. На самом деле я сталкивался с подобным многократно. Мне часто писали, что у моего проекта Flexbugs есть проблема подобной несовместимости, но если бы я пытался как-то это обойти и внедрил несколько решений, то все бы порушилось буквально две недели назад с выходом Chrome 44. Возможные решения проблемы не столько соответствовали требованиям спецификаций, сколько пытались компенсировать (на самом деле) правильную работу браузера [2].
Когда два браузера отображают один и тот же код по-разному, вам нужно потратить время и понять, какой из них работает верно, чтобы в соответствии с этим править свой код. Тогда в будущем не придется ничего переделывать.
Добавлю, что так называемые «отличные» front-end-разработчики – это люди, находящиеся на передовой, которые адаптируют новые технологии до того, как те станут популярными, и даже вносят свой вклад в их разработку. Если вы разовьете в себе привычку заглядывать в спецификации и представлять, как будет работать технология еще до её появления во всех браузерах, то станете частью избранной группы и сможете понимать и влиять на разработку спецификации.
Читайте код, написанный другими
Чтение кода других людей для развлечения, вероятно, не то, чем вы хотите заниматься субботним вечером, но это, вне всяких сомнений, один из лучших способов улучшить свои навыки разработчика.
Самостоятельно решать проблемы – это отличный способ обучиться, но если это все, чем вы будете заниматься, то вы достигнете предела своих возможностей довольно быстро. Читая код других людей, вы открываете свое сознание для новых способов решения задач. Способность читать и понимать код, который писали не вы, очень важна, если вы работаете в команде или участвуете в открытых проектах.
Я считаю, что одна из самых крупных ошибок, которую делают компании при найме новых инженеров, заключается в том, что они просят их написать код – новый код, с нуля. Я никогда не был на интервью, где бы меня попросили оценить существующий код, найти в нем ошибки и исправить их. Это очень плохо, потому что большую часть времени инженера занимает дополнение или изменение существующей базы. Очень редко вы создаете что-то с нуля.
Работайте с теми, кто умнее вас
У меня создалось впечатление, что гораздо больше front-end-разработчиков, чем back-end-разработчиков, хотят заниматься фрилансом (все время работать самостоятельно). Возможно, это происходит потому, что front-end-разработчики часто учатся самостоятельно, а вторая категория большую часть своих знаний получает в университетах.
Проблема здесь в том, что, занимаясь самообразованием и работая на себя, вы не получаете выгод и опыта от работы с людьми, которые умнее вас. Вам не с кем обсудить идею или код. Я рекомендую хотя бы на начальном этапе своей карьеры поработать в команде, где люди умнее и опытнее вас.
Если вы в какой-то момент начнете работать на себя, станьте (или останьтесь) частью открытых проектов. Активное участие в подобных вещах даст вам те же преимущества, что и работа в команде, а иногда даже больше.
Изобретайте велосипед
Изобретать велосипед плохо для дела, но хорошо для обучения. Вы можете соблазниться и схватить типовой виджет или библиотеку делегирования событий из npm, но только представьте, насколько больше вы узнаете, пытаясь написать эти вещи самостоятельно.
Я уверен, что часть читателей этой статьи сейчас начнет возражать. Но не поймите меня неправильно. Я не говорю, что вы не должны использовать готовый код. Использование отличных и проверенных библиотек, баги которых исправлены, а преимущества подтверждены несколькими годами тестирований, практически всегда очень хорошее решение.
Но в этой статье я говорю о том, как из хорошего разработчика превратиться в отличного. Большинство людей в этой индустрии, которых я считаю великими, сами создали или помогли с поддержкой очень популярных, постоянно используемых мною библиотек.
Разумеется, вы можете сделать успешную карьеру, не создавая собственные библиотеки JavaScript, но тогда у вас не будет возможности досконально разобраться в деле, которым вы занимаетесь.
Люди, занятые в этой индустрии, часто задают один и тот же вопрос: «Что мне делать дальше?» Если вы задаетесь этим вопросом вместо того, чтобы пытаться изучить новый инструмент или создать новое приложение, почему бы не попытаться воссоздать одну из ваших любимых JavaScript библиотек или один из CSS-фреймворков?
Пишите о том, что узнали
И последнее, но не по значению: пишите о том, что узнали. Есть огромное количество причин, по которым этим стоит заниматься, но самая главная заключается в том, что это заставляет вас лучше разбираться в вопросе. Если вы неспособны объяснить, как что-то работает, есть шанс, что вы сами плохо себе это представляете. Очень часто вы даже не знаете, что не до конца разобрались, пока не пытаетесь выразить свои слова на бумаге.
По собственному опыту скажу, что написание статей, общение и создание моделей – это самые лучшие способы заставить себя погрузиться и полностью разобраться в каком-либо вопросе. Даже если никто не читает то, что вы пишите, пусть так – важен сам процесс.
Примечания: FireFox внедрил изменения спецификации в версии 34 от 1 декабря 2014 года. Chrome сделал это в версии 44 от 21 июля 2015 года, а это значит, что и Opera скоро до этого доберётся. Edge вышел в свет 29 июля 2015 года и работает согласно спецификации. Работа над Safari, по всей видимости, ведется. Вы можете считать Flexbug #1 хорошей кросс-браузерной «заплаткой» для решения этой проблемы.
Наши публикации по теме разработки и проектирования:
- Какие технологии чаще всего используются на хакатонах
- 200 блогов по разработке и проектированию
- Работаем с User stories: Руководство Gov.uk
- Gov.uk: базовые аспекты методологии agile
- Проектирование продукта с ориентацией на пользователя
- Принципы управления разработкой сервиса от Gov.uk
- Руководство: Как построить слаженную команду
- Из хакера в маркетологи: Чему можно научиться за год работы
