Попробуйте в каком-нибудь проекте, ради эксперимента:
писать тесты только на чистые функции (очень много кода пишется только по идею "тестируемости")
инжектить классы, а не абстракции (пока не будет двух реализаций)
Я где-то 8 лет назад поймал себя на мысли что у меня тесты стали походить на произведения Лавкафта: элдрич юнит тесты с циклопиан моками тестируют проблемы из параллельного измерения. Найти баланс я не смог, поэтому решил пойти с нуля: не писать моковые тесты вообще, в надежде что где-то что-то начнёт ломаться и я пойму где же эти тесты необходимы. Вот только ничего не сломалось; я если и ошибаюсь где-то, то это либо находят интеграционные тесты, либо я сам при смоук тестировании, либо кто-нибудь случайно через год.
Отказался использовать в аргументации: звучит фальшиво и лениво. Стоит использовать только аргументы которые можно опровергнуть, иначе создаётся ощущение что тебя послали на 4..5 букв. YAGNI, KISS, SOLID и прочие имеют значение на момент прочтения - суть уловили, впитали и забыли.
Например:
я положил весь код в контроллер - не потому что KISS, а потому что это CRUD без логики; появится логика - усложним _немного_
я не разделил логику и доступ к данным - не потому что я не люблю Single Responsibility, а потому что меня задолбало смотреть в два монитора сразу наш микросервис уже достаточно responsible
я обработал все ошибки в лог - не потому что YAGNI, а потому что я не знаю, что здесь вообще будет происходить и, прежде чем писать обработку, хочу на это сначала посмотреть глазами (добавлю алерт в kibana на этот лог)
Поддерживаемость и простота — объективные метрики качества.
Вот нет, к сожалению. Если во главу угла ставить поддерживаемость и простоту, то исчезает например идемпотентность и адекватная обработка ошибок. Простоту использовать во вред также легко как и оверинжениринг.
Я для себя отказался от YAGNI, KISS и SOLID, это всё уже стало частью поп-культуры программирования и мало что значит. Вбрасывать это в разговор - к срачу.
Кстати, и overengineering и oversimplification можно использовать для успокоения нервов особо бесноватых индивидуумов. Иногда выходить за рамки, мне кажется, можно и нужно.
Мы публично хвалим интроверта, который в этот момент хочет провалиться сквозь землю. Мы дарим сертификат на ужин человеку, который сидит на диете. Мы пишем «молодец!» в общем чате тому, кто жаждет личного разговора с руководителем.
Поэтому хвалить нужно себя, за достижение своих целей. Корпоративное словоблудие: его либо игнорировать, либо ему подыгрывать - кому что больше по душе.
При нагрузке выше VO2 max "горит" всё — и ноги, и лёгкие (лактат там тоже накапливается). Но, в отличие от ног, я ни разу не сталкивался с "усталостью" дыхательных мышц; лактат вызывает дискомфорт, но не более.
Если взять условный all-out тест на 20 минут, то при высоком каденсе (100-110 RPM) к концу останавливаешься не из-за усталости, а потому что терпеть такой стресс дольше психологически невозможно. На низком каденсе за те же 20 минут ноги "отвалятся" — по крайней мере, у меня.
Если постепенно увеличивать нагрузку то за год (1-2 сезона) можно справиться. Первые 2-3 месяца будет что-то вроде адаптации (болит всё и постоянно, самое классное время). Большая нагрузка требует много еды, очень много еды - х2 х3 порции легко. Я за первые несколько лет какое-то чудовищное количество риса с курицей съел...
Нагрузку можно перекладывать на лёгкие через увеличение RPM - лёгкие восстанавливаются быстрее чем ноги (по сути: крутить быстрее, а на жать сильнее). Если поддерживать высокий RPM то, со временем, увеливается эффективность отвода лактата (и в лёгких и в ногах), снижается потребление кислорода, повышается граница до которой организм всё ещё может использовать жир и 20 км/ч легко превращаются в 30-35 км/ч за год. Дальше уже сложнее.
Я последние 5 лет практически не пишу юнит-тесты на крудовую бизнес-логигку, в первую очередь из-за того что тонны тестов только замедляют рефакторинг и превращаются в копипаст: логика переносится в тесты (осмысленно или нет - не так важно), так как цель - зелёная галочка, а не корректность. С таким подходом начинают появляться и подрывать доверие к системы false-positive тесты; со временем начинаешь задаваться вопросом: а стоили ли 2000 зелёных галочек потраченного на них времени...
Если я правильно понял, что самого кода сервисов генератор тестов не видит, т.е он не может превратить баг имплементации в фичу, т.е шанс на false-positive уменьшается. Также не должно быть проблем с рефакторингом, так как тесты можно перегенерировать всегда.
Интересно, какие категории ошибок может такой подход находить и не приведёт ли это к тому, что разработчики будут тратить время на вставку ассертов вроде if arg < 0 throw no-way-exception куда надо и не надо чтобы осчастливить генератор?
Другими словами, не добавит ли это разработчикам больше не самой полезной работы?
На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.
Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.
Нельзя просто так сказать, нам в команду нужен крутой автоматизатор и в течение месяца он у вас появился.
Был случай, когда мы наняли тестировщика, который, мягко говоря, преувеличил свои навыки автоматизации. Через пару месяцев работы бок о бок с разработчиками его навык уже позволял работать самостоятельно. В изоляции он бы не выжил.
Во-первых, тогда он должен досконально изучить наш сервис. Что не всегда возможно.
Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.
Понятно, что чем меньше покрытие, тем больше вероятность пропустить баг, но разработчики со стажем знают в каких сценариях они часто ошибаются и могут направлять тестирование на самые злачные кейсы.
В конце концов, нужно больше общаться и меньше впадать в крайности.
Не стоит ассоциировать каждого продакта и проджекта с бизнесном. Чаще всего это точно такие же наёмные рабочие которым на "принесёт ли денег фича" соврершенно плевать, так как к моменту, когда фича может начать или не начать приносить деньги, он, менеджер, уже будет работать где-то в другом месте или пойдёт на повышение. А вот программистам кучу криво написанного кода поддерживать придётся, если конечно они сами не свинтят куда-нибудь.
Возможность писать качественный код и получать удовольствие от работы всегда и везде приходится выгрызать зубами. Если не хочется выгрызать, значит не очень и хочется писать качественный код.
Да, сможет. Личного опыта не имею, но коллега + жена + 2 ребёнка живут на стандартную экспатскую зарплату. В Амстердаме жить вряд ли получится, но купить\снять дом в Almere можно.
Всё это, к сожалению, правда. Разрыв между крупными корпорациями и небольшими компаниями становится всё больше и больше, а олдскульные компании упрямо сидят на 85к максимум (и то, если повезёт). При этом никого не смущает, что искать человека на такую зарплату придётся целый год или два, тратя кучу ресурсов и времени.
Как человек уже 4 года живущий в Амстердаме и постоянно собеседующий разработчиков скажу, что у кандидатов из "СНГ" очень высокие зарплатные ожидания, и это, пожалуй, самая популярная, если не единственная причина отказа. Чем олдскульнее голландская компания, тем меньше она хочет платить выше психологической отметки в 85к в год. Современные средние\крупные компании могут платить и выше, но тут как повезёт.
В плане квалификации у среднего программиста из "СНГ" проблем быть не должно никаких: уровень среднестатистического кандидата из Индии и Турции несравнимо ниже, но им легко дадут стандартные 60-75, даже если от их решений хочется рыдать кровавыми слезами.
На мой взгляд, Амстердам идеален для "хочется пожить в Европе и разговаривать по-английски", но с зарплатой и техническим уровнем тут сложно (исключительно с точки зрения кандидатов из РФ).
Попробуйте в каком-нибудь проекте, ради эксперимента:
писать тесты только на чистые функции (очень много кода пишется только по идею "тестируемости")
инжектить классы, а не абстракции (пока не будет двух реализаций)
Я где-то 8 лет назад поймал себя на мысли что у меня тесты стали походить на произведения Лавкафта: элдрич юнит тесты с циклопиан моками тестируют проблемы из параллельного измерения. Найти баланс я не смог, поэтому решил пойти с нуля: не писать моковые тесты вообще, в надежде что где-то что-то начнёт ломаться и я пойму где же эти тесты необходимы. Вот только ничего не сломалось; я если и ошибаюсь где-то, то это либо находят интеграционные тесты, либо я сам при смоук тестировании, либо кто-нибудь случайно через год.
Отказался использовать в аргументации: звучит фальшиво и лениво. Стоит использовать только аргументы которые можно опровергнуть, иначе создаётся ощущение что тебя послали на 4..5 букв. YAGNI, KISS, SOLID и прочие имеют значение на момент прочтения - суть уловили, впитали и забыли.
Например:
я положил весь код в контроллер - не потому что KISS, а потому что это CRUD без логики; появится логика - усложним _немного_
я не разделил логику и доступ к данным - не потому что я не люблю Single Responsibility, а потому что
меня задолбало смотреть в два монитора сразунаш микросервис уже достаточно responsibleя обработал все ошибки в лог - не потому что YAGNI, а потому что я не знаю, что здесь вообще будет происходить и, прежде чем писать обработку, хочу на это сначала посмотреть глазами (добавлю алерт в kibana на этот лог)
Вот нет, к сожалению. Если во главу угла ставить поддерживаемость и простоту, то исчезает например идемпотентность и адекватная обработка ошибок. Простоту использовать во вред также легко как и оверинжениринг.
Я для себя отказался от YAGNI, KISS и SOLID, это всё уже стало частью поп-культуры программирования и мало что значит. Вбрасывать это в разговор - к срачу.
Кстати, и overengineering и oversimplification можно использовать для успокоения нервов особо бесноватых индивидуумов. Иногда выходить за рамки, мне кажется, можно и нужно.
Поэтому хвалить нужно себя, за достижение своих целей. Корпоративное словоблудие: его либо игнорировать, либо ему подыгрывать - кому что больше по душе.
При нагрузке выше VO2 max "горит" всё — и ноги, и лёгкие (лактат там тоже накапливается). Но, в отличие от ног, я ни разу не сталкивался с "усталостью" дыхательных мышц; лактат вызывает дискомфорт, но не более.
Если взять условный all-out тест на 20 минут, то при высоком каденсе (100-110 RPM) к концу останавливаешься не из-за усталости, а потому что терпеть такой стресс дольше психологически невозможно. На низком каденсе за те же 20 минут ноги "отвалятся" — по крайней мере, у меня.
Есть есть, даже в очень тощих визуально людях достаточно жира.
Если постепенно увеличивать нагрузку то за год (1-2 сезона) можно справиться. Первые 2-3 месяца будет что-то вроде адаптации (болит всё и постоянно, самое классное время). Большая нагрузка требует много еды, очень много еды - х2 х3 порции легко. Я за первые несколько лет какое-то чудовищное количество риса с курицей съел...
Нагрузку можно перекладывать на лёгкие через увеличение RPM - лёгкие восстанавливаются быстрее чем ноги (по сути: крутить быстрее, а на жать сильнее). Если поддерживать высокий RPM то, со временем, увеливается эффективность отвода лактата (и в лёгких и в ногах), снижается потребление кислорода, повышается граница до которой организм всё ещё может использовать жир и 20 км/ч легко превращаются в 30-35 км/ч за год. Дальше уже сложнее.
Я последние 5 лет практически не пишу юнит-тесты на крудовую бизнес-логигку, в первую очередь из-за того что тонны тестов только замедляют рефакторинг и превращаются в копипаст: логика переносится в тесты (осмысленно или нет - не так важно), так как цель - зелёная галочка, а не корректность. С таким подходом начинают появляться и подрывать доверие к системы false-positive тесты; со временем начинаешь задаваться вопросом: а стоили ли 2000 зелёных галочек потраченного на них времени...
Если я правильно понял, что самого кода сервисов генератор тестов не видит, т.е он не может превратить баг имплементации в фичу, т.е шанс на false-positive уменьшается. Также не должно быть проблем с рефакторингом, так как тесты можно перегенерировать всегда.
Интересно, какие категории ошибок может такой подход находить и не приведёт ли это к тому, что разработчики будут тратить время на вставку ассертов вроде
if arg < 0 throw no-way-exceptionкуда надо и не надо чтобы осчастливить генератор?Другими словами, не добавит ли это разработчикам больше не самой полезной работы?
На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.
Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.
Был случай, когда мы наняли тестировщика, который, мягко говоря, преувеличил свои навыки автоматизации. Через пару месяцев работы бок о бок с разработчиками его навык уже позволял работать самостоятельно. В изоляции он бы не выжил.
Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.
Понятно, что чем меньше покрытие, тем больше вероятность пропустить баг, но разработчики со стажем знают в каких сценариях они часто ошибаются и могут направлять тестирование на самые злачные кейсы.
В конце концов, нужно больше общаться и меньше впадать в крайности.
Не стоит ассоциировать каждого продакта и проджекта с бизнесном. Чаще всего это точно такие же наёмные рабочие которым на "принесёт ли денег фича" соврершенно плевать, так как к моменту, когда фича может начать или не начать приносить деньги, он, менеджер, уже будет работать где-то в другом месте или пойдёт на повышение. А вот программистам кучу криво написанного кода поддерживать придётся, если конечно они сами не свинтят куда-нибудь.
Возможность писать качественный код и получать удовольствие от работы всегда и везде приходится выгрызать зубами. Если не хочется выгрызать, значит не очень и хочется писать качественный код.
Нет, не работает.
Да, сможет. Личного опыта не имею, но коллега + жена + 2 ребёнка живут на стандартную экспатскую зарплату. В Амстердаме жить вряд ли получится, но купить\снять дом в Almere можно.
Всё это, к сожалению, правда. Разрыв между крупными корпорациями и небольшими компаниями становится всё больше и больше, а олдскульные компании упрямо сидят на 85к максимум (и то, если повезёт). При этом никого не смущает, что искать человека на такую зарплату придётся целый год или два, тратя кучу ресурсов и времени.
Как человек уже 4 года живущий в Амстердаме и постоянно собеседующий разработчиков скажу, что у кандидатов из "СНГ" очень высокие зарплатные ожидания, и это, пожалуй, самая популярная, если не единственная причина отказа. Чем олдскульнее голландская компания, тем меньше она хочет платить выше психологической отметки в 85к в год. Современные средние\крупные компании могут платить и выше, но тут как повезёт.
В плане квалификации у среднего программиста из "СНГ" проблем быть не должно никаких: уровень среднестатистического кандидата из Индии и Турции несравнимо ниже, но им легко дадут стандартные 60-75, даже если от их решений хочется рыдать кровавыми слезами.
На мой взгляд, Амстердам идеален для "хочется пожить в Европе и разговаривать по-английски", но с зарплатой и техническим уровнем тут сложно (исключительно с точки зрения кандидатов из РФ).