Наличие людей, у которых вы можете учиться, является неотъемлемой частью успеха разработчика. Никакое количество чтения не сможет полностью подготовить вас к постоянно меняющемуся веб-ландшафту, поэтому жизненно важно иметь возможность обращаться к опытным и опытным наставникам. Николас Закас — один из тех людей, к которым вы можете обратиться.
Николас, лидер в мире JavaScript и невероятно разбирающийся в масштабируемости и производительности, является одним из тех, кто помогает определять лучшие практики благодаря своему обширному опыту работы в таких компаниях, как Yahoo! и коробка. Одним из его самых удивительных качеств является его доступность и его желание действительно помочь продвинуть сеть.
Давайте перейдем к нашим вопросам и ответам, чтобы вы могли узнать немного больше об этом великом разработчике.
Q Начнем с обычного. Не могли бы вы кратко рассказать о себе?
Конечно. Я инженер-программист, который занимается веб-разработкой. Я люблю Интернет и с самого начала знал, что хочу сделать это своей карьерой. Эта любовь привела меня во многих направлениях, в том числе писать и говорить. В данный момент я работаю в Box, взяв на себя задачу помочь масштабам компании.
Q Вы были главным инженером внешнего интерфейса в Yahoo !. Я думаю, что для большинства из нас трудно понять работу в таком масштабе. Можете ли вы рассказать нам о проблемах, которые вы видели на Y! и как это сформировало ваше мышление с тех пор, как вы ушли?
Yahoo! был самый впечатляющий профессиональный опыт в моей жизни. До этого я был большой рыбой в маленьком пруду, и в первый день я понял, что сейчас нахожусь в океане. Решение проблем в обычном режиме и решение проблем в масштабе требуют двух разных способов мышления. В масштабе, никогда не бывает только «еще одной» вещи. В частности, я помню один разговор, когда кто-то хотел сделать дополнительный запрос Ajax, и я сказал нет. Он ответил: «В чем дело, это всего лишь еще одна просьба?» Мне пришлось объяснить, что еще один запрос на пользователя при миллионах пользователей означает резкое увеличение нагрузки на сервер, которое нам необходимо для планирования загрузки. Я посмеялся над этим, потому что я был на другой стороне этого разговора, когда впервые прибыл в Yahoo !.
На все, что я делаю, повлиял мой опыт в Yahoo !. Я одержим масштабируемостью и проблемами, связанными с ней, и с тех пор большая часть моей работы, как в Box, так и во время консалтинга, была направлена на то, чтобы помочь компаниям масштабировать свои веб-приложения. Мой опыт в Yahoo! сделал так, чтобы я понимал эти вопросы с разных сторон, не только с технической, но и с кадровой и организационной точек зрения.
Q Когда я читаю ваши труды, вы сильно сосредотачиваетесь на принципах информатики. Только в последние пару лет я увидел в этом всплеск. Где вы видите большую часть нынешнего поколения разработчиков переднего плана с точки зрения использования формализованных принципов CS в своей работе? Они все еще отстают?
Я думаю, что передовые разработчики все еще не имеют достаточных знаний в области компьютерных наук. Это правда, что наличие степени CS само по себе не гарантирует успеха как переднего разработчика, но это, безусловно, помогает. Я знаю несколько отличных FE, которые сейчас возвращаются и либо посещают курсы информатики формально, либо пытаются получить больше знаний по CS с помощью чтения и других средств.
Веб-приложения намного сложнее, чем раньше, и понимание шаблонов проектирования, абстракции и принципов архитектуры становится все более и более важным. Те, кто придет в отрасль без хорошего опыта в области КС, будут либо ограничены в своем профессиональном росте, либо начнут осваивать эти принципы КС иным способом. Я твердо верю, что лучшие и самые яркие — те, кто может вернуть принципы CS обратно во фронт. Независимо от того, проходит ли это формальное обучение или нет, эти знания становятся важными для развития вашей карьеры.
В том же духе, где вы видите, что разработчикам внешнего интерфейса не хватает навыков? Что они должны делать, но не должны?
Самая большая проблема, которую я вижу, это отсутствие организации кода. Частично проблема заключается в том, что веб-технологии, такие как CSS и JavaScript, в основном не имеют встроенной формы. В то время как у Java есть пакеты, а у C ++ есть, веб-технологии не дают вам формального способа организации вашего кода. Это приводит к плохой организации кода, а затем к плохой архитектуре, потому что нет также никаких встроенных шаблонов.
Изучение шаблонов проектирования, организации кода и принципов архитектуры принесет огромную пользу внешним инженерам. Не только за их код FE, но и за возможность конструктивно участвовать в разговорах о других частях своего технологического стека.
Q Я слышал разговоры, в которых тело стандартов ECMAScript получает толчок от очень громкой группы, которая называет себя «практиками» языка JavaScript и стремится к более практичным, реальным обновлениям JavaScript. Слышали ли вы об этом, и если да, как вы относитесь к этому и взаимодействию между традиционными сопровождающими JS и этой новой группой?
Да, определенно был приток практикующих, вовлеченных в комитет по стандартам. Это Рик Уолдрон и Йехуда Кац из jQuery Foundation и Эрик Феррайуоло из команды YUI на TC39 , люди с реальным опытом создания веб-приложений и библиотек JavaScript. Есть также много активных людей, которые регулярно участвуют в обсуждении и представляют точку зрения практикующего. Даже я вмешиваюсь время от времени, когда чувствую, что реальность не совсем пересекается с планами.
Это общение между практиками и теми, кто решает будущее направление технологий, которые мы используем, является обязательным условием. Через es-обсудить члены TC39, как правило, отзывчивы. Я смотрю на эти отношения как на отношения между гражданами и выборными должностными лицами. Если граждане не говорят чиновникам, что для них важно, чиновникам трудно это знать. Случайные люди, жалующиеся на что-то здесь или там, не заставляют кого-то думать об этом как о важном — это когда все критические массы протягивают руку и говорят «да, это важно», когда происходят изменения.
Q Похоже, что некоторые из них могут быть основаны с учетом принятия таких DSL, как CoffeeScript, TypeScript и Dart, которые, кажется, обеспечивают гибкость и мощность для разработчиков переднего плана. Это проблема языка или опыт разработчика?
Я чувствую, что это проблема экспертизы разработчика. Чаще всего я вижу, что люди, не имеющие большого опыта веб-разработки, решают, что это легко, поэтому они просто собираются что-то взломать. В конце концов, JavaScript выглядит как многие другие языки на основе C, и поэтому они начинают писать так, как если бы это был C, C ++ или Java — тогда они разочаровываются, потому что функциональность, к которой они привыкли, не существует … затем они обращаются к таким вещам, как CoffeeScript или Dart, потому что это возвращает им то, что они считают потерянным.
Если вы немного перевернете сценарий, если люди действительно потратили немного времени на изучение JavaScript перед тем, как погрузиться в него, я надеюсь, что будет большая оценка того, какой это уникальный и динамичный язык. К сожалению, «быстрые» и «быстрые» процессы разработки, как правило, побуждают людей не останавливаться и узнавать о том, что они пытаются сделать, а просто делать что-то, чтобы поддерживать скорость и результативность. Когда это происходит, поиск чего-то, что выглядит знакомым, имеет гораздо больший смысл, чем использование чего-то совершенно нового.
Вопрос: Одна вещь, которую вы действительно концентрируете на себе, — это производительность и попытки научить разработчиков оптимизировать свой код. Алекс Секстон написал отличную статью , посвященную этим направлениям, подробно описав роли, специально предназначенные для оптимизации. Это оптимальный путь для компаний, или каждый разработчик должен быть сведущ в нюансах производительности?
Для меня это слишком специфическая специализация. Как передовой инженер, ваша работа заключается в решении таких проблем, как производительность, ремонтопригодность, интернационализация, доступность и многое другое. Иными словами: если внешние разработчики не думают об этих вещах, то я не уверен, о чем они думают. По моему опыту, чем больше вы разделяете специализации, тем труднее убедить всех в том, что это их ответственность. «О, команда исполнителей позаботится об этом». «Это? Команда доступности будет беспокоиться об этом». Нельзя сказать, что у вас нет людей, которые оказываются в большей степени настроенными на определенные проблемы, но я считаю, что вы хотите, чтобы все в команде все время думали обо всех этих проблемах.
Q Вы всегда, кажется, находитесь на вершине передовых технологий, особенно с точки зрения JavaScript. Каков ваш процесс, чтобы оставаться в курсе всех изменений?
Я много читаю. Мой канал в Твиттере состоит в основном из новостных агрегаторов, которые позволяют мне быть в курсе происходящего. Я также много пишу, что, как мне кажется, приводит меня к областям исследований, на которые я обычно не обращаю внимания, пытаясь лучше объяснить вещи. Наконец, я постоянно экспериментирую, как самостоятельно, так и на работе, и смотрю на реальные проблемы, с которыми сталкиваются люди, чтобы понять, смогу ли я найти решения.
Q Последний вопрос. Если бы вам пришлось перечислить пять главных вещей, которые должны соответствовать передним разработчикам, чем бы они были?
- Изменяющийся ландшафт API — убедитесь, что вы знаете, что возможно
- Как эффективно использовать постоянно развивающиеся инструменты разработки
- Усилия по стандартизации — понимание того, что будет, а что нет и почему
- Каналы обратной связи браузера — вы должны их использовать
- Организация кода и шаблоны проектирования
закрытие
Спасибо, Николас, за то, что нашли время высказать это понимание.
Я призываю наших читателей следить за Николасом в Твиттере, а также зайти в его блог , где он публикует некоторые из наиболее часто упоминаемых статей о веб-разработке.