Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.

Но после нескольких лет руководства командой фронтенда, десятков ночных дебагов и сотен часов, потраченных на поиск неуловимых багов, я пришёл к неожиданному выводу: качественные юнит-тесты — это не якорь, замедляющий разработку, а реактивный двигатель, ускоряющий её.

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

Когда-то мой чек-лист «готова ли фича» выглядел как молитва джуна: открыть браузер, нажать пару кнопок, убедиться, что в консоли нет красного цвета (желтое — это нормально, да?), и смело делать merge.

В те времена React был еще зеленым, Backbone уходил в архив, а модные парни на конференциях говорили про какое-то тестирование. Я слушал их как индеец — много слов, мало понимания.

Проект жил быстро, но баги плодились еще быстрее. Каждый хот-фикс тянул за собой новый хот-фикс, как матрешка багов. Я начал бояться рефакторинга сильнее, чем дантист боится собственных зубов.

Переломный момент настал ночью перед релизом. Один пропущенный null-чек положил всю систему авторизации. Пока я в 3 утра откатывал релиз, понял: так больше жить нельзя.

Скептики часто говорят:
«Юнит‑тесты? Это же лишняя морока.»
«Код всё равно придётся менять — зачем тестировать то, что всё равно устареет?»
«У нас нет времени на это.»

Я слышал это десятки раз — от новичков, опытных тимлидов и даже CTO. И всё же, спустя годы в разработке, я с уверенностью могу сказать: юнит‑тесты — это не обуза, а инструмент, который экономит время, снижает стресс и делает код надёжнее.

Давайте разберёмся с популярными мифами.

Если вы не читали Часть 1, вы можете исправить сиё недоразумение здесь.

Переиспользование конфигураций

Новая библиотека vue-cli-3 избавила от необходимости поддерживать сложные шаблоны сборки и конфигураций. Вместо этого она позволяет разработчику сосредоточиться на создании своего приложения. Она также имеет малоизвестные функциональные возможности, которые могут значительно повысить вашу эффективность. Если у вас не установлен vue-cli-3, вы можете установить его, выполнив:

установка @ vue/cli

yarn global add @vue/cli
// или же
npm i @vue/cli -g

Одно из незамеченных преимуществ — это удаленные пресеты. Они позволяют вам определять явный набор плагинов и их опций при создании нового проекта на Vue. Вы даже можете явно установить версии этих плагинов для дальнейшего определения функциональности. Если вы использовали vue-cli-3, вы, вероятно, сталкивались с этим при создании нового приложения:

vue-cli-3 create

На днях ковыряясь в множестве файлов redux'a, где по логике файлы вынесены в reducers, actions, константы типов actions. Bсе это оказалось весьма не простая задача держа все эти типы файлов у себя в голове и прослеживать логику. И… эврика, появилась идея упрощения написания redux логики. Возможно создавая свой велосипед, но кто не пытался писать свои велосипеды? Но главное это не написание а поддержка написанного когда. Давайте я вам немного постараюсь показать свое видение моей логики redux'a.

Нововведения в ECMAScript

Здравствуйте читатели Хабр. Предлагаю вашему вниманию интересную штуку которая в скором времени появится уже появилась в стандарте ECMAScript. Она уже доступна почти во всех браузерах и весь функционал тоже. Это нововведение всего лишь сахар-обертка и ее можно решить своими средствами и это я вам тоже покажу. Но этот сахар позволит нам писать кода меньше, ведь мы это так любим. Итак, добавляется базовые функции к массиву, в данном случае их 2, которые позволят нам разворачивать многоуровневые массивы в один или более уровней вложенности. Да да и все это как говориться из коробки

Есть много преимуществ для централизации состояния вашего приложения в Vuex store. Одним из преимуществ является то, что все транзакции записываются. Это позволяет использовать удобные функции, такие как отладка по времени выполнения, где вы можете переключаться между предыдущими состояниями, чтобы отделять задачи выполнения.

В этой статье я покажу, как создать функцию Undo/Redo далее Отката/Возврата с помощью Vuex, которая работает аналогично отладке во время дебага. Эта функция может использоваться в различных сценариях, от сложных форм до игр на основе браузера.

Вы можете проверить готовый код здесь, на Github, и попробовать демо в этом Codepen. Я также создал плагин как модуль NPM под названием vuex-undo-redo, если вы хотите использовать его в проекте.

Как часто вы выполняете одно и то же задание каждый день? Я готов поспорить, что больше, чем вы думаете. Выполнение простых действий, таких как создание свойств, наблюдателей(watchers) или новых методов, выполняется снова и снова при создании приложения.

Эти маленькие вроде бы действия образуют продолжительный отрезок времени. Наша цель — делать как можно больше с как можно меньшим количеством действий.

Когда люди обсуждают изменения в PHP7, самое распространенное что вы слышите — это значительно улучшенный движок, который может похвастаться более быстрой скоростью выполнения и значительно меньшим объемом памяти при сравнении обычных приложений PHP, таких как Drupal, WordPress и MediaWiki.

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