Понимание, какие тесты нужно гонять, а какие - нет это ключ к успешном проекту. Если нет такой цели, то нужно понимать, что проект проживет по инерции какое-то время, а потом загнется. А с подходом давайте гонять все - это тупик.
Мне кажется мы о разном говорим. Поддержание тестов в актуальном состоянии и выбор какие именно тесты запустить на каждом изменении это две разные задачи, да у них есть некоторая похожесть.
Логику по выбору тестов которые запустить на ревью нужно написать и её нужно поддерживать. И я утверждаю, что это - сложная задача. Что-то можно сделать через юниты и тесты контрактов на уровне модуля. Можно построить граф зависимостей по коду и тестировать связанные модули (все тесты для этих модулей). Но кроме этого могут быть зависимости через базу/очереди.
Разработка сложных проектов требует практик: Менять интерфейсы между модулями только осмысленно, выкидывать не используемый код.
А синтаксическое слогоделение используется только для переносов в письменной речи
Когда набераешь текст, то можно и не переносить. С появление выравнивания по ширине это даже выглядит норм.
Cпецифика фрацузского, что там надо знать следующее слово, чтобы произнести текущее и даже переносы отдельных слов путают. Если бы переносили предложения только по ритмическим группам, было бы удобнее.
С тем чтобы запускать только нужные тесты, я не спорю.
Я просто не знаю инструментов, которые смогут тесты разделить правильно. А чтобы это делать на уровне людей, нужно чтобы все писатели тестов хорошо знали всю систему и последние изменения в ней.
Стоимость для бизнеса складывается из затрат на поддержание какие тесты запускать при изменениях и пропущенные ошибки из-за того, что нужные тесты не запустили раньше.
Все эти тест-сьюты они критичны для ручного тестирования, потом, что оно не масштабируется. Для авто тестов можно достаточно быстро добавить железа.
Просто ускорить тесты намного проще. Это можно сделать один раз. При этом это может сделать даже человек, который не имеет глубоких знаний в бизнес логике и архитектуре этого проекта. Например человек который только пришёл на проект, как автор поста.
Но чтобы выйти за пределы России, надо совершить колоссальные шаги, которые мы делать не умеем - это надо признать честно.
Не надо говорить за всех, говорите за себя и свою копанию. Есть много примеров когда компании вышли за пределы. И еще больше людей которые создали компании уже за пределами.
Повторю (перефразируя) коммент под предыдущей статьёй: в многопоточном коде, если разные потоки будут использовать один экземпляр класса, любовь к манипуляциям с переменными объекта приведёт к большим проблемам.
У класса нет ни одного не статического публичного метода. Как его будет использовать разные потоки?
полностью опирается на ИИ-инструменты, привязывает свои навыки к стабильности энергосистемы и инфраструктуры. Достаточно сбоя техногенного, природного или военного и эти навыки обнуляются
Если отключить электричество то и у человеков будут проблемы с доставкой контента. А когда они пересядут за холст и масло, то при включении электричества будут проблемы.
Программку писать не надо, если метрика годная, то уже должна быть. Для Питона есть.
Это я ещё раз повторяю мысль, что сложность восприятия человеком кода является субъективной характеристикой.
Вполне можно. Вложенные условия будут сложней плоских условий. Одна функция на 1000 строк сложнее десяти по сто. Ну и по ней не читаемость оценивают, а потенциально проблемные места: метод или функцию.
Мы точно говорим про автоматический запуск тестов на CI на каждый pull request?
Автор решал проблему именно эту проблему.
То никаких проблем собрал release notes,
Выглядит так, как будто у вас есть релизы и вы гоняет тесты перед датой релиза. Это проигрышная стратегия для бизнеса. Хорошо когда CICD и между началом работы и деплоем в прод происходит пара часов. Это правда будет подороже создания хороших тестсьютов.
Чистый код он действительно не про производительность. На моей практике правда оптимизации делались через алгоритмы. Заинлайнить всё в одну функцию не поможет сильно, да и компиляторы это сами делают в некоторых языках.
Если слеплено в виде простой последовательности операций, без возвратов назад и без лишних зависимостей по локальным переменным - ни разу не усложняет, а наоборот.
К сожалению такой код встречается не так часто как бы хотелось. После пару-тройку изменений, которые делаются в спешке или людьми других взглядов, код имеет тенденцию превращаться в лапшу.
Мне кажется мы о разном говорим. Поддержание тестов в актуальном состоянии и выбор какие именно тесты запустить на каждом изменении это две разные задачи, да у них есть некоторая похожесть.
Логику по выбору тестов которые запустить на ревью нужно написать и её нужно поддерживать. И я утверждаю, что это - сложная задача. Что-то можно сделать через юниты и тесты контрактов на уровне модуля. Можно построить граф зависимостей по коду и тестировать связанные модули (все тесты для этих модулей). Но кроме этого могут быть зависимости через базу/очереди.
Разработка сложных проектов требует практик: Менять интерфейсы между модулями только осмысленно, выкидывать не используемый код.
Когда набераешь текст, то можно и не переносить. С появление выравнивания по ширине это даже выглядит норм.
Cпецифика фрацузского, что там надо знать следующее слово, чтобы произнести текущее и даже переносы отдельных слов путают. Если бы переносили предложения только по ритмическим группам, было бы удобнее.
> Если команды не знают свой продукт и не понимают к чему приведут их изменения, то грош им цена.
А какая у вас позиция в компании и какого размера проект (в количестве работающих над ним людей)?
С тем чтобы запускать только нужные тесты, я не спорю.
Я просто не знаю инструментов, которые смогут тесты разделить правильно. А чтобы это делать на уровне людей, нужно чтобы все писатели тестов хорошо знали всю систему и последние изменения в ней.
Стоимость для бизнеса складывается из затрат на поддержание какие тесты запускать при изменениях и пропущенные ошибки из-за того, что нужные тесты не запустили раньше.
Все эти тест-сьюты они критичны для ручного тестирования, потом, что оно не масштабируется. Для авто тестов можно достаточно быстро добавить железа.
Просто ускорить тесты намного проще. Это можно сделать один раз. При этом это может сделать даже человек, который не имеет глубоких знаний в бизнес логике и архитектуре этого проекта. Например человек который только пришёл на проект, как автор поста.
Не надо говорить за всех, говорите за себя и свою копанию. Есть много примеров когда компании вышли за пределы. И еще больше людей которые создали компании уже за пределами.
Вы будете себя вести лучше, чем до этого.
У класса нет ни одного не статического публичного метода. Как его будет использовать разные потоки?
Творить можно и без, но как вы монетизировать будете?
Если отключить электричество то и у человеков будут проблемы с доставкой контента. А когда они пересядут за холст и масло, то при включении электричества будут проблемы.
Программку писать не надо, если метрика годная, то уже должна быть. Для Питона есть.
Вполне можно. Вложенные условия будут сложней плоских условий. Одна функция на 1000 строк сложнее десяти по сто. Ну и по ней не читаемость оценивают, а потенциально проблемные места: метод или функцию.
Мы точно говорим про автоматический запуск тестов на CI на каждый pull request?
Автор решал проблему именно эту проблему.
Выглядит так, как будто у вас есть релизы и вы гоняет тесты перед датой релиза. Это проигрышная стратегия для бизнеса. Хорошо когда CICD и между началом работы и деплоем в прод происходит пара часов. Это правда будет подороже создания хороших тестсьютов.
Кажется, что вы применили подход не к месту, получили проблем от этого и поставили крест на технологии. Не надо так.
Мы вообще должны дискутировать про рефакторинг, а не уточнять требование к задаче поставленной не нам.
Чистый код он действительно не про производительность. На моей практике правда оптимизации делались через алгоритмы. Заинлайнить всё в одну функцию не поможет сильно, да и компиляторы это сами делают в некоторых языках.
Java хоронят каждый год. Питон ругают.
Про го давно не видел, может дженерики завезли?
Rust неплохо решает проблемы зависимостей для Питона. На нем пишут модули для которых нет зависимостей.
Автор в критикует пример, но не всю книгу.
Я видел код джунов, читайте, не бойтесь. Читайте разное. Пробуйте, анализируйте результат.
Солид забыли. И серию язык плохой/скоро умрёт.
К сожалению такой код встречается не так часто как бы хотелось. После пару-тройку изменений, которые делаются в спешке или людьми других взглядов, код имеет тенденцию превращаться в лапшу.
Гляньте на https://github.com/python/typeshed , там есть типизация для библиотек в которых типы не добавлены авторами.
Дело не в языке, а в специализированных библиотеках. R постарше и в своё время обходил Питон и по статистике и по биологии. Как сейчас не знаю.