Artem Zakharchenko, автор библиотеки для тестирования MSW с 15К звезд на GitHub, поделился мыслями о Test Driven Development:

TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.

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

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

Я не считаю TDD жизнеспособным подходом в быстро развивающихся системах, таких как веб. Он может иметь гораздо больше смысла при написании систематического программного обеспечения, в котором очень мало что меняется от проекта к проекту. Это полная противоположность тому, что вы пишете в Интернете.

Негативный аспект TDD заключается в том, что я видел, как команды разочаровываются, если им не удается следовать ему. И тогда они отказываются от всей идеи тестирования, поскольку TDD так широко ассоциируется с ним. Вместо того чтобы поощрять людей к тестированию и показывать им, что тестирование программного обеспечения может быть интересным, эта практика запирает их в педантичных ограничениях, которым не может следовать ни один инженер.

Я не придерживаюсь TDD. Это не значит, что я не пишу тесты. Я пишу много тестов. Я занимаюсь разработкой прототипов, итераций и тестов.

Прототип. Я даю своим идеям простор и позволяю им дышать, не слишком заботясь о тестировании на первых порах. Я экспериментирую, меняю вещи, ломаю вещи, ставлю себя на место пользователя и разрабатываю API, поведение и ожидания. Как я уже сказал, это может занять некоторое время.

Итерация. Я трачу это время на то, чтобы убедиться, что моя система имеет смысл и удовлетворяет предъявляемым к ней требованиям (которые сами по себе могут развиваться и менять то, зачем я это делаю).

Тестировать. Наконец, я пишу тесты. Это стало неотъемлемой частью моего рабочего процесса. Я не могу представить себе, что не пишу тесты.

Конечно, бывают исключения. Если я пишу простую функцию ввода-вывода, то не нужно тратить день на то, чтобы понять, что она делает, потому что это все, что она будет делать. Я могу написать для нее несколько модульных тестов с самого начала. Но большинство моих (и, я уверен, ваших тоже) работ - это не простые функции. Это сложная логика, на отладку которой требуется время. Если я буду неукоснительно следовать TDD, я буду тратить время на написание тестов, которые в итоге выброшу. Это бесполезно и не поможет мне обрести уверенность в том, что я создаю.

Не отчаивайтесь. Применяйте те практики, которые работают для вас (даже если это TDD, лишь бы вы не лгали себе!). Главное, что тестирование имеет значение. Оно всегда имело значение. Разработчики тестируют программное обеспечение с 80-х годов, я полагаю. Вы тоже должны! Я сделаю все возможное, чтобы показать вам, что тестирование может быть доступным и увлекательным.

#testing #tdd #article

Свершилось. Вышел VitePress 1.0.0.

VitePress - генератор статических сайтов (SSG), который удобен для создания как технических документаций, так и просто сайтов.

Больше 2 лет он был в статусе release candidate, стабильный, но постоянно добавляющий в себя функционал.

VitePress - один из трех китов империи Эвана, и обязателен к как минимум "попробовать" для любого Vue.js разработчика.

#vitepress #release

Svelte украл у Vue руны

По подозрению Evan You

#svelte #evanyou

Если в DevTools браузера вам нужна только консоль, то плагин vite-plugin-terminal позволяет выводить информацию в терминал (где запущен Vite), таким образом давая больше места странице в браузере. В VS Code его можно "отцепить" в отдельное окно.

#tip

Интересная табличка совместимости современных JavaScript рантаймов с JavaScript (сорри за мой рязанский французский)

https://runtime-compat.unjs.io

#jsre

Case study о вреде Nuxt и ошибках в архитектуре

VueStorefront, предлагавший услуги Frontend-as-a-Service, а именно, фронтенд для онлайн магазинов для подключения к headless e-commerce решениям, так и не смог за 4 года апгрейднуть Nuxt со второй на третью версию и в расстроенных чувствах решил переехать на React и Next.js, попутно сменив название на Alokai

При выборе технологий для магазина Arty-Crafty я долго изучал VueStorefront, но так и не понял, что это за зверь и с чем его едят. Теперь это проблема реактовцев.

#nuxt #ecommerce #vuestorefront

Основные функции фронтенд фреймворков

Фреймворки для веб-разработки - это, по сути, пресобранные библиотеки кода, которые обеспечивают структурированную основу для создания веб-приложений. Они предлагают целый ряд возможностей, таких как:

Компонентная архитектура: Фреймворки часто разбивают пользовательские интерфейсы на многократно используемые компоненты, что способствует модульности и удобству сопровождения.

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

Маршрутизация: Фреймворки обрабатывают логику маршрутизации, обеспечивая отображение правильного контента в зависимости от навигации пользователя в приложении.

Управление состоянием: Сложные приложения иногда требуют управления состоянием различных компонентов. Фреймворки часто предоставляют встроенные или совместимые решения для этого.

Инструменты разработки (devtools): Многие фреймворки предлагают такие инструменты для разработчиков, как отладчики, горячая перезагрузка и профилирование производительности, что повышает удобство разработки.

Эти функции значительно сокращают количество шаблонизированного кода, упрощают процесс разработки и обеспечивают последовательность действий при разработке.

#frontend

В CSS есть правило color-scheme для реализации цветовых тем на сайте. Не очень удобное, по сравнению с использованием для этой цели CSS переменных.

В последнем Хроме появилась экспериментальная функция light-dark, с которой это делать проще. Но, опять же, для серьезных проектов лучше использовать CSS переменные.

:root {
  color-scheme: light dark;
}

.element {
  color: light-dark(black, white);
  background-color: light-dark(white, black);
}

В Firefox она уже была реализована

#css #tip

Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.

(с) Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"

#quote

Автор Volar Johnson Chu собирается покинуть open source. Стресс и слабое финансирование.

Volar (language-tools) один из основных проектов Vue экосистемы с точки зрения Evan You.

Mucho trabajo, poco dinero...

p.s.: кстати, бетта-тестирование volar 2.0 оказывается было, и показало ошибки, которые потом вылезли и после релиза

#volar

Evan You нанял Johnson Chu на full time позицию фьючерсом.

Viva Volar

#volar

Уже писал про esm.sh, который позволяет работать с npm ES модулями в скрипте HTML страницы. Вот его аналог - esm.run

Вот как с помощью него можно легко отрендерить markdown файл безо всяких фреймворков и генераторов:

<!doctype html>
<script type="module">
  import { marked } from 'https://esm.run/marked';

  document.body.innerHTML = marked(
    await fetch('./README.md').then(r => r.text())
  );
</script>

#markdown #lib

Перевел статью Artem Zakharchenko "Темная сторона Open Source"

#opensource #article #habr

Рабочее место на ближайшую неделю.
+17°С, если что.

А вы помните эмблемку Vue 3.0?

#vuejs #logo

Сегодня в 27.03.24 в 4pm CET состоится голосовой чат в Дискорде с командой Vite
Тема - Vite 5.3
Ссылка

#vite #chat

Pinia cheatsheet (Option stores)

#pinia #cheatsheet