Это переводит фокус конфликта (а именно его разработчик ловит, когда втыкается в ограничения) с человека на бездушную машину.
Петя, редиска, докопался до отступов в моём коде!
vs
Линтер опять мозги парит!
Компуктер не обидится, машинное время дёшево и конфликт с машиной решать проще, чем с человеком.
Как и тесты. Пусть самые простые, пусть не все, пусть с игнором неважных ошибок, но если не сделать сразу вообще ничего, то мы попадаем на flakehell с гарантией чуть позже.
Очень помогает сразу думать о том, как мы приложение раскатывать будем. Порой такое наворотишь в альфаверсии, что половину перекопать придётся, чтобы альфу на сервер доставить и как никак поддерживать
Бизнес ценность и миссия сервиса в ридми или ещё где - это конечно важно - но разработке чаще нужно проект пересетапить и чтобы тесты прошли после правки, нежели переосмысливать бизнесовую модель компании. Каждый новый разраб не будет задавать вопросы по развёртыванию, если инструкцию из ридми проверяли хотя бы раз в полгода. Проверить просто - rm -rf app/ && git clone .... А ещё сложность развёртывания является неплохим маркером технического долга и если ресетап раз в полгода вызывает "даа там всё нормально, мне лень сейчас", то есть смысл упрощать.
Для проекта с рускоязычной командой выглядит как трата времени на раннем этапе проекта: добавляем риск двойного испорченного телефона вида "разработчик1 <-> дока <-> разработчик2", пытаясь заранее облегчить онбординг англоязычных коллег (потенциальных) и/или подготовить доку для публикации. Проектов, которые так и не дошли до найма нэтивов в продажи/саппорт или при публикации документации для пользователей не наняли техписа (который один чёрт всё переписал) я знаю намного больше, чем обратных кейсов. А вы?
Если тесты в проекте начинают требовать ресурсов на поддержку и временами хочется написать тесты на тесты - значит тесты нужно отрефачить. Если в тестах появляются универсальные генераторы фикстур - вероятно стоит пересмотреть цели тестирования. Часто дублирование похожего кода в фикстурах/тестах окажется проще поддерживать, чем сложные универсальные генераторы. Ну и конечно, если ваши тесты сильно зависят от окружения запуска и с полпинка не заводятся на машине нового разработчика - так жить нельзя, это нужно менять на корню (:
Не согласен с позицией "вот понадобятся логи при разборке с багом - тогда и добавим". Кмк, для простоты отладки багов намного лучше иметь логи, описывающие шаги работы программы словами, нежели голые
LS-nw API REQUEST ...
LS-nw API RESPONSE 503 ...