Дайджест за день 15 - 21 августа

Astro 1.0 | Astro
Состоялся релиз Astro 1.0! Astro - это веб-фреймворк, который ставит перформанс в приоритет. Центральная концепция - Island Архитектура. Фреймворк разбивает UI на изолированные компоненты, которые грузятся независимо друг от друга. Также фреймворк стремится отсылать 0 JS в браузер, загружая его только по необходимости.

Patterns.dev - Modern Web App Design Patterns
Сайт-учебник про паттерны для веб-приложений. Паттерны очень хорошо описаны и визуализированы. Сам сайт не очень большой, но там есть ссылка на основной труд - книгу про паттерны проектирования веб-приложений на 435!!! страниц.

Code Golfing Tips & Tricks: How to Minify your JavaScript Code - getButterfly
Достаточно большой читшит разных трюков для написания программ, где размер кода критично важен. Например, это разные челленджи вида "напиши свой твиттер\игру\блог и умести его в 3кб кода". По сути, весь читшит - это инструкция как самому стать минификатором кода. Некоторые хаки очень даже элегантны, если можно применить к ним такое слово.

Type Annotations in JavaScript
На обсуждение TC39 представлен пропозал про добавление аннотаций типов в JS. Данный пропозал предлагает добавить в стандарт основные уже существующие способы описывать типы. Цель данного пропозала - не добавить типизацию в JS, а только лишь добавить синтаксис для типов, который браузер будет отбрасывать (воспринимать как комментарии к коду)

——————————————

Если вы хотите помочь каналу - расскажите о нем своим коллегам\друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Big Changes Ahead for Deno

В блоге Deno команда разработки поделилась планами на Deno. И как же два основных направления похожи на то, что предлагает bun - совместимость с nodejs API и самый быстрый рантайм.

Первое направление для работы - совместимость с существующими пакетами в npm. Изначально, команда Deno не ставила себе целью сделать так, что любой npm пакет мог бы работать на Deno. Deno предлагает web-совместимый API, но пакеты, расчитывающие на nodejs api - не работали. Однако запрос от сообщества есть. Все хотят просто поставить пакет из npm и чтобы он просто работал. Deno планирует сделать так, чтобы 90% пакетов npm работали в Deno.

Второе направление для работы - это перформанс. Буквально "Our goal is to make Deno the fastest JavaScript runtime".

Также из интересного еще рассказано про автодокументацию 3rd-party пакетов от Deno. Deno планирует собирать документацию для всех пакетов, публиковать ее и индексировать для создания единого поиска по документации всех пакетов Deno экосистем.

https://deno.com/blog/changes

#development #javanoscript #deno

7.0 design alpha

Скоро выйдет Storybook 7.0 и команда storybook начинает рассказывать про изменения. На этот раз пост посвящён новому дизайну интерфейса storybook.

Обновили layout, встроили основные инструменты в интерфейс storybook (показ сетки, изменение вьюпорта, смена цвета бекграунда).

Кроме изменений интерфейса storybook также теперь поставляет свой интерфейс предсобранным. Раньше, при сборке storybook проекта, кромме историй проекта собирался и сам storybook. Это занимало время (и непонятно зачем так вообще надо было делать). Теперь storybook поставляется предсобранным, что ускоряет старт проекта.

https://storybook.js.org/blog/7-0-design-alpha/

#development #javanoscript #storybook

The False Trade-off between Quality and Speed

Статья про trade-off между качеством и скоростью. Часто так бывает, что команды разработки готовы пожертвовать качеством, для того, чтобы увеличить свою скорость разработки. Это может исходить как от стейкхолдеров, так и от самой комманды разработки.

В статье дается также определение высоко-качественного ПО:
- Делает то, что должно делать
- Безопасное
- Поддерживаемое
- Делает то, что нужно пользователю

Проблема в том, что размен качество на скорость создает негативную обратную связь. Снижаем качество = снижается скорость, нам это не нравится, мы еще раз снижаем качество. В статье говориться, что trade-off качество-скорость - ложный. Его не существует. Мы не должны никогда резать качество в угоду скорости.

