VF
Если ревьювер найдет ошибку, то тест кто будет писать?
Size: a a a
2021 May 08
AK
Прочтите вопрос выше. Сколько должно случится фейлов чтобы понять что практика плохо работает? Есть 3 ревьювера, все ревьювят код и даже делают замечания, в конце концов задача попадает в прод и роняет его. Сколько раз надо на это напороться чтобы понять что ревью не помогает?
C
Дизайн - это более высокий уровень. Тесты - может надо дописать, а не просто оставить текущие?
C
Сколько их было бы без ревью?
СА
Машина может пока слишком мало. В основном форматирование отступов и новые строки. У Go неплохой
golint, но он тоже в 80% случаев пишет про неправильное форматирование комментариев при экспортируемых методах и переменных.VF
Тесты входят в дизайн, сначала тесты, потом код, вы оговаривает типичные и граничные случай которые надо протестировать ДО написания кода
VF
Нормальный дизайн без тестов в целом не особо возможен.
AK
Попробуйте
golangci-lint и линтеры к нему. Он даже цикломатическую сложность считать умеет. А вы как с таким подсчетом справитесь?СА
"Рядовой Сидоров, разве вы не видите, что раскалённое олово капает на голову вашему боевому товарищу". Это хороший подход, но на практике очень редко применимый. Намного лучше, когда он формально интегрирован в процесс разработки.
VF
Первые 4 пункта решаются проектированием до написания кода
AD
А если я написал оверинжениринг, а потом кому-то на ревью написал, что тут не хватает фабрики фабрик?
Если люди часто нарушают СОЛИД, то какие причины? Они не понимаю эти принципы? А почему с тестами проблемы? Пробовали TDD? Считаете покрывало?
Повторю свою мысль - если изо дня в день, приходится писать комментарии про Солид, то кодревью работает или нет?
Если люди часто нарушают СОЛИД, то какие причины? Они не понимаю эти принципы? А почему с тестами проблемы? Пробовали TDD? Считаете покрывало?
Повторю свою мысль - если изо дня в день, приходится писать комментарии про Солид, то кодревью работает или нет?
c
Nyet
AK
"Рядовой Сидоров" много говорит о культуре в компании. Я как челвоек в армии служивший, порядки армейские в жизни не притащу в свою команду
VF
Нет доверия, нет самостоятельности. Нет самостоятельности, нет роста. Что данный спор и подтверждает.
C
Многие кейсы всплывают только после плотного погружения в код. Если задача реально простая - другое дело
VF
В ситуации где люди воспринимаются как "тупые кодеры" безусловно нужен контроль на выходе
VF
Ну и погрузитесь в код, в чем проблема?
VF
Очевидно, что в ходе работы могут возникнуть новые обстоятельства, но это лишь говорит нам следующее: остановись и выполни перепроектирование. На код ревью исправлять такую ситуацию будет поздно
AK
Столько же, а то и меньше, при условии внедрения CI и использовании автоматизированных линтеров и автоматизированных тестов. Если еще и TDD добавить, можно еще сократить. К сожалению с последним обычно возникают проблемы, т.к. подход требует недюжей дисциплины.
VF
Причем до написания основного кода 😁