SS
Логорифм же:)
вы приняты
Size: a a a
2021 March 02
Y
А тесты это в данной модели нужное свойство чтобы катить в прод в слепую с уверенностью что тоглы не сломали ничего
O
Эмпирически, разработчики не трогают код который не нужно делать в рамках задач
Так это же никак не зависит от ревью, нет? Ну всмысле странно трогать код, которые _не нужно_ трогать, чтобы выполнить задачу. Или это какая-то ситуация "спонтанного рефакторинга"?:)
Y
Ну и в таком коде будет очень много копипасты и мертвого кода
Y
Так это же никак не зависит от ревью, нет? Ну всмысле странно трогать код, которые _не нужно_ трогать, чтобы выполнить задачу. Или это какая-то ситуация "спонтанного рефакторинга"?:)
Если ты смотришь на код и он говно иди в нем сложно разобраться - переписываешь. Интерфейсы все есть, с тебя имплементация. Ну и тесты тоже есть
O
Ну и в таком коде будет очень много копипасты и мертвого кода
Те, кто придут такой продукт потом разгребать, попросят массажистку, личный боинг и обязательно тщательно спроектируют архитектуру отдельного котла в аду авторам оригинального решения:)
T
Оставлю тут, если что:
https://free-for.dev/
https://free-for.dev/
Y
Те, кто придут такой продукт потом разгребать, попросят массажистку, личный боинг и обязательно тщательно спроектируют архитектуру отдельного котла в аду авторам оригинального решения:)
Точно такие же речи идут в сторону адептов скалы или cqrs
O
Если ты смотришь на код и он говно иди в нем сложно разобраться - переписываешь. Интерфейсы все есть, с тебя имплементация. Ну и тесты тоже есть
Мне кажется в таком подходе можно очень быстро дойти до итерации "мы постоянно все переписываем, а это очень медленно", то есть даже в среднесрочной перспективе этот подход проигрывает?
Y
Мне кажется в таком подходе можно очень быстро дойти до итерации "мы постоянно все переписываем, а это очень медленно", то есть даже в среднесрочной перспективе этот подход проигрывает?
Мы сегодня собирали процесс который позволяет быстро херачить код с приемлемым качеством и несколькими релизами в день в прод.
O
Было бы еще любопытно получить реальный пример подобного подхода и во что это вылилось.
O
А, ну подождем годик-два, потом попросим у тебя отчета и опекс)
O
с учетом сгоревших программистов в том числе
Y
А, ну подождем годик-два, потом попросим у тебя отчета и опекс)
Так много кто так работает, и без код ревью. Я по сути описал самый обычный тбд, только его реализацию, а не теорию с сайта
O
Так много кто так работает, и без код ревью. Я по сути описал самый обычный тбд, только его реализацию, а не теорию с сайта
Расшифруй про тбд плз. У меня не складывается применение известных значений этой абривиатуры к ситуации
Y
Транк бейзд девелопмент
O
а, и правда, это тоже так сокращается)
O
Хм. Но при этом TBD же не исключает код ревью как таковое? Там скорее упор на то, что ревью должно проводится on-fly и идти с высшем приоритетом. А лучше вообще "пишите код вместе, вот вам и ревью".
SS
Хм. Но при этом TBD же не исключает код ревью как таковое? Там скорее упор на то, что ревью должно проводится on-fly и идти с высшем приоритетом. А лучше вообще "пишите код вместе, вот вам и ревью".
+
O
То, что git flow подталкивает к тому, чтобы пилить бранч дофига времени, а потом придти с MR на 1000+ files changed - это есть такое и в принципе есть некоторые способы решения подобных проблем (начиная с административных, заканчивая полным форком и миграцией на этот форк со временем). С другой стороны, само появление подобных необходимостей говорит о том, что или стадия для ревью не подходящая (бутстрап идет, допустим, когда не до ревью, код пишут полтора землекопа и они то как раз его друг у друга миллион разу уже посмотрели, считай TBD), или в консерватории реально что-то не так и опять же флоу тут ни при чем, надо разбираться с первопричиной.