Вы знаете, но ведь мы с вами сошлись во мнениямих.
Если речь идет о ситуации, где цена ошибки большая (бронежилет спасет вам жизнь), то я буду первый кто попросит выдать мне бронежилет (захочет использовать TDD).
Но если речь идет о том, что бросаются камнями и максимум что грозит синяк. То я лично выбираю каску и не более. В бронежилете бегать тяжело а от камней можно увернуться.
>Проще сменить команду с неподходящей парадигмой в подходе к разработке, чем учить работающих по ТЗ гибкой разработке или экстремальщиков предварительному согласованию архитектуры и спецификаций.
Ваше видение проблемы вызывает уважение (без шуток). И я сожалею, что наш менеджмент этого не понимал.
Я и мои коллеги обучены и привычны к использованию Waterfall с подробным планированием и согласованием интерфейсов. Собственно, я описывал взгляд с этой стороны. Попытка заставить нас использовать TDD отзывалась болью и мучениями, окончилась крахом и стоило громадного количества человеко-часов.
Другое дело, что поменять команду (>50 человек) было нереально.
>Не воспринимайте это как персональное оскорбление, но в своём анализе вы многократно пали жертвой Availability bias. Отсюда и пост. Увы, у вас по какой-то причине всё пошло плохо, и ни вы, ни ваши коллеги не видели примеров того, как оно работает и делает жизнь лучше.
Поясните пожалуйста. Вы имеете в виду, что у меня выборка малая? Что я сужу исключительно по опыту, с которым сталкивался, хотя немало и обратного опыта, так?
Вынужден с вами согласиться. Пожалуй я слишком резко обобщаю.
Тогда, воспринимайте мой пост как отчет о специфическом кейсе в фирме, где я работал.
Вообще говоря, я признаю, что теоретически юнит тесты — замечательная вещь. Иначе наш менеджмент не был бы так уверен в том что это надо использовать. Они ведь вменяемые люди. Более того, для некоторых специфических ситуаций использование юнит тестов очень даже оправдано.
Точно также теоретически социализм — замечательная вещь. Иначе столько людей не были бы так уверены в том, что его надо строить. Многие из них вполне вменяемые люди. И более того, в некоторых специфических случаях социализм вполне работает. Взять хотя бы Израильские Кибуцы.
Но, к сожалению, в жизни имеются некоторые детали, которые сводят благостную картинку на нет. Что примечательно, в обоих случаях (тесты и социализм) — все портит человеческий фактор.
Собственно, мой пост направлен на то, чтобы объяснить, как оно в реальности у нас происходило. И может произойти у других.
>Вы рефакторите код или добавляете новую функциональность, модифицируя существующий код.
>Расскажите как после внесения изменений вы убеждаетесь, что своими изменениями вы не поломали что-то ещё?
Во-первых, код рефакторится довольно редко. Принцип «работает — не трогай» используется очень широко.
Во-вторых, если уж код подвергается рефакторингу, чаще всего меняются интерфейсы. И это делает тесты заведомо невалидными.
В-третьих, в большом продукте при рефакторинге, все равно QA обязан провести sanity тестирование.
В-четвертых, code review вместе с функциональными тестами решают проблему.
И в пятых, чисто эмпирический факт:
За 3 года работы, юнит тесты ни разу не помогли найти баг при рефакторинге. Да, они проваливались, но после их изучения они признавались устаревшими и просто отключались.
Если речь идет о ситуации, где цена ошибки большая (бронежилет спасет вам жизнь), то я буду первый кто попросит выдать мне бронежилет (захочет использовать TDD).
Но если речь идет о том, что бросаются камнями и максимум что грозит синяк. То я лично выбираю каску и не более. В бронежилете бегать тяжело а от камней можно увернуться.
Ваше видение проблемы вызывает уважение (без шуток). И я сожалею, что наш менеджмент этого не понимал.
Я и мои коллеги обучены и привычны к использованию Waterfall с подробным планированием и согласованием интерфейсов. Собственно, я описывал взгляд с этой стороны. Попытка заставить нас использовать TDD отзывалась болью и мучениями, окончилась крахом и стоило громадного количества человеко-часов.
Другое дело, что поменять команду (>50 человек) было нереально.
Поясните пожалуйста. Вы имеете в виду, что у меня выборка малая? Что я сужу исключительно по опыту, с которым сталкивался, хотя немало и обратного опыта, так?
Вынужден с вами согласиться. Пожалуй я слишком резко обобщаю.
Тогда, воспринимайте мой пост как отчет о специфическом кейсе в фирме, где я работал.
Точно также теоретически социализм — замечательная вещь. Иначе столько людей не были бы так уверены в том, что его надо строить. Многие из них вполне вменяемые люди. И более того, в некоторых специфических случаях социализм вполне работает. Взять хотя бы Израильские Кибуцы.
Но, к сожалению, в жизни имеются некоторые детали, которые сводят благостную картинку на нет. Что примечательно, в обоих случаях (тесты и социализм) — все портит человеческий фактор.
Собственно, мой пост направлен на то, чтобы объяснить, как оно в реальности у нас происходило. И может произойти у других.
>Расскажите как после внесения изменений вы убеждаетесь, что своими изменениями вы не поломали что-то ещё?
Во-первых, код рефакторится довольно редко. Принцип «работает — не трогай» используется очень широко.
Во-вторых, если уж код подвергается рефакторингу, чаще всего меняются интерфейсы. И это делает тесты заведомо невалидными.
В-третьих, в большом продукте при рефакторинге, все равно QA обязан провести sanity тестирование.
В-четвертых, code review вместе с функциональными тестами решают проблему.
И в пятых, чисто эмпирический факт:
За 3 года работы, юнит тесты ни разу не помогли найти баг при рефакторинге. Да, они проваливались, но после их изучения они признавались устаревшими и просто отключались.