Development

Представим, что план вашего спринта - реализовать 2 экрана, и вы с этим справились раньше, чем наступил конец спринта (для некоторых команд, наверное, звучит как анекдот). В этом случае у вас появляется выбор, что делать оставшееся время спринта: - Do More. В нашем случае, начать делать 3й экран - Do Extra. Делать что-то, не связанное на прямую с бизнесовыми задачами - Do Nothing. Грубо говоря, отдыхать По заверению автора статьи, большинство опытных программистов выбирает Do Extra. Do extra - это делать что-то, что не является обычными рабочими задачами, но где-то рядом с ними. Например, найти новую библиотеку валидации, которая упростит разработку дальнейших экранов. Или написать бота для slack. Это задачи, которые могут быть полезны, но их нельзя просто втащить как часть обычной работы. Эти задачи важны для нас стратегически, даже если они зайдут в тупик (например, нет фреймворка валидации, удовлетворяющего наши нужды) При этом к extra есть несколько требований: - Плохо специально уменьшать обьем обычных задач в пользу extra - Extra должно быть связано с текущими задачами.

Доступна бета новой документации по реакт - Все новые материалы для обучения используют хуки - Интерактивные примеры - Илюстрации и диаграммы, показывающие как работает реакт

Статья про написание авто-тестов с использованием базы данных на C#. Автор отлично разбирается в автоматизации тестирования и понимает, зачем нужно писать авто-тесты и какими они должны быть. Это, в частности, видно по следующему выражению. So, we are going to ignore anyone who says, “A test should only have one assertion” and replace it with, “A test should have as many assertions as needed to prove a fact”. Каким-то образом в индустрии тезис "1 тест - 1 факт" превратился в "1 тест - 1 асерт". Последнее правило одновременно очень простое, популярное и неверное. В статье разбираются проблемы написания авто-тестов с использованием БД. Если мокать БД, то тесты будут давать недостаточно уверенности в работе программы. Если заводить БД на каждый тест - то это будет медленно и может привести к ложно-положительным срабатываниям. Например, если в БД всего 1 запись, то мы не узнаем что наш код плохо работает когда записей много. Поэтому автор предлагает использовать 1 инстанс БД для всех тестов, но при этом гарантировать изоляцию тестов с помощью самих тестов. Если вам интересны авто-тесты или вы хотите писать тесты с использованием БД - рекомендую данную статью к прочтению

Статья про полиморфизм без классов и без ООП. Что нам дает полиморфизм? Он позволяет расширять поведение, не меняя сам алгоритм. Грубо говоря, если у вас есть алгоритм, который вызывает метод класса и вам хочется добавить кейс, когда этот метод отрабатывает по-другому - вам поможет полиморфизм. Вы можете добавить новый класс, наследующийся от базового, который реализует метод так, как вам нужно. При этом вы не меняете код, который вызывает метод. Это и есть пример легкого расширения поведения приложения через полиморфизм. Это очень упрощенное описание. Не бейте за ошибки. Также полиморфизм можно реализовать через мульти-методы. В этом случае мы используем диспетчеризацию. Т.е. если в варианте с ООП наш алгоритм вызывал метод инстанса какого-то класса, то теперь наш алгоритм должен мочь уметь находить функцию для вызова на основе пришедшего аргумента. Грубая и наивная реализация такого полиморфизма: ``` const map = { left: someFunction, right: someFunction } const fn (direction) = { map[direction]() } ``` В статье приводятся более сложные примеры с несколькими параметрами и логикой на основе параметров. Также указываются примеры фреймворков для полиморфизма через мульти-методы для разных языков.

Microsoft выпустила веб версию vscode. Терминала, что естественно, нет. Но можно открыть свой проект в браузере и редактировать его в веб-редакторе.

Состояние приложения можно разделить на два типа: состояние, нужное для реакта и остальное. Для первого типа состояний нам нужно использовать useState. Эти состояния используются в JSX и в зависимостях у useEffect. Все остальные состояния можно не заворачивать в useState и использовать что-то другое (например useRef). Это позволяет избежать лишних ререндеров.

Статья о BASIC - подходе к написанию автотестов. BASIC: - black-box - не тестируем имплементацию - annotative - декларативное описание тестов - single-door - проверяем ровно 1 факт - independent - тесты должны быть независимыми - copy only what’s necessary - все что нужно для понимания теста должно быть в тесте В статье разбирается практический пример, как применяя BASIC, можно сделать из плохого теста - хороший. Не смотря на то, что концепция BASIC очень хороша - она структурирует лишь часть хороших паттернов авто-тестирования. И, мне кажется, BASIC придуман больше как маркетинговый инструмент консультанта, который его придумал. Сами принципы хороши и всегда полезно прочесть о них еще раз.

Вышел Eleventy 1.0 Beta Eleventy - генератор статических сайтов на JavaScript.

Статья от Эрика Элиота про вред и невозможность дедлайнов в разработке ПО. Коротко: - Разработчики плохо оценивают сроки потому что в разработке много неопредеделенности, скоупы задач разрастаются, shit happens - Во всех вариантах, когда вы обещаете определенную поставку к определенному сроку - вы лжете самому себе и заказчику. Вам придется либо двигать сроки, либо скоуп поставки. Вместо того, чтобы гнаться за дедлайнами, Эрик предлагает: - Периодически проводить демо сделанного функционала - Научится хорошо декомпозировать задачи и контролировать скоуп задач -

Перевод статьи про ускорение раскрашивания пар скобок в vscode. В vscode есть популярное расширение - Bracket Pair Colorize, суть которого - раскрасить парные скобки в коде в один цвет. Это позволяет быстрее понимать, какая скобка к какому скоупу относится. Но т.к. API для расширений имеет свои ограничения, расширение не может быстро раскрасить скобки в больших файлах. Для примера используется один из исходников тайпскрипта на 42 тысячи строк. Команда VSCode решила ускорить расширение. Сама статья немножко кликбейт, потому что команда vscode ускорила работу расширения применив недоступный для разработчиков расширения способ - нативное встраивание в vscode. Начиная с vscode 1.60.0 парное раскрашивание скобок будет доступно в vscode нативно и работать очень быстро. Кроме того в статье рассказывается про подводные камни алгоритма для решения задачи. Если вам интересно применение алгоритмов в реальности - стоит прочитать.

Очень хорошая статья от Джейка Арчибальда про то, как и зачем появился CORS, как он работает и как с этим жить. Статья хороша тем, что последовательно подходит к описанию работы CORS и будет полезно как тем, кто вообще не знает о том, что такое CORS, так и тем, кто его уже не раз настраивал. Тажке в статье описаны интересные особенности и хаки браузеров. Рекомендую к прочтению всем интересующимся CORS.

Jest - test-runnter, который сейчас является по-факту выбором по-умолчанию для новых проектов. Но jest можно улучшить многими внешними тулами, которые разрабатывает сообщество. На этот раз сообщество выпустило расширение для expect'ов в jest. Библиотека расширяет стандартные проверки в expect'ах, дополняя их различными проверками для разных типов данных

Вышел Eslint 8.0.0 - теперь при применении исправлений с помощью --fix можно передать дополнительный флаг для удаления неиспользуемых eslint-disable - дропнута поддержка 11, 13, 15 ноды - обновлен внутренний парсер AST - убраны разные deprecated API для разработчиков - правила, которые предоставляю fix или suggest теперь обязаны иметь в описании полей правила fixable и hasSuggestions соответственно

Вышел Parcel 2. В релизе много улучшений перформанса а также, наконец-то, система плагинов. Zero configuration tool теперь не такой уж zero configuration

Хороший курс про вьезжание в автоматизацию тестирование через webdriver IO и Javascript для QA

Перевод статьи How to Make Reliable Probabilistic Forecasts Without Sizing Your Stories Into Even Pieces Сони Сидеровой. Если коротко: - Декомпозировать истории на равные части в ущерб поставляемой ценности для клиента - плохо - Даже если все задачи одного размера, то разброс по времени их выполнения может быть огромный. Размер задачи - важный, но лишь один из критериев, влияющихх на T2M. Например, большую часть времени могут сьедать блокировки и ожадиня. - Прогнозируемость возможна в условиях стабильности рабочего процесса. Поэтому следует сфокусироваться на стабильности работы, а не на размере элементов

