Как называется такой подход к разработке, тестировани и баг-фиксу?
Работал на проекте, где совершенно не было тестов, но и завала по багам так же не было.
Вот почему то вспомнилось и приспичило узнать, есть ли название следующему подходу:
Весь код заливается через строгий и тщательный код-ревью. На дев сервере тестится только руками, зачастую мелкие баги попадают в продакшн.
Баг фикс организован таким образом, что клиент где-то натыкается на ошибку, ошибка сразу репортится в канал Slack и сохраняется в базе, как необработанная. Ошибка анализируется по стеку и переменным окружения, которые прилагаются к записи этой ошибки. Исправляется и заливается хот-фикс.
Сама ошибка, фактически - это отловленный Exception, который записывается в базу со всей доступной информацией. Если, например, произошла некоторая абстрактная ошибка, то при фиксе ставится исключение уже с человеческим названием, и если вдруг из за изменения некоторого модуля снова попадаем в ту же исключительную ситуацию - получаем уже абсолютно точное название, по которому понятно, что за ошибка произошла и можно даже вспомнить, где её искать (хотя, к ошибки крепится номер файла и строки, так что можно и не вспоминать).
Минусы очевидны - логические ошибки таким образом не выловишь, только по обращению клиента. Ну и, само собой, автотесты предусмотрели бы ошибку заранее.
Плюсы - не тратится время на тесты, благодаря чему быстрее пилятся фичи. Всё более стихийно, проект "чаще ошибается", но быстрее развивается и адаптируется под клиента, что очень важно, особенно в условиях жесткой конкуренции.
Это просто такой компромиссный способ разработки продукта с баг-фиксом малой кровью, или у такого подхода есть название и он является в некоторой степени вполне рабочей альтернативой? Хотелось бы узнать больше и почитать на эту тему.
Нашел и прочитал пару статей о статическом и динамическом анализе кода и сначала подумал, что это о моём вопросе. Но как оказалось, сходство только в том, что в динамическом анализе тоже используется рабочая версия программы, а не тестовая, фиктивная.
А может просто поздно, мозг устал и пытается выжать важное из неважного, - просто проект без тестов. Чего я привязался и ищу что-то глубокое? Кто знает...
про название метода не знаю, но я лично делаю упор на тщательное планирование, стройную архитектуру, поиск общих решений, хорошо структрированный код и повторное его использование
пару лет работаем над проектом, у которого несколько похожих модулей, в первом я не участвовала, а к третьему модулю количество продакшн ошибок сократили до двух абсолютно не критичных с более чем двух сотен в первом модуле
параллельно разработали универсальную систему для построения фронтенд приложений, которая сокращает время разработки с нескольких месяцев до пары-тройки недель одним разработчиком, плюс генерирует документацию по каждому приложению
QA работает как у всех с тикетами и нашими фиксами, но количество тестирования несравнимо меньше, а качество продашкн удивляет даже меня
Это совершенно нормальный подход к разработке. У нас в компании это называется data-driven development.
Суть в том что вместо тестов, весь проект плотно покрыт всякими разными метриками. Например покупки в минуту, регистрации в минуту, клики по кнопкам в конце концов. Все эти метрики отображаются на графиках. При релизе любой новой фичи мы смотрим на эти графики и алерты.
Если видим как что-то пошло вниз, значит есть баг, откатываем чиним, если все ровно значит багов либо нет, либо они не существенны и никак не влияют на пользовательский опыт.
У Вас в компании это, наверное, не правильно назвали, либо мы говорим не об одном и том же. data driven development - это способ разработки, ориентированной на данные. Так же, как есть ориентированная на события или на логику предметной области. DataDD - это (грубо говоря) когда вы проектируете хранилище данных, а поверх него потом генерируете модели записей таблиц, как позволяют легковесные фреймворки типа Yii, Laravel. Может, я чего то не знаю...
Про графики очень интересно, но какое же у вас множество измерений, что вы его отображаете на графиках и анализируете, а не смотрите в таблицах/списках? Я посмотрел Вашу компанию мельком и совершенно не могу представить, где у Вас применимо то, что вы описываете. Или Вы имеете ввиду, что можете отследить падение продаж и сделать вывод, что что-то не работает? А если это произошло не из-за поломке, а по другой тысяче возможных причин? Расскажите подробнее, если не сложно?
olijen: data-driven - это подход к разработке в целом, баги тут только как вторичка. Выкатили фичу, если что-то упало, значит пришли данные что есть баг, в этом суть.
У нас есть и таблицы с ошибками и графики всего что только можно, от продаж до посещений с разбивкой по любой платформе, стране и т.п.
Разумеется если просто так смотреть на график - то не ясно что тут повлияло, инструментов много. Графики - главный индикатор проблем, откуда ты уже начинаешь копать и искать источник.
Простой
Простой
Простой
