Иногда, когда коллеги решают использовать новый подход, смотришь на это и думаешь — что за дичь? Но так как ты в этом не эксперт, решаешь, что тебе просто показалось. Тем более, они говорят, что многие на рынке так делают. Ну, раз все делают, то и нам придётся с этим жить.
Конечно, можно принять это как данность, особенно если эта дичь происходит где-то далеко. Но что, если оно негативно влияет на твою непосредственную работу? Как понять — это лыжи не едут или?..
Отличный вариант — пойти и спросить у тех, кто сталкивался и с этим, и с другими подходами о плюсах, минусах и подводных камнях. Но такая возможность не всегда есть. Тогда можно пойти в ChatGPT и спросить у него об особенностях использования.
Причём, я бы советовал явно спросить в промте — а какие пререквизиты у того, чтобы внедрять подход? Очень часто выясняется что для правильного применения количество необходимых накладных расходов перевесит плюсы, которые были видны невооруженным взглядом.
На этой неделе на менторской сессии был отличный пример про это. Команда разработки использует trunk-based подход в работе с системой контроля версий. Радуются тому, что нужно совершать меньше телодвижений, чтобы докатить фичу до релиза. Правда, сами релизы регулярно фейлятся, но им кажется, что это нормально и не должно их настораживать.
Да, trunk-based development действительно распространенная практика. Но для номрального функционирования она требует серьезного покрытия тестами, а ещё предполагает наличие фиче-тогглов, чтобы любую новую фичу можно было включать-выключать. Т.е. действительно можно сэкономить на мёржах, но придётся делать дополнительную работу по управлению включением-выключением фичей и убедиться, что вся функциональность покрыта автотестами.
Спросил потом у ChatGPT про это - и он
отлично всё рассказал. Про фичетогглы, кстати, это он добавил, у меня на сессии совсем из головы вылетело.
