Комментарии 14
Вместо обсуждения этой неинтересной статьи хочу поговорить с вами о таком процессе, который я называю моргенштернизация IT.
Не подумайте, я не собираюсь хейтить Моргенштерна, он умный чувак. Он просто понял как работает хайп и что надо делать чтобы хайпануть. Поэтому он вообще не пытается делать классную и интересную музыку, он четко понимает какое говно зайдет людям и делает именно это говно. Только для того чтобы получить хайп.
Айти же давно превратилось в массовку, где большинство в профессии шарит на уровне ценителей Моргенштерна. И поэтому тут тоже можно хайповать. Только для этого нужен рецепт хайпа.
И этот рецепт хайпа в ойти прост — берешь всем известную или никому не нужную вещь из модной темы (Ну что там сейчас модно? Ммм тестирование, аджайл, тайм-менеджмент и т.п.), немного видоизменяешь чтобы казалось что сам придумал, клеишь модный ярлычок и форсишь везде где можешь. Макаки ведутся, хайп вместе с самооценкой растет, можно еще и подкаст заодно порекламить.
Только автор толком ниасилил, взял TDD (который тоже какойто недоморгенштерн по этой же схеме 100 лет назад придумал), переименовал в Mudation Driven Development и пытается расфорсить.
Каким же жалким надо быть, чтобы вместо того чтобы создавать крутые продукты, проектировать новые технологии, изобретать новые вещи, сидеть и пытаться раздуть никому не нужную мелочную херную до хайповой темы? Только для того чтобы потешить свое чсв перед макаким, которых нормальные специалисты презирают.
Не подумайте, я не собираюсь хейтить Моргенштерна, он умный чувак. Он просто понял как работает хайп и что надо делать чтобы хайпануть. Поэтому он вообще не пытается делать классную и интересную музыку, он четко понимает какое говно зайдет людям и делает именно это говно. Только для того чтобы получить хайп.
Айти же давно превратилось в массовку, где большинство в профессии шарит на уровне ценителей Моргенштерна. И поэтому тут тоже можно хайповать. Только для этого нужен рецепт хайпа.
И этот рецепт хайпа в ойти прост — берешь всем известную или никому не нужную вещь из модной темы (Ну что там сейчас модно? Ммм тестирование, аджайл, тайм-менеджмент и т.п.), немного видоизменяешь чтобы казалось что сам придумал, клеишь модный ярлычок и форсишь везде где можешь. Макаки ведутся, хайп вместе с самооценкой растет, можно еще и подкаст заодно порекламить.
Только автор толком ниасилил, взял TDD (который тоже какойто недоморгенштерн по этой же схеме 100 лет назад придумал), переименовал в Mudation Driven Development и пытается расфорсить.
Каким же жалким надо быть, чтобы вместо того чтобы создавать крутые продукты, проектировать новые технологии, изобретать новые вещи, сидеть и пытаться раздуть никому не нужную мелочную херную до хайповой темы? Только для того чтобы потешить свое чсв перед макаким, которых нормальные специалисты презирают.
Я согласен, что термины придумывают направо и налево. Например, гексагональная архитектура — бред в общем-то.
Однако в mutation driven development я все же вижу рациональное зерно.
Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.
Ну и еще и оскорбления.
Однако в mutation driven development я все же вижу рациональное зерно.
Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.
Ну и еще и оскорбления.
Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.Ну это вы просто пытаетесь высосать из пальца ответ мне. Если бы ваша статья не была пустой и неинтересной, коментов и рейтинга у нее было бы побольше
Однако в mutation driven development я все же вижу рациональное зерно.Есть вагон людей, которые и в TDD видят рациональное зерно. Хотя это такой же высосаный из пальца бред ради хайпа. Я «борюсь» против того, чтобы расхайпованная бредятина не превращалась в индустрии в best practice
Если бы ваши комменты были менее токсичными, ваш рейтинг (карма) была бы повыше.
Вместо аргументов идет злоба, оскорбления. Это просто раздражает, не более того: никакой осмысленной позиции не вижу что-то.
Если бы ваши комменты были менее токсичными, ваш рейтинг (карма) была бы повыше.Если бы меня интересовала карма, я бы писал по другому.
Вместо аргументов идет злоба, оскорбленияАргументация в моих коментах есть, просто вы ее игноируете
не вижу что-то.Вы написали высосаную из пальца статью, про высосаную из пальца никому не нужную методологию, чтобы попиарить свой никому ненужный блог с 3.5 подписчиками и подкаст, который ведете чтобы набить плюсиков в популярность, чтобы подороже продаться.
Достаточно аргументировано? Или назовете эти факты оскорблениями?
А теперь вы пытаетесь сделать хорошую мину при плохой игре, но сказать вам особо нечего, что хорошо видно по вашему безжизненному комментарию
Под аргументами я понимаю что-то связанное с сутью статьи: разработка через мутации. А не переходы на личности и выяснения, кто чей блог шатал.
Такая неинтересная статья, такой неинтересный комент, ну так читайте интересные статьи и коменты.
«Я три дня гналась за вами, чтобы сказать, как вы мне безразличны»
Такая неинтересная статья, такой неинтересный комент, ну так читайте интересные статьи и коменты.
«Я три дня гналась за вами, чтобы сказать, как вы мне безразличны»
Под аргументами я понимаю«Ваши пруфы не пруфы». Ну хорошо хоть не «сперва добейся»
Если вы вдруг забыли на какой комент отвечали, то напомню: эта ветка коментов не про вашу статью, а про моргенштернизацию (лел) ойти, частью которой вы являетесь. И именно об этом процессе я всю ветку говорю, а не о вашей статье — она нахрен никому не сдалась.
Хотите чтобы люди обсуждали ваши статью по сути, добавьте туда суть. Пока что там обсуждать нечего.
ну так читайте интересные статьи и коменты.Если хотите чтобы вас не обсирали, не давайте повода для этого. А не указывайте людям что им делать.
TDD — это очень тонкая методология, и она касается даже не процесса написания основного кода, а процесса создания новых фич. Причём, лучше всего оно работает для машиноориентированных фич. Пишешь тест под несуществующую фичу и в этот момент (будучи потребителем API) хорошо и плотно думаешь о том, как эту фичу сделать удобной (себе). Думаешь до того, как пишешь, что бесценно.
Странный подход делать это руками когда есть инструменты Mutaition Testing для большинства популярных языков
Честно говоря, сначала я тоже удивился такому подходу, когда читал оригинальную статью. Однако потом вспомнил один свой кейс.
У меня был небольшой микросервис, который выполнял важную функцию, но бизнес-логики там было не очень много. Т.е. сервис дёргал 5 разных внешних API, и в зависимости от их ответов формировал своё заключение.
Бизнес-логики — там было буквально пара-тройка методов, а всё остальное — бойлерплейт, который и тестировать то особо не надо: если бы там что-то пошло не так, это было бы видно в логах, и можно было бы просто откатить.
Но при этом бизнес-логика наборот довольно важная, и ошибку там пришлось бы искать очень долго.
При этом ради пары методов городить инструменты по всеобъемлющему мутационному тестированию ну особо не нет смысла. А так, вручную подёргав условия, можно было бы убедиться, что покрытие более менее достаточное.
Т.е. это промежуточный, переходный этап перед тотальным подключением автоматического мутационного тестирования всего проекта
У меня был небольшой микросервис, который выполнял важную функцию, но бизнес-логики там было не очень много. Т.е. сервис дёргал 5 разных внешних API, и в зависимости от их ответов формировал своё заключение.
Бизнес-логики — там было буквально пара-тройка методов, а всё остальное — бойлерплейт, который и тестировать то особо не надо: если бы там что-то пошло не так, это было бы видно в логах, и можно было бы просто откатить.
Но при этом бизнес-логика наборот довольно важная, и ошибку там пришлось бы искать очень долго.
При этом ради пары методов городить инструменты по всеобъемлющему мутационному тестированию ну особо не нет смысла. А так, вручную подёргав условия, можно было бы убедиться, что покрытие более менее достаточное.
Т.е. это промежуточный, переходный этап перед тотальным подключением автоматического мутационного тестирования всего проекта
НЛО прилетело и опубликовало эту надпись здесь
Mutation-testing руками, да ещё и в середине рабочего процесса — это глупость. Разумный метод — использование фреймворков мутации, причём мутационные тесты — это не часть продакшен-пайплайна, а отдельно стоящий пайплайн по таймеру или по наличию свободных ресурсов. У мутационного тестирования нет конца (т.к. это фаззинг с рандомом), есть только апериодическое сообщение о найденных потенциальных багах или плохо написанных тестах.
С академической точки зрения — концепция как концепция, со своими плюсами и минусами. Единственное, на мой взгляд, практическое применение — проекты, где ресурсы почти не ограничены, но требуется исключительная стабильность. Намного более девяти тысяч)
Что интересно, этот подход можно совместить с отладкой разного рода багрепортов. Хоть как-то поднять отдачу.
Что интересно, этот подход можно совместить с отладкой разного рода багрепортов. Хоть как-то поднять отдачу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mutation Driven Development