Если мы хотим разрабатывать быстро, то надо разрабатывать качественно

Что же предлагается делать?

- Строить культуру ответственности команды разрабокти за качество производимого
- Подерживать высокие стандарты качества
- Встраивать качество в процессы и оценку

Немного своих мыслей: хороший вопрос, который остался без ответа "что такое качество?" (ну точнее в статье ответ есть, но он очень абстрактный). Нужно ли нам всегда делать безупречное ПО? Действительно ли нужны безупречные интерфейсы? Действительно ли в каждой фиче следует следить за поддерживаемостью решения?

Для меня очевидно, что нет. ИМХМО, разные контексты требуют разного отношения. Степень "безупречности" будет отличаться для маркетингового лендинга и формы оплаты. Для лендинга, который будет жить всего неделю - не иметь автотестов, архитектуры, какие-то огрехи в UI и UX - это норма. Это то качество, которое нам требуется. Но для формы оплаты так не подойдёт - там цена бага большая, как и цена плохого дизайна системы.

https://maruz.medium.com/the-false-trade-off-between-quality-and-speed-7f0f9e93fdd

#managment #quality

Popular Node.js patterns and tools to re-consider | Practica.js

Статья от автора книг "JavaScript testing best practices" and "Node.js best practices". Он рассматривает популярные в node.js мире паттерны и инструменты и оценивает их с точки зрения, насколько это актуально сейчас и какие есть альтернативы.

Короткий список:
- Dotenv для загрузки конфига из .env файла = Предлагается использовать convict
- Жирный сервис, вызываемый из контроллера = Предлагается декомпозировать, создавая use-case
- Закинуть все в DI (например в Nest.js) = Предлагается закидывать только то, что нужно конфигурировать
- Passport.js = Слишком жирное решение, вместо комбайна следует использовать точечные библиотеки
- Supertest для тестов api = http-библиотека + assert'ы от фреймворка тестирования
- Декораторы fastify для функций (не для обработчкиов реквеста или веб-утилит) = корректная декомпозиция
- Логирование из catch = Дополнение контекста ошибки в catch, но единое логирование в глобальном обработчике
- Использование morgan = Используйте удобный вам логгер, напишите руками небольшую мидлварку
- Условия на NODE_ENV = следует избегать

Я очень сильно утрировал. Какие-то пункты очень странные. Я, например, не знал, что кто-то использует API fastify, потому что лень самим декоратор написать над функцией. Но во многих пунктах полезно прочесть не конкретную рекомендацию (они как раз неинтересны), а то, почему текущий паттерн - может быть плох, и на каких принципах следует основывать выбор паттерна или инструмента

https://practica.dev/blog/popular-nodejs-pattern-and-tools-to-reconsider/

#development #javanoscript #nodejs

Дайджест за 30 августа - 2 сентября

Big Changes Ahead for Deno
В блоге Deno команда разработки поделилась планами на Deno. И как же два основных направления похожи на то, что предлагает bun - совместимость с nodejs API и самый быстрый рантайм.

Storybook - 7.0 design alpha
Скоро выйдет Storybook 7.0 и команда storybook начинает рассказывать про изменения. На этот раз пост посвящён новому дизайну интерфейса storybook.

The False Trade-off between Quality and Speed
Статья про trade-off между качеством и скоростью. Часто так бывает, что команды разработки готовы пожертвовать качеством, для того, чтобы увеличить свою скорость разработки. В статье говориться, что trade-off качество-скорость - ложный. Его не существует. Мы не должны никогда резать качество в угоду скорости.

Popular Node.js patterns and tools to re-consider | Practica.js
Статья от автора книг "JavaScript testing best practices" and "Node.js best practices". Он рассматривает популярные в node.js мире паттерны и инструменты и оценивает их с точки зрения, насколько это актуально сейчас и какие есть альтернативы.

——————————————

