Comments 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, и в зависимости от их ответов формировал своё заключение.
Бизнес-логики — там было буквально пара-тройка методов, а всё остальное — бойлерплейт, который и тестировать то особо не надо: если бы там что-то пошло не так, это было бы видно в логах, и можно было бы просто откатить.
Но при этом бизнес-логика наборот довольно важная, и ошибку там пришлось бы искать очень долго.
При этом ради пары методов городить инструменты по всеобъемлющему мутационному тестированию ну особо не нет смысла. А так, вручную подёргав условия, можно было бы убедиться, что покрытие более менее достаточное.
Т.е. это промежуточный, переходный этап перед тотальным подключением автоматического мутационного тестирования всего проекта
UFO just landed and posted this here
Mutation-testing руками, да ещё и в середине рабочего процесса — это глупость. Разумный метод — использование фреймворков мутации, причём мутационные тесты — это не часть продакшен-пайплайна, а отдельно стоящий пайплайн по таймеру или по наличию свободных ресурсов. У мутационного тестирования нет конца (т.к. это фаззинг с рандомом), есть только апериодическое сообщение о найденных потенциальных багах или плохо написанных тестах.
С академической точки зрения — концепция как концепция, со своими плюсами и минусами. Единственное, на мой взгляд, практическое применение — проекты, где ресурсы почти не ограничены, но требуется исключительная стабильность. Намного более девяти тысяч)
Что интересно, этот подход можно совместить с отладкой разного рода багрепортов. Хоть как-то поднять отдачу.
Что интересно, этот подход можно совместить с отладкой разного рода багрепортов. Хоть как-то поднять отдачу.
Sign up to leave a comment.
Mutation Driven Development