А как вы боретесь с тем, что программисты не проверяют результат?

Question

[NightWriter]

Вопрос о ситуациях, когда программист сделал что-то, залил и не увидел/не проверил/не проклацал, что то, что он сделал – не особо-то и работает

Answer 1

[Tenkoff]

Увольняем.

Answer 2

[Bambr]

Ввели кодревью, резко уменьшилось количество кривых «фиксов», которые не проверялись автором на работоспособность вообще. Но это, конечно, не серебряная пуля.

Comments

[pxx]

Дополню несколькими пунктами из своей практики.
1. Код ревью без исключений.
2. Демонстрация ревьюверу того, что проект компилируется/билдится/деплоится в зависимости от задачи.
2. Демонстрация ревьюверу измененного/добавленного функционала в общих чертах. Эдакий очень легонький смоук-тест.

Answer 3

[Назар Мокринский]

Только перепроверять, постоянно. Каюсь, иногда тоже так получается, и мне нет оправдания.

Answer 4

[PerFORmeRofDeS]

Вызвать родителей!
А вообще должен присутствовать тестер + нормальный менеджер для контроля.

Answer 5

[1nd1go]

Код-ревью
Smoke тест
Regression тест

А также надо стремиться трэкать количество фиксов после репортинга о выполнении. По низким показателям проводить беседы о причинах. Может человека утомили ваши задачи, ему хочется чего-то другого. И т.п.

Косячат все, кто-то больше, кто-то меньше. Главное — когда это становится критично для проекта. Не закрыл div — не сильный баг. Но если постоянно фичи не доделывваются, но закрываются как готовые — это надо копать.

Answer 6

[Inori]

TDD/BDD + бета сервер.

Comments

[NightWriter]

TDD|BDD не помогает, когда, например, div не закрыли или в css налажали, или в одном месте поправили, а в другом нет. Бета-сервер – это отлично, но тут, получается, программист заливает на бетку то, что сделал, не глядя – тестировщик посмотрит все равно. Или как?

[Назар Мокринский]

Только перепроверять, постоянно. Каюсь, иногда тоже так получается, и мне нет оправдания.

[Inori]

Так какая у вас проблема?
Вы боитесь за качество проекта на продакшне или вас сам факт «залил и не проверил» смущает?
Если второе — то это как бы человеческий фактор, тут только разговоры с виновником помогут.

Answer 7

[LeoCcoder]

Таски у нас может закрывать только ПМ.
Просто так таск он не закроект, в конце таска должна быть причина, почему его можно закрыть. Если таск был: «не отображается аватарка в профиле, если ее сделать с камеры», то в конце таска должна быть фраза: «Починил и проверил, теперь аватарка появляется, если ее сделали с камеры». Желательно также приложить скриншот и любые другие доказательства, что оно теперь работает.
ПМ или тестировщики всегда имеют доступ к версии продукта, где присутствует результат работы выполненные в закрываемом таске.
Поэтому ПМ или тестировщик всегда может проверить точно ли баг исправлен (обычно это делается только со сложными тасками), но может и закрыть таск сразу.
Еще хочется добавить что у нас 2 сервера: боевой для пользователей и девелоперский для разработчиков. Все сначало проверяется на девелоперским сервере. Раз в 1-2-3 недели формируется версия и обновляется боевой сервер. Если это критикал баг-фикс, то формируется мини-версия в тот же день, когда баг был закрыт и обновляется боевой сервер.

Можно штафовать разработчиков за явную халатность. Но это думаю не сильно поможет.

Answer 8

[denver]

Больная тема, однако имхо против лени нет приема.

Answer 9

[EndUser]

Введите правило «непроверенный код = ненаписанный код».
Балбесам можно приставить тестера.
Если превращается в систему — штрафовать согласно выполненной работе (там сразу видно в цифрах, что выполнил 4 задания из 20 на текущий месяц)
При рецидиве уволить балбесов.

Answer 10

[Anton Taraev]

Очень интересно описано решение это проблемы www.ozon.ru/context/detail/id/7360633/ Какжды программист должен стараться сделать максимально качественный код

Answer 11

[Вячеслав Плиско]

Главное правило — коммитер не мержит свой код. Код обязан быть с тестом. Соответственно коллега проверяет и ревьювит код, прогоняет тесты и смотрит чтобы не упали старые.