Если вы хотите помочь каналу - расскажите о нем своим коллегам\друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

A first look at Bun: is it really 3x faster than Node.js and Deno?

Еще одно сравнение перформанса bun, deno и nodejs. В этот раз сравнение идет на основе дашборда проекта Mitosis. Там есть какая-то бизнес-логика и это боле мене похоже на реальное приложение.

Сравнивалась скорость SSR рендера этого приложения для этих рантаймов. Напомню, что bun на своей страничке обещает что он в 3 раза быстрее чем deno и node.js. В этом замере это не подтвердилось, но цифры все равно получились впечатляющие. Bun оказался в 2 раза быстрее node.js и на 10% быстрее deno.

https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x-faster-than-nodejs-and-deno-45od

#development #javanoscript #bun

Installing and running Node.js bin noscripts

Новый туториал от Dr. Axel Rauschmayer, в этот раз про то, как работают запускаемые файлы (bin) в npm пакетах. Очень подробно рассказано, как же так выходит, что вы пишете npx somepackage, а npm запускает что-то конкретное.

Рекомендую к прочтению. Там и про то, как регистрировать bin файлы в пакете, и куда они устанавливаются и как этим управлять, и как проверять пакеты через npm link (и альтернативы линковке) и про кэши. В общем, ИМХО, очень полезная статья для любого фронтенд-разработчика.

https://2ality.com/2022/08/installing-nodejs-bin-noscripts.html

#link #development #javanoscript #nodejs #bin

ReacType

ReacType - инструмент для прототипирования интерфейсов, который позволяет делать и редактировать интерфейсы для React в визуальном редакторе. То есть можно накидывать интерфейсы используя базовые компоненты, размещая их на холсте, но при этом не написав не строчки кода, а затем экспортировать React-код. Либо можно править код прямо на месте, либо загрузить в редактор код и поиграться с интерфейсом. Из интересных фичей - инструмент умеет показывать граф данных, которые используют компоненты (из хуков, пропсов, контекста).

Подход с визуальным программированием отлично ложиться на 2 кейса: обучение и работа с непрограммистами (например, дизайнер, продакт или пользователь продукта могут не словами описывать, что они хотели бы видеть - а могли бы накидать интерфейс).

У меня большие сомнения на счет production использования ReacType, но, как и любой инструмент для визуального программирования, выглядит интересно

https://reactype.io/index.html

#link #development #javanoscript #react

JSON Crack - Crack your data into pieces

JSON Crack - визуализатор JSON'а. Вы загружаете в него JSON, а он отображает его как дерево. Из фичей - есть поиск и экспорт получившегося дерева

https://jsoncrack.com/

#link #development #JSON

Default Exports in JavaScript Modules Are Terrible

Ещё одна статья, в которой рассказывается, почему не стоит использовать export default.

В кратце:
- Автокомплит не подсказывает, что у модуля есть export default, если вы начали делать импорт через { }
- То, что экспортируется через export default может быть импортировано под любым именем. Это создает сразу несколько проблем: возможность криво назвать, то что импортируется; возможность назвать по-разному одну и ту же сущность в разных файлах; возможность неконсистентного именования при импортах из пакетов

Если вам нужен аргумент против использования export default в своих проектах - посмотрите эту статью.

В целом у export default есть боле мене адекватные места для применения. Например, библиотеки. import React from 'react' - это как раз случай, когда export default не делает хуже. Хотя и с именоваными экспортами было бы нормально.

Лично я предпочитаю забанить export default в проектах на уровне линтера. Отсутствие адекватного автокомплита и возможность накосячить с именованием слишком сильно бьют по DX в проекте

https://www.lloydatkinson.net/posts/2022/default-exports-in-javanoscript-modules-are-terrible/

#development #javanoscript #modules

Дайджест за 5 - 9 сентября

A first look at Bun: is it really 3x faster than Node.js and Deno?
Еще одно сравнение перформанса bun, deno и nodejs. В этот раз сравнение идет на основе дашборда проекта Mitosis. Там есть какая-то бизнес-логика и это боле мене похоже на реальное приложение. Bun оказался в 2 раза быстрее node.js и на 10% быстрее deno.

