Обновить

Нет времени на тесты — через неделю релиз

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели6.8K
Всего голосов 11: ↑10 и ↓1+10
Комментарии7

Комментарии 7

ЗакрепленныеЗакреплённые комментарии

Тимофей, спасибо за хорошо проработанный материал.
Возможно будет интересно. Вам или Вашим читателям. Кросс-ссылочка. Мы тоже пытались показать, как автотесты экономят именно время разработчика. Не так красиво получилось, как у Вас, зато есть конкретные цифры, не сильно отличающиеся от Ваших.

Даже в Европе, где культура разработки зрелая

Причём это не стартапы на коленке. Это компании, где шаблон баг-репорта составлен по ISO/IEC/IEEE 29119

Да ну, не смешите. Не скажу за всю Европу, но я работал в аутстаффе с полным портфелем европейских проектов. В том-то и беда, что везде лютый говнокод + бюрократия + потолок зарплат 5к. Самая выгодная стратегия европейского разраба - годами сидеть на попе ровно, саппортить заплесневелые легаси и заполнять бумажки по стандартам.

А видишь хороший код в европейской компании - где-то рядом ребята из наших краёв.

Хорошо вас понимаю. Но не стоит путать две вещи: качество кода и качество процесса. Говнокод, обложенный нормальным CI/CD, ревью, баг-трекингом по стандарту и внятным релизным циклом — это управляемый говнокод. Он предсказуемо деплоится, предсказуемо ломается и предсказуемо чинится. А красивый код без процесса — это русская рулетка, просто с красивым барабаном.

Данная цитата не про то, что в Европе пишут красивый код. Я бы больше хотел поставить фокус на то, что зрелый процесс снижает цену ошибки. И такой процесс как раз достижим за счет международных стандартов. Именно поэтому те компании могут себе позволить разработчиков, которые «сидят на попе ровно» — потому что система выстроена так, что героизм не требуется.

А «ребята из наших краёв» пишут хороший код часто не благодаря культуре, а вопреки — потому что процессов нет и всё держится на личном скилле. Это наш дар и проклятье.

Говнокод это не антоним визуально красивого кода, если что. Говнокод это материал, работа с которым потребляет нерационально много времени, когнитивных и эмоциональных усилий. Даже если написано все очень красиво.

А «ребята из наших краёв» пишут хороший код часто не благодаря культуре, а вопреки

Ой ли. В нашей практике последних 10-15 лет нормально часто менять проекты и работать на разных рынках. Ребята из бСССР и Восточной Европы банально впитали больше хороших практик и набрались большего опыта, чем условный инженер из благополучной Франции, который уже 20 лет сидит и ковыряет одно и то же за одни и те же деньги.

Но ок, я вашу точку зрения понял. Спор все равно беспредметный. Считайте, я просто байками поделился.

Тимофей, спасибо за хорошо проработанный материал.
Возможно будет интересно. Вам или Вашим читателям. Кросс-ссылочка. Мы тоже пытались показать, как автотесты экономят именно время разработчика. Не так красиво получилось, как у Вас, зато есть конкретные цифры, не сильно отличающиеся от Ваших.

вместо прокликивания всего приложения

Всё становится гораздо проще когда вообще нельзя что-то "прокликать". Ну то есть когда локально код можно запустить только через тесты. Тогда уже ни кодер, ни менеджер не задаются вопросом нужны ли тесты - они будут. И покрытие тестами улетит в космос и будет там оставаться.

Нам три года назад заказчик навязал serverless для всего бэкенда (AWS Lambda). В этом куча своих плюсов и минусов. Но самый прикол, что это выворачивает наизнанку выбор между тестами и прокликиванием. Обеспечить и поддерживать "прокликиваемость" оказывается сложнее, чем фигачить тесты.

У нас покрытие сейчас 97% при том, что мы к этому не стремились. А на возможность "прокликать" и её содержание мы забили в первые месяцы проекта.

Прокликать сценарии, конечно же, можно в нижних средах после деплоя. И к сожалению, некоторые баги интеграционного характера выявляются только там. Но это ничтожная проблема учитывая что мы получаем взамен.

Красота!

А по поводу:

Всё становится гораздо проще когда вообще нельзя что-то "прокликать".

Важно именно донести до разрабов пользу написания тестов, что я и пытался сделать в статье. Когда они видят требование Code Coverage >= 80 — им страшно и появляется обоснованное сомнение:

А зачем нам это вообще?

Звучит крайне интересно.

А можете кратенько описать, что это и как? Я слегка погуглил. Получается, это возможно только в облаках сторонних провайдеров? Да и то, только потому, что они тестовые среды не предоставляют? Т.е. если я захочу такое у себя, то мне надо отобрать доступы у разработчиков и тестировщиков к тестовым средам? или как мне этого serverless добиться?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации