В первые годы я искренне (думаю как и многие на моём месте), не считал себя достаточно подготовленным для работы, на которую устраивался. Я предлагал свою кандидатуру лишь потому, что не понимал, как в действительности мало знаю, а брали меня на работу, лишь потому, что люди, проводившие со мной собеседование, не знали, что спрашивать.
При всём при этом, в конечном итоге я неплохо справлялся с каждой из своих ролей и со всеми поставленными передо мной задачами, становясь ценным членом команды. Когда я в конце концов уходил (чтобы принять новый вызов, к которому я тоже был не подготовлен), как правило мне приходилось самому подыскивать себе замену. Оглядываясь на то, как я проводил те небольшие собеседования, я удивляюсь, какое большое значение я придавал знаниям — при том, что у меня самого поначалу их было маловато. Сейчас я вряд ли взял бы на работу тогдашнего меня, хоть я и знаю, по личному опыту, что успех с таким малым багажом заний возможен.
Чем дольше я работал в вебе, тем больше понимал, что хороших специалистов от действительно хороших специалистов отличает не то, что они знают, а то, как они думают. Конечно, знания важны, в некоторых случаях критичны, но в сфере, которая так быстро меняется, подход к получению знаний всегда будет важнее (по крайней мере, в долгосрочной перспективе), чем то, что вы знаете в данный момент. И, пожалуй, самое важное: как вы используете эти знания при решении повседневных задач.
Есть множество статей, рассказывающих о языках, инструментах и фреймворках, необходимых вам, чтобы найти хорошую работу. Я же хотел подойти с другой стороны. В этой статье я собираюсь рассказать про мысленную установку фронтенд-разработчика, и надеюсь, дать более надёжный ответ на вопрос «как стать выдающимся».
Для начала, на мой взгляд уже прописная истина.
Фронтенд-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с фронтенд-разработчиком, который занимает центральное место в цепочке разработки, и при этом имеет дело с большим количеством разных специалистов. Фронтенд-разработчик должен понимать работу связанных с ним специалистов (в некоторых случаях достаточно довольно поверхностного знания) и иногда подсказывать, что и как сделать лучше.
И ещё одно отступление, для большинства эта рекомендация будет более чем очевидна: используйте препроцессоры для CSS
Препроцессоры, прочно вошли в жизнь фронтенд-разработчика, это уже стандарт. SCSS, SASS, LESS и прочие нужно использовать по одной простой причине: они увеличивают скорость вёрстки. Если сразу не приходит понимание, то уверяю со временем вы поймёте сколько времени сэкономили используя вложенные стили, примеси, переменные и прочие приятные мелочи.
Теперь к сути)
Слишком многие из тех, кто пишет CSS и JavaScript, находят работающее решение «методом тыка» и тут же переходят к следующей задаче. Я знаю об этом, потому что постоянно вижу это, оценивая чей-либо код, а ещё потому что сам когда-то этим грешил.
Я часто спрашиваю кого-нибудь: «Зачем ты поставил здесь float:left?» или «А этот overflow:hidden действительно необходим?», и мне отвечают: «Не знаю, но если это убрать, оно не будет работать».
То же самое справедливо для JavaScript. Я могу наткнуться на setTimeout для предотвращения «race condition», или как кто-то останавливает всплытие событий, не задумываясь, как это скажется на других обработчиках событий на странице.
Понимаю, что бывают моменты, когда нужно что-то работающее, и немедленно. Но если вы никогда не выкроите время, чтобы понять причины проблемы, то будете наступать на одни и те же грабли снова и снова.
Выяснять, почему ваш хак работает, может показаться лишней тратой времени сейчас, но я ручаюсь, что это сбережёт вам время в будущем. Более глубокое понимание систем, с которыми вы имеете дело, означает меньше проб и ошибок в дальнейшей работе.
Одно из главных отличий между кодом фронтенда и бэкенда в том, что код бэкенда как правило исполняется в окружении, которое целиком под вашим контролем. Фронтенд, напротив, в большей степени вам неподконтролен. Платформа или устройство у ваших пользователей может полностью смениться в любой момент, и ваш код должен изящно отреагировать на это.
Я помню, как просматривал исходник популярного JavaScript-фреймворка в 2013-м и наткнулся на следующую строчку:
var isIE6 =!isIE7 &&!isIE8 &&!isIE9;
В этом случае код обрабатывал все версии IE старше шестой, но как только вышел IE10 — изрядная часть функциональности полностью отвалилась.
Я понимаю, что в реальном мире определение возможностей не всегда работает на 100%, и иногда приходится зависеть от глючной реализации или белого списка браузеров, в которых доступные возможности ошибочно определяются как отсутствующие и наоборот. Но каждый раз, когда вы такое делаете, критически важно, чтобы вы были готовы к тому, что в будущем этих багов почти наверняка не будет.
У браузеров всегда будут баги, но когда два браузера отображают один код по-разному, люди часто предполагают, не проверяя свою догадку, что так называемый «хороший» браузер прав, а «плохой» браузер ошибся. Но это не всегда так, и если вы ошиблись в своем предположении, то выбранный вами обходной путь почти наверняка в будущем перестанет работать.
Пример этого из наших дней — минимальная ширина флекс-элементов по умолчанию. По спецификации, исходное значение у min-width и min-height для флекс-элементов — auto (а не 0), что значит, что они не должны ужиматься меньше минимальной ширины своего содержимого. Долгое время, около 8-9 месяцев Firefox был единственным браузером, где это было реализовано правильно.
Если вы наткнулись на несоответствие между браузерами и заметили, что ваш сайт одинаково отображается в Chrome, IE, Opera и Safari, но иначе выглядит в Firefox, вы можете предположить, что неправ Firefox. Я много раз был тому свидетелем, когда предложенные обходные пути, будь они реализованы, перестали бы работать спустя какое-то время, при обновлении браузера. Вместо того, чтобы обходными путями добиваться следования спецификации, многие по незнанию «наказывают» правильное поведение.
Когда два браузера и более отображают код по-разному, нужно найти время на то, чтобы разобраться, кто из них прав, и писать код с учётом этого. Тогда ваши обходные решения будут намного надёжнее в будущем.
Кроме того, те, кого называют «выдающимися» фронтендерами — зачастую люди с «передовой» прогресса, которые осваивают технологии ещё до того, как они станут мейнстримом, и даже участвуют в разработке этих технологий. Если вы разовьёте умение смотреть в спецификацию и представлять себе, как технология будет работать, ещё до того, как сможете «поиграть» с ней в браузере, вы попадёте в группу избранных, которые могут рассуждать о разработке спецификации и даже влиять на неё.
Чтение чужого кода — не самое приятное развлечение, но без всяких сомнений один из лучших способов повысить свой профессиональный уровень.
Самостоятельное решение проблем — отличный способ учиться, но если вы будете заниматься только этим, вы достаточно быстро окажетесь на плато. Чтение чужого кода открывает ваш ум новым способам решения задач. А умение читать и понимать код, который вы не писали, при работе в команде или участии в опенсорсном проекте — самое важное.
Я действительно считаю, что одна из крупнейших ошибок компаний при найме новых программистов — то, что их заставляют лишь писать код, новый код с нуля. Мне практически не доводилось бывать на собеседованиях, где меня попросили бы прочитать существующий код, найти в нём ошибки и исправить их. Это очень плохо, поскольку больше всего времени у программиста уходит на дополнение и изменение существующего кода. Редко приходится писать что-то с нуля.
У меня сложилось впечатление, что фронтендеров, тяготеющих к фрилансу (и вообще к работе на себя), намного больше, чем бэкендеров, стремящихся к тому же. Возможно, это потому, что фронтендеры — чаще самоучки, а бэкендеры — чаще выпускники профильных вузов.
Проблема самоучек, работающих на себя, в том, что им обычно недоступны плюсы учёбы у более знающих людей. Нет того, кто помог бы очистить ваш код от глупостей или хотя бы просто оценить его.
Я настоятельно рекомендую вам, как минимум на начальном этапе карьеры, работать в команде, а именно — в команде людей, которые умнее и опытнее вас.
Если в какой-то момент своей карьеры вы перейдете к работе на себя, возьмите себе за правило участвовать в опенсорсных проектах. Активное участие в таких проектах даёт те же плюсы, что и работа в команде, а порой даже больше.
Частый вопрос, который задают люди в этой отрасли: "что бы такого написать ещё?" Если этот вопрос встал перед вами, то вместо того, чтобы выучить новый инструмент или создать какое-то новое приложение, почему бы не повторить что-то из ваших любимых JavaScript-библиотек или CSS-фреймворков? Приятный момент здесь в том, что если даже у вас возникнут трудности, то в исходнике существующей библиотеки найдутся ответы.
Изобретать велосипеды — плохо для бизнеса, но замечательно для обучения. Как бы ни было соблазнительно взять некий готовый скрипт для подсказок при наборе или библиотеку анимации, только представьте, чему вы научитесь, хотя бы попытавшись написать подобное самостоятельно.
Уверен, некоторые читатели этой статьи прямо сейчас готовы резко возразить. Не поймите меня превратно. Я не утверждаю, что никогда не нужно пользоваться сторонним кодом. Использование проверенных библиотек, с преимуществом в виде многих лет тестирования и отлова ошибок — разумный шаг в подавляющем большинстве случаев.
Но в этой статье я говорю от том, как из хорошего стать выдающимся. Многие из тех, кого я считаю выдающимися в этом деле — создатели и кураторы популярнейших библиотек, которыми я всё время пользуюсь.
Наверное, можно с успехом работать, не написав ни одной собственной JavaScript-библиотеки, но тогда вряд ли вам удастся в полной мере прочувствовать этот материал «на собственной шкуре».
Последнее, но, безусловно, не менее важное — вам стоит писать о том, чему вы научились. Для этого есть масса хороших причин, но, наверное, самая важная — это заставит вас лучше понять тему. Если вы не можете объяснить, как что-либо работает, есть изрядная вероятность, что вы сами в этом не разобрались. И зачастую трудно понять это, пока вы не опишите это в подробностях.
По моему опыту, писать статьи, создавать демки — один из лучших способов заставить себя самого углубиться в что-либо и понять это полностью, снаружи и изнутри. Даже если вашу писанину никто не будет читать, сам процесс более чем стоит того.
Комментарии ()