StormX

Давайте обратимся к данной публикации, чтобы понять примерные тренды, потому что наиболее выгодный вариант – это все же фронтендер.

Вкратце, полноценный клиентский разработчик должен знать:
– html5/css3 + bootstrap
– один-два препроцессора (less/stylus)
– чистый js и пару-тройку клиентских библиотек или фреймворков (knockout/backbone/angular/react)
– немного node.js, чтобы уметь пользоваться пакетным менеджером (npm) и билд-менеджером (gulp/grunt)

Этот список покрывает большинство клиентских задач в средней студии или стартапе.

В реальности, от разработчика требуется только одно – уметь быстро накостылять какую-нибудь фичу к релизу, который должен был быть вчера. Собственно, если внимательно посмотреть на список, который я привел, можно заметить, что все эти вещи направлены на максимально быструю разработку – тут костыль, там костыль – и в продакшн. Как бы ни пытались нагнать пафоса на собеседовании, в бою будет именно так.

Другой вопрос – что со всем этим делать.

Я обычно предлагаю попытаться начать свой маленький проект. Какой-нибудь простенький личный сайт, игру на js (тот же flappy bird или 1048 – много ума здесь не нужно). Посложнее – свою тему или библиотечку. Это будет хорошим практическим опытом, который не стыдно описать в резюме.

Обязательным навыком является быстрое чтение документации (желательно на английском) и понимание того, что происходит в коде, который вы видите первый раз в жизни. Советую потренироваться на различных проектах с открытым исходным кодом.

Если говорить о личном опыте, то я неплохо подтянул js с помощью codewars – задачки начинаются от самых простых (преобразование строк, перебор массива), до очевидно тяжелых (собственные интерпретаторы и преобразование данных изображения).

А вот попытка спихнуть на верстальщика UI/UX – это уже экономия со стороны отдельных контор, которые по какой-то причине не хотят нанимать отдельного дизайнера/проектировщика в штат или по контракту. Тут, к сожалению, придется мириться и смотреть статьи по теме – тот же GoodUI.

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Super позволяет вам получить доступ к методу конструктора родительского класса. Единственной причиной включения реквизита является доступ к this.props внутри вашего конструктора.
https://stackoverflow.com/questions/30571875/whats...

Если мы говорим о JS, то:

• имена переменных должны быть существительными (id, name, count);
• имена функций должны начинаться с глаголов (getId, parseName, setCount);
• имя константы должно быть записано прописными буквами, а слова должны быть разделены нижним подчеркиванием (MAX_COUNT);
• имя объекта, обернутого jQuery, должно начинаться с $ ($el, $this);
• имена функции-конструкторов должны начинаться с заглавной буквы (Plugin, Number, String);
• избегайте слишком абстрактных названий, например, temp, foo, bar.

> Насколько я понимаю, смысл mock-функций в jest - это заглушки для функций, чтобы не тащить код всего модуля и не замедлять процесс тестирования.

Это не совсем так. Моки подразумевают, что вы прямо проверяете то что мокаете. Что функция была вызвана, что запрос был выполнен. Это и называется мокинг. А просто заглушка это стаб. Ее смысл не в том чтобы не тащить код, а в том чтобы изолировать побочные эффекты и добиться детерминированности. К последнему, например, относятся таймеры и рандомные числа. Если все это используется внутри программы, то вы не сможете просто так ее протестировать.

Подводя итог, мокают для того чтобы проверить сам мок, например вы хотите убедиться что запрос действительно делался (как в примере документации jest). В остальных случаях у вас стаб (даже если либа называет его моком). Стаб используется для того чтобы тестировать свой код, а стаб нужен только для изоляции побочного эффекта.

Ни первое ни второе напрямую с видом тестирования не связано. Моки и стабы могут применяться практически на любом уровне автоматизированного тестирования.

Темы для самостоятельного изучения:

Побочные эффекты
Детерминированность
Чистые функции
https://martinfowler.com/articles/mocksArentStubs.html

Выяснилось, что удобного места со списком заданий нет, кроме ответа от Максим Зайцев
Так же выяснилось, что созданием ТЗ и последующим разбором в данный момент никто не занимается кроме меня, поэтому добавляю ответ от себя.

Здесь есть задания и разбор. Будет пополняться.

Задание 1 (уже разобрано)
Задание 2 (будет разобрано в конце мая)

p.s. ссылки ведут на github, поэтому я надеюсь у модераторов не будет претензий.

На примере использования токенов.

Авторизация:
1. Отправляем пару логин/пароль, в случае успеха получаем в ответе токен и данные пользователя.
2. Пишем данные пользователя в состояние главного компонента, из него прокидываем в контекст.
3. Токен пишем в cookie и в заголовки по-умолчанию библиотеки для http запросов.
4. Колбеки авторизации и логаута можно так-же прокинуть в форму логина и кнопку логаута через контекст.

Инициализация приложения:
1. Проверяем cookie на наличие токена.
2. Если он есть запрашиваем пользователя и пишем в главный компонент.
3. Пишем токен в заголовки по-умолчанию библиотеки для http запросов.

Логаут:
1. Удаляем токен из cookie и заголовков по-умолчанию библиотеки для http запросов.
2. Удаляем данные пользователя из состояния главного компонента.
3. Делаем редирект с защищенной страницы.