Кажется, что вы вполне можете от айсберга проблем показать лишь ее вершину, но со всей конкретикой - «вот тут мы внедряли такой-то кусок бизнес-задачи, и оно стоило вам 100 часов разработки. А также сломало вот такой функционал, что стоило вам ещё 30 часов разработки. Это дорого. Если потратить еще 100 часов и вот этот кусок привести в порядок, то на следующее приседание вокруг этого функционала будет потрачено 25 часов. А если нет - то уже 150, потому что ради ваших дедлайнов с небес в код изрядно так насрали. Решайте»
Я предположу, что людям из бизнеса интересны ответы на вопросы «а куда мы тратим наши деньги?». И все их наводящие вопросы как раз были в поисках этих ответов.
И, будем уж совсем честны - даже если техдолг представляет собой кусок каши времен мезозоя, с бОльшей его частью зачастую можно смириться, и даже ничего от этого не потерять. Но если даже критические проблемы (риск краха инфры, крит уязвимости и прочее) бизнес не хочет решать - думаю, вам не по пути. Так тоже бывает
Либо вы очень везучий, либо вы знаете то, чего не знаю я. Я умудрился схватить бан на ютубе пару лет назад, и мне, кажется, уже раз 5 отказывали. А ведь я ничего и не снимал - сидел себе, лайки-дизайки ставил и на каналы подписывался. И ведь даже причину бана не выяснить. Как вам удалось из этого порочного круга выйти?
Попробую предположить, что "чрезмерно" - это тогда, когда коммуникация становится конечной целью, а не средством для решения реальных проблем. В таких ситуациях можно увидеть, как, например, откровенная дичь успешно проходит код-ревью, лишь бы не создавать конфликты
Вы уверены, что приведенные примеры в принципе относятся к unit-тестированию?
В качестве юнита можно взять как один класс, так и их связанную группу. И проверить работу бизнес-логики (и только бизнес-логики) в изоляции от особенностей конкретного хранилища, накладных расходов (=время теста), а также недетерминированности (отвал бд - точка отказа)
Ваши примеры я бы назвал чуть иначе - интеграционное тестирование. Впрочем, вполне могу быть и не прав
Кажется, что вы вполне можете от айсберга проблем показать лишь ее вершину, но со всей конкретикой - «вот тут мы внедряли такой-то кусок бизнес-задачи, и оно стоило вам 100 часов разработки. А также сломало вот такой функционал, что стоило вам ещё 30 часов разработки. Это дорого. Если потратить еще 100 часов и вот этот кусок привести в порядок, то на следующее приседание вокруг этого функционала будет потрачено 25 часов. А если нет - то уже 150, потому что ради ваших дедлайнов с небес в код изрядно так насрали. Решайте»
Я предположу, что людям из бизнеса интересны ответы на вопросы «а куда мы тратим наши деньги?». И все их наводящие вопросы как раз были в поисках этих ответов.
И, будем уж совсем честны - даже если техдолг представляет собой кусок каши времен мезозоя, с бОльшей его частью зачастую можно смириться, и даже ничего от этого не потерять. Но если даже критические проблемы (риск краха инфры, крит уязвимости и прочее) бизнес не хочет решать - думаю, вам не по пути. Так тоже бывает
Либо вы очень везучий, либо вы знаете то, чего не знаю я. Я умудрился схватить бан на ютубе пару лет назад, и мне, кажется, уже раз 5 отказывали. А ведь я ничего и не снимал - сидел себе, лайки-дизайки ставил и на каналы подписывался. И ведь даже причину бана не выяснить. Как вам удалось из этого порочного круга выйти?
А на каком окружении вы пытаетесь поднять докер, если не секрет?
Всегда удивляло то, что LTS-версии laravel строились на не-LTS зависимостях symfony. Думал - неужели это не стрельнет в ногу? В общем, таки стрельнуло
Единственное "но" - иногда что-то второстепенное перестает быть таковым, а код уже на плохих рельсах.
А в целом идею поддерживаю
Где-то видел фразу в духе "если фундамент вашего приложения построен исключительно на софт скиллах, то и надёжность его будет соответствующая"
Попробую предположить, что "чрезмерно" - это тогда, когда коммуникация становится конечной целью, а не средством для решения реальных проблем. В таких ситуациях можно увидеть, как, например, откровенная дичь успешно проходит код-ревью, лишь бы не создавать конфликты
Вы уверены, что приведенные примеры в принципе относятся к unit-тестированию?
В качестве юнита можно взять как один класс, так и их связанную группу. И проверить работу бизнес-логики (и только бизнес-логики) в изоляции от особенностей конкретного хранилища, накладных расходов (=время теста), а также недетерминированности (отвал бд - точка отказа)
Ваши примеры я бы назвал чуть иначе - интеграционное тестирование. Впрочем, вполне могу быть и не прав