https://t.me/xavescor_code/30
Учись работать в команде - не трать время на фигнюПредположим что вы установили какие-то правила по написанию кода. К примеру, у нас в команде мы решили что использовать React.useCallback - не очень хорошая идея и мы написали ему замену. Но есть проблема: как донести идею до команды и контролировать её соблюдение? Потому что у людей есть проблема: они забывают. А тратить время на code review каждый раз, чтобы проверять использует ли человек что-то не то - очень сильно напрягает.
Решение простое: ESLint. Если вы установили какое-то правило - оно должно покрываться линтером. Правило сверху, к примеру, можно покрыть кодом, который изображён на скриншотах выше.
Из этого я пришёл к следующему правилу в отношеньках: если вы сумели согласиться на какую-либо практику, то она ОБЯЗАНА покрываться линтером. Да, есть мелкие исключения, но они мелкие. Остальные правила должны быть в линте.
Из этого следует второе правило: при ревью не принимаются притензии по кодстайлу, используемым апишкам и т.п. Потому что если это плохо, то подобный код должен запрещаться линтером.
Уважайте время коллег: как при написании кода, так и при ревью. Потому что неформализованные правила - это самое большое зло, которое ведёт к конфликтам.
Полезные ссылки:
https://eslint.org/docs/latest/rules/no-restricted-syntax - запрет написания плохого кода
https://eslint.org/docs/latest/rules/no-restricted-imports - запрет импортов
https://astexplorer.net - посмотреть в какой ast превращается ваш код для правил выше