A
Кажется это стоит добавить в список аргументов про "вам точно не нужно N, все работает прекрасно и без него".
N8s
Size: a a a
2021 March 02
O
N8s
Это слишком толстый намек)
A
A
Это слишком толстый намек)
где N>=K
SS
Смотря что вкладывается в понятие «плохой коммит»
ну после которого баг репорт
SS
при этом я не утверждаю, что мы все баги ловим на стадии ревью
Y
при этом я не утверждаю, что мы все баги ловим на стадии ревью
Тогда я не понимаю в чем разница. Там ищете и тут ищете. Обмазываетесь фича тоглами и можете изолировать сайд эффекты. Архитектурно у вас должен быть предусмотрен паттерн стратегия, и по сути у вас с точки зрения багов которые нашли на ревью/тестировании/в проде процесс не меняется вообще никак
SS
Тогда я не понимаю в чем разница. Там ищете и тут ищете. Обмазываетесь фича тоглами и можете изолировать сайд эффекты. Архитектурно у вас должен быть предусмотрен паттерн стратегия, и по сути у вас с точки зрения багов которые нашли на ревью/тестировании/в проде процесс не меняется вообще никак
искать в одном код ревью проще, чем когда у тебя с последнего известного хорошего состояния уже тыща коммитов
Y
Правда то, о чем я говорю сдвигает баланс в сторону скорости разработки, а не качества. Иногда в таком процессе можно прилечь, если это для бизнеса не критично - то по сути мы с вами изобрели реализацию tbd
Y
искать в одном код ревью проще, чем когда у тебя с последнего известного хорошего состояния уже тыща коммитов
Не понимаю о чем речь. Бисект будет работать так же, история коммитлв такая же
SS
так же как? если тебе, допустим, надо 15 минут, чтобы проверить один коммит, сколько времени ты будешь бисектить?
O
Я так понимаю, что Ярослав постулирует то, что количество "плохих" коммитов будет небольшим и более высокие затраты на их исправление будут все равно выгоднее, чем проверка всего кода сразу. Но для меня это все очень уж перекликается с сознательным накоплением тех. долга, более того - даже форсирует само его возникновение.
O
Но я бы тогда предложил и от тестов сразу отказаться. Вот они то точно кучу времени занимают, а разработчики вроде нормальные ребята, ошибаются редко, можно же тесты только на критичную бизнес логику писать...
Y
Я так понимаю, что Ярослав постулирует то, что количество "плохих" коммитов будет небольшим и более высокие затраты на их исправление будут все равно выгоднее, чем проверка всего кода сразу. Но для меня это все очень уж перекликается с сознательным накоплением тех. долга, более того - даже форсирует само его возникновение.
Да, это про копление техдолга в тех местах которые редко затрагиваются
E
Да, + код ревью не только про “словить баг”
O
Да, это про копление техдолга в тех местах которые редко затрагиваются
А каким образом происходит разделение между редко и часто затрагиваемыми местами?
SS
Да, + код ревью не только про “словить баг”
+
Y
так же как? если тебе, допустим, надо 15 минут, чтобы проверить один коммит, сколько времени ты будешь бисектить?
Логорифм же:)
O
Да, + код ревью не только про “словить баг”
Эта аргументация уже приводилась:)
Y
А каким образом происходит разделение между редко и часто затрагиваемыми местами?
Эмпирически, разработчики не трогают код который не нужно делать в рамках задач