Использование Any в typescript считается анти-паттерном. Наверное, вы встречались с этим утвержденеим в докладах и общении на конференциях или даже в своей команде. Люди готовы вложить много усилий в то, чтобы в коде не было ни одного any (есть даже eslint правило, запрещающее any в коде). Однако, нам не следует быть такими категоричными на счет any. Any подходит для случаев когда: - Вы мигрируете код с JS на TS и вы не можете протипизировать все разом - Вы используете библиотеку с плохими тайпингами - Проверки TS требуют от вас лишних телодвижений. Например, вы написали код и уверены что он работает, вы покрыли его тестами. Но TS выводит ошибки в типах. В некоторых случаях угодить TS - сложно. В таком контексте применения any - обосновано. - Вы дейсвтительно ожидаете any. Контексты для использования any - единичны. Поэтому в tsconfig следует включить опцию noImplicitAny, чтобы все any были явными.

Небольшая статья про бест-практисы использования Context в React.

Soundcloud одними из первых начали использовать паттерн Backed-For-Frontend (с 2013го года). Сейчас они начинают серию статей про развитие своей архитектуры с короткой заметки про Backend-For-Frontend в soundcloud. В статье описывается, что в паттерне BFF the good, the bad and the ugly.

Маленькая заметка в блоге Фаулера о стратегии бранчевания Ship Show Ask С одной стороны, Continioues Integration зарекомендовал себя как best practice и мы должны стремиться к тому, чтобы лить изменения сразу в mainline. С другой стороны, Code Review очень популярно, а инструменты для его проведения могут похвастаться очень крутыми фичами. Стратегия Ship, Show, Ask заключается в том, чтобы взять лучшее из обоих миров. Автор кода должен определить тип его изменений. Первый тип изменений - Ship. Это когда автоор кода просто комитит изменения в mainline. Это отлично подходит для: - Все сделано как обычно - Пофикшен мелкий баг - Обновлена документация - Код был улучшен на основе предыдущего фидбека Второй тип изменений - Show. В этом случае автор изменений делает отдельную ветку, отдает ее на Code Review, но вливает в mainline сразу. Это отлично подходит для: - Хочется получить фидбек по улучшению кода - Хочется показать новый паттерн или подход - Показать изменения после рефакторинга - Интересный баг, который был пофиксен Последний тип изхменений - Ask. В этом случае автор заводит отдельную ветку и начинает процесс блокирующего Code Review т.к. ему нужен фидбек коллег. Это подходит для: - А эти изменения вообще сработают? - Был использован новый подход. Нужно его обсудить. - Мне нужна помощь, чтобы сделать лучше - Вот что я сделал за сегодня, завтра я это волью Правила этого подхода: - Апрувы не обязательны для вливания Pull Request - Автор кода сам вливает свой Pull Request. Мы доверяем коллегам в выборе типа изменений и решении о вливании кода. - Нужно использовать практики CI/CD - Долгоживущие ветки - неприемлемы

Есть достаточно известный гайдлайн по оформлению коммитов - conventional commits. Но также есть менее известный гайдлайн по оформлению комментариев на Code Review - conventional comments. Комментарии на Code Review могут быть поняты неправильно или не поняты совсем. Это увеличивает время проведения Code Review, иногда создает конфликты. Conventional Comments решают эти проблемы, добавляя к комментариям ярлыки и атрибуты. Например, не "Почему такое название", а "suggestion(non-blocking): давай переименуем в someName". Примеры комментария в conventional comments: --- **suggestion (test,if-minor)**: It looks like we're missing some unit test coverage that the cat disappears completely. --- **suggestion**: Let's avoid using this specific function… If we reference much of a function marked “Deprecated”, it is almost certain to disagree with us, sooner or later. --- Выглядит как хорошее дополнение к гайдлайнам по проведению Code Review.

