Квалификационные задания на JS-разработчика
order by id desc
Часть вторая. Практика
Для запуска\сборки нужен npm и gulp установленные глобально.
- Запуск дев-сборки и сервера:
npm run dev:server - Продакшн сборка:
npm run prod:build
Также необходимо в корне проекта создать файл .gmkey и скопировать в него апи ключ для гугл-карт, иначе система сборки пошлет вас
ЗЫ: Я до этого никогда не писал тестов, и тем более ни делал ничего по TDD, и в настоящий момент я решил их не делать в данном задании. Это будет мое TODO
Часть первая. Теория
1. Расскажите, чем, на ваш взгляд, отличается хорошее клиентское приложение от плохого с точки зрения...
...пользователя:
Рассматривая некое абстрактное приложение, то хорошим для пользователя можно считать приложение, которое соблюдает большинство или все следующие пункты
- интуитивность/понятность
- отзывчивость
- скорость
- необходимость :)
Большинство этих характеристик условны и перетекают друг-в-друга, и соответственно влияют друг-на-друга, но для удобства анализа мы их все таки выделим. Зачастую невозможно добиться положительного результат по всем пунктам, например интуитивности сложно достичь, когда предметная область приложения комплексная, и как следствие мы получаем такой же интерфейс. Но учитывая это, мы можем написать гайд\тур, частично нивелируя сложность. Ну и привычки коллективного пользователя меняются, много интерфейсов когда-то были неинтуитивными.
Отзывчивость, тут надо пояснить что я под этим имею ввиду, это то, как приложение реагирует на пользовательские действия. Тут вроде все просто: каждое действие порождает какую-то видимую для пользователя реакцию: управляющие элементы реагируют на кликанье\наведение\отправление и тд.
Скорость сильно зависит от "реального мира" и где находится сервер для нашего клиента. В случае если клиент и сервер на одном компьютере(где уже, наверное, неуместно называть их клиентом и сервером, но скорее гуем и ядром приложения), то скорость зависит только от мощности клиентской машины. В случае же если мы общаемся с сервером посредством известных сетевых протоколов, то сюда добавляется скорость сети. Частично этот пункт(собственно как и первый "десктопный" случай)зависит от разработчика и примененых им решений к архитектуре и оптимизации.
Ну и конечно нужность\необходимость может перечеркнуть все плюсы и минусы. Если приложение не нужно пользователю, он им не будет пользоваться, даже если оно будет максимально "юзабельным", максимум поиграется. Если нужно, то за неимением лучших альтернатив, или по привычке с наличием оных, будет есть кактус, сплевывая иголки, но принимая полезность :)
...менеджера проекта:
Наверное, с точки зрения управления производством тут сложно придумать, чем клиентское приложение отличается от любого-другого ПО. Но есть особенность, которая делает важный инструмент разработки ПО вообще, в клиентском приложении еще более важным. Это итерацционная, модульная разработка. Так как клиентское приложение неразрывно связано с пользовательским интерфейсом, то это значит его можно(и как я знаю, нужно) показывать конечному заказчику в период разработки. На начальном этапе или наработке фич, в данном случае неважно. Важно то, что имея последовательную, продуманную, модульную разработку, мы можем презентовать заказчику промежуточные результаты. Будь то отдельные куски интерфейса в СПА, или отдельные страницы в многостраничных сайтах. Ну и проще контроллировать процесс: дизайнеры/верстальщики/разработчики/тестировщики работают над отдельными модулями не накладываясь друг-на-друга. Так что хорошим клиентским приложением для ПМа, в первую очередь, является приложение разрабатываемое модульно
...дизайнера:
Мне сложно придумать тут что-то кроме одного: соответствие конечного результата задумке дизайнера
...верстальщика:
Тут всё просто(ну как мне видится): верстальщику нужно превращать макеты и\или идеи дизайна в верстку, для этого ему нужно использовать/наследовать имеющиеся куски верстки и создавать новые. Он должен быть уверен, что существующие элементы легко переиспользовать, наследоваться от них, модифицировать не меняя основы. Для этого на проекте может быть использована своя или имеющаяся система для организации стилей, например БЭМ(единственная,которую автор использовал на практике). Также можно использовать движки для шаблонизации и облегчения написания HTML, все для того же, чтобы можно было легко композировать(есть такое слово?), изменять и переиспользовать куски разметки. Конечно все это должно быть в виде удобной и понятной системы директорий: для стилей(например, по блокам), для разметки,для скриптов. Также неплохо было бы, чтобы сборщик проекта(куда без них) был настроен согласно удобной внутреней конвенции т.е., например, были скрипты, одноименные файлам страниц, или модулей, подключались бы автоматически. Или были бы настроены готовые таски и скрипты на создание страниц\скриптов\стилей или бандлов всего этого. Вообщем, чтобы рутинная работа была сведена к минимуму.
Ну и не совсем про приложение, но про смежное: дизайн должен быть...консистентным? Как можно меньше элементов с одинаковым функционалом и разным внешним видом, меньше зоопарка цветов и тд.
...серверного программиста:
Никогда не сталкивался в работе с четким разделением на серверную и клиентскую часть(но хотелось бы)). Но могу предположить, что хорошее клиентское приложение, в лице разработчиков этого приложения, присылает на ендпойнты все что нужно, ничего лишнего, не просит создавать новые точки входа без особой необходимостии и т.д. и т.п.
2. Опишите основные особенности разработки крупных многостраничных сайтов, функциональность которых может меняться в процессе реализации и поддержки. Расскажите о своем опыте работы над подобными сайтами: какие подходы, инструменты и технологии вы применяли на практике, с какими проблемами сталкивались и как их решали.
Очевидно(наверное), что в таких проектах необходимо поддерживать хорошее состояние кодовой базы, то есть проводить код-ревю и рефакторинг через произвольные промежутки времени. Ибо разработчик может упороться, не иметь достаточно времени, чтобы сделать хорошо, ибо нужно "сейчас", не иметь опыта, не придумать хорошего решения, но словить озарение позже. Еще, учитывая, что это большой проект, скорее всего в нем есть некоторая текучка, люди могут приходить и уходить. Соответственно нужно, чтобы были установлены стандартны оформления на уровне проекта или компании. Может даже линтер соответствующе настроен). Я при написании понял, что просто конспектирую must-have список, а не свой собственный опыт)). Единственное, что хотелось бы подметить из личного опыта, что код, особенно если он не самый заурядный, должен быть либо написан так что он прозрачен при чтении, либо минимально задокументирвован. Чтобы избежать ситуаций, когда нужно что-то поменять или убрать, когда тебе нужно звать коллегу и он будет тратить свое время, или ситуацию зеркальную предыдущей. В целом, всё вышеописанное, и все что я могу написать, можно отнести и к маленьким проектам, но на больших проблемы стреляют больнее.
3. При разработке интерфейсов с использованием компонентной архитектуры часто используются термины Presentational Сomponents и Сontainer Сomponents. Что означают данные термины? Зачем нужно такое разделение, какие у него есть плюсы и минусы?
Кратко, чтобы не пересказывать всем известные статьи: Presentational Component(далее ПЦ) отвечает только за сам UI и если содержит логику, то только логику отображения, то есть самого интерфейса, никак не взаимодействует с остальным приложением, кроме как вызовом методов переданных ему. Container Component(далее ЦЦ) "оборачивает" ПЦ прокидывая в него нужные данные, отвечает за связь с хранилищем. Данный подход помогает переиспользовать ПЦ(визуал) с разными ЦЦ(данными). Также это удобный способ организовывать приложение: знаешь где данные приложения, а где его UI. А минусы я не знаю, так как ни разу не использовал подобный подход в крупных проектах, да и на продакшене вообще ¯\_(ツ)_/¯
Я знаю, что в статье, где предлагается этот паттерн, появилась пометка за 2019 год связанный с хуками и ненужностью этого паттерна в связи с последними обновлениями, но я с ними еще не разбирался, поэтому, чтобы не быть живой иллюстрацией мема, не буду о них ничего писать
4. Как устроено наследование в JS? Расскажите о своем опыте реализации JS наследования без использования фреймворков.
Не было опыта, по крайней мере в продакшене. Даже сахар в виде классов не использовал. Но в теории, если кратко, понимаю, что если у объекта есть свойство __proto__, ссылающееся на другой объект, то все его поля будут также принадлежать "родителю"(речь не про термин из наследования). Ну и зная это, можно легко построить механизм наследования.
5. Какие библиотеки можно использовать для написания тестов end-to-end во фронтенде? Расскажите о своем опыте тестирования веб-приложений.
До вашего тестового опыт написания тестов был чисто "игрушечный" и чисто модульный. Так что о e2e я только читал, и никакой даже приблизительной мысли, что творится в этой сфере, не имею. Но с удовольствием бы попробовал, но для этого нужен реальный проект...
6. Вам нужно реализовать форму для отправки данных на сервер, состоящую из нескольких шагов. В вашем распоряжении дизайн формы и статичная верстка, в которой не показано, как форма должна работать в динамике. Подробного описания, как должны вести себя различные поля в зависимости от действий пользователя, в требованиях к проекту нет. Ваши действия?
Ну тут есть алгоритм для таких ситуаций вцелом: если можешь, то пишешь/идешь к дизайнеру, если это не принесло никаких удовлетворительных результатов или занимает слишком много времени, то рекурсивно повторяешь тоже самое с менеджером. Если по прежнему ничего, то
-
выполняешь другю задач(у\и) если он(а\и) есть, если проблема в отсутвии времени вообще или у дизайнера\менеджера в частности
-
выполняешь эту задачу применяя к ней стандарты похожих выполненных задач и своё чувство прекрасного, но просто, чтобы не тратить много времени, в случае если нужно будет переделать и\или улучшить.
Рассматривая ситуацию в вопросе: если все походы по инстанциям(:)) не увенчались успехом, и с другими задачами не сложилось, то, если на проекте есть похожие формы, делаешь похоже на них. Если нет, то делаешь максимально простой прототип, который можно было бы в дальнейшем улучшить.
7. Расскажите, какие инструменты помогают вам экономить время в процессе написания, проверки и отладки кода.
Второй монитор неплохо помогает :). Если более серьезно(хотя в шутке про монитор доля правды велика), то очень помогает именно знание инструмента. на последнем месте работы я использовал PHPStorm, так как он был у нас стандартом, который конечно прикольный, но я не понимал его полностью, хотелось чего-то прозрачнее. После увольнения вернулся к простым редакторам, а конкретно к VSCode, я уже не помню чем конкретно, он мне так понравился, учитывая, что атом в своё время не произвёл на меня впечатления, но помню, что понравились горячие клавиши по умолчанию, и как все организовано, в плане интерфейса. Плюс, когда у тебя не здоровый IDE-комбайн, то тебе нужно место где нужно проводить всякие сборщики, контроль версий и тд. Если с линтерами успешно справляется сам VSCode, то на всё остальное у меня обычный терминал с запущенным в нем tmux'ом. Очень удобно, особено в связке с tmuxinator, можно запускать проект и окружение одной строчкой. Плюс если мы говорим о клиентском js, то debugger в dev-tools отличная штука.
8.1. Какие ресурсы вы используете для развития в профессиональной сфере? Приведите несколько конкретных примеров (сайты, блоги и так далее).
Хабр, медиум(не только по айти), стаковерфлоу, реддит(хотя там больше смеха ради). Подписан на несколько ютуб-каналов с it-тематикой, но единственное, что смотрю с интересом это яндекс(разные каналы) и конечно хекслет. Прошел еще у них курсы по джсу год назад. Постоянно прислушиваюсь к тому что говорят Рахим и Кирилл, хорошо прочищают голову. Раньше сидел у них в слаке, но это больше трата времени, чем что-то полезное. Плюс некоторые разрознённые телеграм каналы, но изза незавидной регулярности их, и не очень удобной организации пространства в телеге, это все очень приходяще-уходящие источники.
8.2. Какие ещё области знаний, кроме тех, что непосредственно относятся к работе, вам интересны?
Музыкант-любитель(гитара/барабаны/вокал), история, философия. Может оказаться интересным науч-поп почти по любой теме, начиная от здоровья(физиологии) заканчивая физикой. Хочу заняться математикой, наверстать упущенное, что отрицал в школе и универе.
Из около-программных тем: регулярно читаю, что пишет Денис СексиАЙТИ(забыл настоящее имя, чувак из ИД Комитет) про современный ИИ и все смежное. Ещё кино люблю. Как все вообщем: всего понемногу.
9. Расскажите нам немного о себе и предоставьте несколько ссылок на последние работы, выполненные вами.
С 2015-2018 год работал разработчиком в нескольких компаниях в своем родном городе Барнаул. Сперва чисто верстальщиком в небольшой локальной студии, затем полноценным fullstack-разработчиком в компании "Сибирикс", может быть это слово для вас что-то будет значить. В настоящий момент переехал в Москву и ищу работу. Хочу делать интересные штуки и прокачиваться. Хорошо, что поток моей графомании иссяк как раз на том пункте, который должен притягивать ее как магнит :)
Работы:
Из недавнего тестовое для CSSSR
Последнее по работе:
Без исходников, но хоть что-то