Installing and running Node.js bin noscripts
Новый туториал от Dr. Axel Rauschmayer, в этот раз про то, как работают запускаемые файлы (bin) в npm пакетах. Очень подробно рассказано, как же так выходит, что вы пишете npx somepackage, а npm запускает что-то конкретное. Рекомендую к прочтению всем фронтендерам.

ReacType
ReacType - инструмент для прототипирования интерфейсов, который позволяет делать и редактировать интерфейсы для React в визуальном редакторе.

JSON Crack - Crack your data into pieces
JSON Crack - визуализатор JSON'а. Вы загружаете в него JSON, а он отображает его как дерево. Из фичей - есть поиск и экспорт получившегося дерева

Default Exports in JavaScript Modules Are Terrible
Ещё одна статья, в которой рассказывается, почему не стоит использовать export default. В комментариях к посту разные интересные обсуждения

——————————————

Если вы хотите помочь каналу - расскажите о нем своим коллегам\друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Dependency Injection in JS/TS – Part 1 | The Miners

Очень хорошая статья про Dependency Injection с примерами кода на TS.

Флоу статьи:
- Что такое Dependency Injection
- Проблема с гибко vs удобно использовать. Если делать слишком гибко, то становится неудобно использовать. Это ловушка, в которую попадают все, кто пробует DI. Из-за этой ловушки DI кажется бесполезной игрушкой для чистой архитектуры, а не реальных проектов. Но совместить гибкость и удобство использования можно.
- DI позволяет варировать реализацию функций через внедрение разных зависимостей
- DI позволяет замокировать что-то в разработке, без изменения кода приложения
- DI на классах
- Почему важно правильно определять, что является зависимостью сервиса, а что не является. Если начать все выносить в DI, код станет слишком сложным и неподдерживаемым
- Composition Root - место, где мы инстанцируем все сервисы и их зависимости. Также это называется DI контейнер
- Автоматические DI контейнеры - самописные и из npm
- Проблема циклических зависимостей
- Проектирование сверху вниз с помощью DI

Цитировать статью не буду т.к. там очень много и тяжело это адаптировать для канала. Лучше выделите 20-30 минут своего времени и прочтите статью. Она очень хороша.

https://blog.codeminer42.com/dependency-injection-in-js-ts-part-1/

#development #DI

Rewriting tests from Cypress to Playwright using GPT3 by Gajus Kuizinas

Одна команда решила перевести свои браузерные тесты с Cypress на Playwright. Это монотонная и скучная работа, которую, тем не менее, надо сделать.

Однако, одному разработчику пришла мысль "а что если использовать для этого нейронку?". И оказалось, что это очень хорошая идея.

Он открыл openai playground, где можно поиграться с нейронкой GPT-3 в рамках чата.

Он отправил ей

Example
Input: /* cypress code */
Output: /* playwright code */

Input: /* cypress code №2 */

и нейронка вывела корректный перевод cypress code №2 на playwright.

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

Рекомендую зайти в статью и пролистать её вниз, где есть гифка как GTP3 пишет код в чате.

Мы все ближе подходим к моменту, когда нейронки будут сопровождать нас на постоянной основе. Так недалеко и до киберпанка

https://contra.com/p/PWBcPYZc-rewriting-tests-from-cypress-to-playwright-using-gpt-3

#development #cypress #playwright #refactoring #ai #gpt3

Do we need an office?

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

Работу над задачами можно разделить на 2 режима - "с погружением" и "на поверхности" (deep work и shallow work в оригинале)

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

Во втором режиме задачи не требуют большой когнитивной нагрузки.

Так вот, типичный open space офис, в котором единое пространство для всех, не способствует первому режиму работы. Это подтверждается различными исследованиями. С другой стороны, для эффективной работы нужна коллаборация.

В итоге хорошая организация работы в офисе - это дать возможность для эффективной совместной работы (например, наличие удобных переговорок) и также дать возможность для эффективной работы в режиме фокуса (например, изолированное личное пространство). Это рецепт для достижения идеальной продуктивности работы в офисе. Называется это hub-and-spoke architecture.

Однако, с приходом COVID все мы перешли на удаленку и, казалось бы, проблемы open space офисов должны быть неактуальны. Но, на самом деле, у удалёнки есть схожие проблемы.

Нажать кнопку в Zoom'е так просто, что все начали организовывать созвоны в любое доступное время. Отправить вопрос в чат проще, чем подумать самому. Это все ведет к тому, что удаленка превращается в цифровой open space - здесь нет места концентрации, только беспорядочные коммуникации.

В статье рассказывается, как применить практики hub-and-spoke architecture в удаленной работе.

Утрированный список советов:
- Если у вас есть коллеги и в офисе и на удалёнке, то следует работать так, как будто все сидят на удалёнке
- Используйте разные каналы коммуникации для разных целей
- Организуйте рабочее пространство. В идеале - отдельная комната с дверью
- Организуйте себе возможность сфокусированной работы. Отключив уведомления, мессенджеры, зумы и все такое (автор предлагает запускать помидорку и отключать wifi на время помидорки, звучит неплохо на мой взгляд)
- Используйте правильные инструменты для совместной работы. Возможности IDE, борды в MIRO и тд
- Сделайте канал для неформального общения среди коллег

Рекомендую статью к прочтению

https://zhuk.fi/do-we-need-an-office/

#managment #openSpace #remoteWork

An overview of Node.js: architecture, APIs, event loop, concurrency

Новый пост от Dr. Axel Rauschmayer, теперь про то, как работает Node.js. Рассмотрены следующие моменты:
- Архитектура Node.js (где там Node.js, где v8, а где С++ код)
- Встроенные возможности и глобальные переменные
- Как работает event loop и асинхронное взаимодействие
- Разница между асинхронным и синхронным I/O в рамках libuv
- Возможности для многопоточности в Node.js

Рекомендую, если вы хотите ознакомиться с Node.js или если вы работает на Node.js и вам интересно, как устроена внутренняя асинхронность

https://2ality.com/2022/09/nodejs-overview.html

#link #development #javanoscript #nodejs

Introducing Signals – Preact

Команда preact рассказала про разработанные ими сигналы (signal)

Сигнал - это новый (в preact) способ описания стейта, который очень близок к реактивным атомам.

import { signal, computed } from "@preact/signals";

const count = signal(0);
const double = computed(() = count.value * 2);

function Counter() {
  return (
    button onClick={() = count.value++}
      {count} x 2 = {double}
    /button
  );
}

Сигналы - быстры, удобны и мало весят (1.6КБ).

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

С точки зрения DX, сигналы очень просты - объяви сигнал, используй его в вёрстке и все будет работать из коробки. С точки зрения разработчика сигнал, как абстракция, немногим сложнее обычной переменной

С точки зрения перформанса, команда preact сделала нативную интеграцию virtual dom и сигналов. Это позволяет при обновлении значения сигнала ререндерить только то, что действительно использует значение из сигнала. При этом они пошли еще дальше и могут определять, когда vdom вообще перестраивать не нужно, достаточно сразу поменять DOM-элемент - это кейс, когда мы связываем сигнал и dom-атрибут

Выглядит очень интересно, а также наглядно показывает, почему вообще появляются реактивные инструменты для создания UI

https://preactjs.com/blog/introducing-signals/

#development #javanoscript #preact

Дайджест за 12 - 16 сентября

Dependency Injection in JS/TS – Part 1 | The Miners
Очень хорошая статья про Dependency Injection с примерами кода на TS. Объясняется, что такое DI, как его реализовать разными способами и какие паттерны для DI есть. Рекомендую к прочтению

Rewriting tests from Cypress to Playwright using GPT3 by Gajus Kuizinas
Сногсшибательная история про то, как ребята перевели Cypress тесты на Playwright с помощью чата с GPT3 нейронкой.

