V
бывает несколько разарботчиков работают над задачей в одной ветке — например бэк и фронт
О, монорепа. Почему кстати не используете субрепозитории? Неудобно? Или две отдельных: project, project-ui
Size: a a a
2020 November 15
M
О, монорепа. Почему кстати не используете субрепозитории? Неудобно? Или две отдельных: project, project-ui
да, монорепа
DM
BTW, работал и в бОльших командах и с репозиториями возрастом под десяток лет (и да, монорепа). Вот тогда приходит понимание, зачем какие-то соглашения вообще нужны. Про плоскую историю и сквоши своей работы, например.
M
и из четырех языков (Go python typescript scala)
M
О, монорепа. Почему кстати не используете субрепозитории? Неудобно? Или две отдельных: project, project-ui
неудобно, куча разных сервисов — бывает версия апи в разных ветках различается итд
M
BTW, работал и в бОльших командах и с репозиториями возрастом под десяток лет (и да, монорепа). Вот тогда приходит понимание, зачем какие-то соглашения вообще нужны. Про плоскую историю и сквоши своей работы, например.
ну у нас тесты просто на все методы обязательны. Код без тестов не будет принят на ревью в принципе
V
ну у нас тесты просто на все методы обязательны. Код без тестов не будет принят на ревью в принципе
А есть ли это благо? Порождает небось кучу тривиальных тестов качеством не выше чем код, что в случае со стажерами пользы принесет немного. Добавляют иллюзию что 100% покрытие и всё хорошо
DM
А речи про 100% покрытие и не было (если по строчкам/бранчам считать). Написано про покрытие всех методов.
DM
Очевидно, ревьюверы и качество тестов смотрят, в не только кода. Напоминаю: тесты — это тоже код
M
А есть ли это благо? Порождает небось кучу тривиальных тестов качеством не выше чем код, что в случае со стажерами пользы принесет немного. Добавляют иллюзию что 100% покрытие и всё хорошо
ну не на вообще все-все, но бизнес-логика и публичные методы должны быть протестированы
DM
А вообще смешно, что стандартные воркфлоу индустрии, де факто стандарты приходится расписывать и ещё обосновывать (у кого-то ещё сомнения есть).
DM
Культ карго главное не устраивать, конечно.
V
А вообще смешно, что стандартные воркфлоу индустрии, де факто стандарты приходится расписывать и ещё обосновывать (у кого-то ещё сомнения есть).
Ну это из разряда "хорошо быть умным и богатым(это бестпрактис!!), плохо бедным и глупым(депрекейтед)". Далеко не во всех конторах зрелые процессы разработки, тестирования и автоматизации и т.д. :/
DM
Если процессы не менять, они и не изменятся (невероятно, правда?!)
M
Ну это из разряда "хорошо быть умным и богатым(это бестпрактис!!), плохо бедным и глупым(депрекейтед)". Далеко не во всех конторах зрелые процессы разработки, тестирования и автоматизации и т.д. :/
бывает нужно работтать с тем что есть а не с тем как в идеале должно быть, причины могут быть совершенно разные
V
Если процессы не менять, они и не изменятся (невероятно, правда?!)
Так не всегда есть такая возможность, очевидно
DM
Что мешает хотя бы договориться о git branching model? Фиг с ними с тестами и кодревью (фиг — потому что допускаю, что кто-то работает на потогонке, где на это просто времени не выделяют).
V
Что мешает хотя бы договориться о git branching model? Фиг с ними с тестами и кодревью (фиг — потому что допускаю, что кто-то работает на потогонке, где на это просто времени не выделяют).
Я у себя договорился. Я скорее за тестирование плачусь :)
M
Что мешает хотя бы договориться о git branching model? Фиг с ними с тестами и кодревью (фиг — потому что допускаю, что кто-то работает на потогонке, где на это просто времени не выделяют).
код ревью и написание задач самое сложное в моей работе ( Проще код писать. Бывает за день 10 строчек напишешь
M
Слава Б-гу что у нас СТО понимающий да и для продукта в целом важно качество тк потери округления даже одной сотой копейки могут вырасти в милионные убытки.