Комментарии 7
Тимофей, спасибо за хорошо проработанный материал.
Возможно будет интересно. Вам или Вашим читателям. Кросс-ссылочка. Мы тоже пытались показать, как автотесты экономят именно время разработчика. Не так красиво получилось, как у Вас, зато есть конкретные цифры, не сильно отличающиеся от Ваших.
Даже в Европе, где культура разработки зрелая
Причём это не стартапы на коленке. Это компании, где шаблон баг-репорта составлен по ISO/IEC/IEEE 29119
Да ну, не смешите. Не скажу за всю Европу, но я работал в аутстаффе с полным портфелем европейских проектов. В том-то и беда, что везде лютый говнокод + бюрократия + потолок зарплат 5к. Самая выгодная стратегия европейского разраба - годами сидеть на попе ровно, саппортить заплесневелые легаси и заполнять бумажки по стандартам.
А видишь хороший код в европейской компании - где-то рядом ребята из наших краёв.
Хорошо вас понимаю. Но не стоит путать две вещи: качество кода и качество процесса. Говнокод, обложенный нормальным CI/CD, ревью, баг-трекингом по стандарту и внятным релизным циклом — это управляемый говнокод. Он предсказуемо деплоится, предсказуемо ломается и предсказуемо чинится. А красивый код без процесса — это русская рулетка, просто с красивым барабаном.
Данная цитата не про то, что в Европе пишут красивый код. Я бы больше хотел поставить фокус на то, что зрелый процесс снижает цену ошибки. И такой процесс как раз достижим за счет международных стандартов. Именно поэтому те компании могут себе позволить разработчиков, которые «сидят на попе ровно» — потому что система выстроена так, что героизм не требуется.
А «ребята из наших краёв» пишут хороший код часто не благодаря культуре, а вопреки — потому что процессов нет и всё держится на личном скилле. Это наш дар и проклятье.
Говнокод это не антоним визуально красивого кода, если что. Говнокод это материал, работа с которым потребляет нерационально много времени, когнитивных и эмоциональных усилий. Даже если написано все очень красиво.
А «ребята из наших краёв» пишут хороший код часто не благодаря культуре, а вопреки
Ой ли. В нашей практике последних 10-15 лет нормально часто менять проекты и работать на разных рынках. Ребята из бСССР и Восточной Европы банально впитали больше хороших практик и набрались большего опыта, чем условный инженер из благополучной Франции, который уже 20 лет сидит и ковыряет одно и то же за одни и те же деньги.
Но ок, я вашу точку зрения понял. Спор все равно беспредметный. Считайте, я просто байками поделился.
Тимофей, спасибо за хорошо проработанный материал.
Возможно будет интересно. Вам или Вашим читателям. Кросс-ссылочка. Мы тоже пытались показать, как автотесты экономят именно время разработчика. Не так красиво получилось, как у Вас, зато есть конкретные цифры, не сильно отличающиеся от Ваших.
вместо прокликивания всего приложения
Всё становится гораздо проще когда вообще нельзя что-то "прокликать". Ну то есть когда локально код можно запустить только через тесты. Тогда уже ни кодер, ни менеджер не задаются вопросом нужны ли тесты - они будут. И покрытие тестами улетит в космос и будет там оставаться.
Нам три года назад заказчик навязал serverless для всего бэкенда (AWS Lambda). В этом куча своих плюсов и минусов. Но самый прикол, что это выворачивает наизнанку выбор между тестами и прокликиванием. Обеспечить и поддерживать "прокликиваемость" оказывается сложнее, чем фигачить тесты.
У нас покрытие сейчас 97% при том, что мы к этому не стремились. А на возможность "прокликать" и её содержание мы забили в первые месяцы проекта.
Прокликать сценарии, конечно же, можно в нижних средах после деплоя. И к сожалению, некоторые баги интеграционного характера выявляются только там. Но это ничтожная проблема учитывая что мы получаем взамен.

Красота!
А по поводу:
Всё становится гораздо проще когда вообще нельзя что-то "прокликать".
Важно именно донести до разрабов пользу написания тестов, что я и пытался сделать в статье. Когда они видят требование Code Coverage >= 80 — им страшно и появляется обоснованное сомнение:
А зачем нам это вообще?
Звучит крайне интересно.
А можете кратенько описать, что это и как? Я слегка погуглил. Получается, это возможно только в облаках сторонних провайдеров? Да и то, только потому, что они тестовые среды не предоставляют? Т.е. если я захочу такое у себя, то мне надо отобрать доступы у разработчиков и тестировщиков к тестовым средам? или как мне этого serverless добиться?

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