Do we need an office?
Статья про то, что open space офисы негативно влияют на качество сложной работы. Даются ссылки на исследования, книжки и рекомендации по организации работы в офисе. А затем это все переводится на реалии удалёнки т.к. удаленка может взять худшее из open space офисов. В статье рассказывается, как применить практики hub-and-spoke architecture в удаленной работе.

An overview of Node.js: architecture, APIs, event loop, concurrency
Новый пост от Dr. Axel Rauschmayer, теперь про то, как работает Node.js. Рекомендую, если вы хотите ознакомиться с Node.js или если вы работает на Node.js и вам интересно, как устроена внутренняя асинхронность

Introducing Signals – Preact
Сигнал - это новый (в preact) способ описания стейта, который очень близок к реактивным атомам и одновременно быстро работает и удобен в плане Developer Expirience

——————————————

Если вы хотите помочь каналу - расскажите о нем своим коллегам\друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

MemLab: An open source framework for finding JavaScript memory leaks

Meta опубликовали свой инструмент для поиска утечек памяти в JS приложениях под названием MemLab в открытый доступ.

Как я понял, MemLab использует puppeteer для навигации по сайту, а затем сравнивает снапшоты памяти для поиска потенциальных кандидатов на утечку. Также MemLab предоставляет удобный интерфейс для анализа "утёкших" объектов.

В статье нет глубоких технических подробностей о работе инструмента, но зато есть кейс самой Мета - они уменьшили количество крашей страниц на Facebook из-за нехватки памяти в 2 раза с помощью MemLab.
Также есть несколько конкретных кейсов: утечка памяти из-за React Fiber реализации и утечка памяти из-за Relay

https://engineering.fb.com/2022/09/12/open-source/memlab/

#development #javanoscript #memoryLeak #performance #memLab

Release v1.0.0 · axios/axios

Вышел 1.0.0 релиз axios'а.

Axios - это, наверное, самая популярная либа для делания сетевых запросов (или, по-крайней мере, была такой). Но при этом axios находился в вечной бете (0.х.х версии). Какое-то время даже был слух, что разработка axios приостановилась.

Однако, 4 октября вышел в свет релиз 1.0.0. Хотя к 7 октября уже вышла 1.1.2 - видимо пришлось залить в короткие сроки много фиксов.

С одной стороны, ничего принципиально нового не случилось. С другой стороны, это знаменательное событие для axios.

https://github.com/axios/axios/releases/tag/v1.0.0

#link #development #javanoscript #axios

Закон Гудхарта: как государственный контроль влияет на эффективность деятельности хозяйствующих субъектов

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

Этот феномен также был описан в книге "Цель" Голдрата.

Но с KPI всё понятно, но как далеко этот опыт можно экстраполировать?

На этот вопрос отвечают закон Гудхарта, "критика" Лукаса и закон Кэмпбелла, волна Де Брюйна.

Давайте вкратце рассмотрим каждый из них

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

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

Закон Гудхарта и "критика" Лукаса рассматривают макро-экономику. Чуть ближе к обычным людям этот же феномен описал Кэмпбелл. Согласно закону Кэмпбелла, введение каких-либо критериев оценки функционирования социальных и бюрократических институтов неизбежно приводит к тому, что искажаются как сами индикаторы оценки, так и процессы, которые эти индикаторы оценивают.

Социальные институты - это уже ближе к повседневной реальности. Однако Де Брюйн адаптировал закон Гудхарта для организаций. Де Брюйн построил параболическую кривую, которая отражает следующую закономерность: чем больше руководство компании стремится оценивать эффективность своих сотрудников по количественным показателям, тем меньшую производительность деятельности и ее эффективность

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

https://4brain.ru/blog/zakon-gudharta-kak-gosudarstvennyj-kontrol-vlijaet-na-effektivnost-dejatelnosti-hozjajstvujuschih-subektov/

#managment #goodhartLaw #KPI