Тред в твиттере, где автор описывает свой фреймворк обучения новому. Если коротко: - Выпиши все, что знаешь о проблеме. Таким образом ты найдешь то, чего ты не знаешь. - Исследуй. Исследование делится на 2 типа: горизонтальное (информация о проблеме в целом) и вертикальное (углубленное изучение частей проблемы) - Поставь что-нибудь на кон. Это может быть публичное обещание разобраться в обьекте изучения. Или какое-либо материальное вложение. - Вовлеки комьюнити. Расскажи друзьям о том что изучаешь, пообщайся с экспертами в вопросе. - Учи других. Обучение других - один из самых эффективных способов понять вопрос самому. - Порефлексируй об итогам обучения.

Тред в твиттере о том, что медленные тесты в CI пайплайне обязательно приведут к падению прода. Если коротко: - тесты проходят медленно - фидбек-луп на изменения долгий - разработчики начинают группировать больше изменений вместе - Больший размер изменений - хуже ревью, выше шанс что что-то не так

В статье описывается концепция Task-Force Driven Development. Это когда мы под каждую задачу собираем отдельную маленькую команду. Что-то похожее на feature team. Статья говорит о том что это повышает: - шаринг знаний - шаринг компетенций - нет работы ради работы - делаются только важные для бизнеса задачи Но никаких аргументов, что это действительно так работает - нет. В целом интересное чтиво на подумать, но я не уверен насколько это действительно работает

Вышел SWR 1.0 - hook для реакта для запроса данных. С релизом 1.0 много сделано для перформанса (уменьшен вес библиотеки) и все покрыто тестами. Если вы искали как дергать API из компонентов - можно посмотреть на SWR

Лучшие практики (Best Practices) повсюду. Это и хорошо и плохо одновременно. Хорошо тем, что лучшие практики, как правило, говорят как делать хорошо и нам не нужно тратить много мысле-топлива на решение о том, как что-то делать. С другой стороны, лучшие практики плохи тем, что они выглядят серебрянными пулями, но они ими не являются. При этом в разных контекстах лучшие практики могут быть совершенно противоположными. Лучшие практики хороши, пока не хватает экспертизы самому принять решение о лучшем решении. Но когда экспертиза уже набрана, следует рассматривать лучшие практики как то, от чего стоит оттакливаться, а не к чему стоит стремится. Сам термин "Лучшая практика" звучит слишком претенциозно. Лучше его не использовать, а все лучшие практики воспринимать не как лучшие, а как "рекомендованные в определенных контекстах".

Статья про генерацию форм из JSON-схемы на React с использованием паттерна Visitor

Пример генерации кода на TS с помощью ts compiler API. В статье обсуждается, когда нужна генерация кода и как ее реализовать с помощью compiler API. В данном случае, ради примера взята задача по генерации клиента к SOAP сервису с рантайм проверками типов. Статей по генерации кода не так много и они в основном про babel. Потому что babel: - популярнее - имеет документацию по работе с AST чуть по лучше - и, судя по количеству undefined, которое надо прокидывать в методы ts compiler api, имеет более удобные методы Тем не менее, со статьей полезно ознакомится, если вы хотите перестать страдать, описывая бойлерплейтовый код, и хотите начать жить, отдав бездушную работу по написанию кода кодогенераторам.

Статья в блоге Мартина Фаулера про Gateway Pattern. Gateway инкапсулирует в себе знание об общении с внешним сервисом. Это гарантирует, что нюансы внешнего сервиса не растекутся по всей кодовой базе, а изменения в API внешнего сервиса можно обрабатывать только в Gateway. Кроме этого, Gateway полезен для мока в тестах.

Любой код можно протестировать. Вопрос только в усилиях, которые необходимо затратить на тестирование кода. Как улучшить тестируемость системы? Н простых шагов: - Определить анти-паттерны, которые мешают тестировать код - Осознать, что тестирумость приложения важна, в том числе разработчикам - Осознать, что если автотесты пишут тестировщики и они подключаются после разработки - вносить изменения будет сложно - Проводить ретроспективы - почему что-то было сложно протестировать и как это исправить, а что было легко протестировать и как это закрепить - Думать о тестировании на шаге проектирования системы. Обсуждать архитектуру решения вместе с тестировщиком.