В статье стоило уточнить, что речь именно про второе. Код библиотек нуждается в сильно более полном покрытии тестами. Если кто-то поверит статье и протестирует библиотеку по принципу «нет смысла покрывать юнит-тестами тривиальный код», он с крайне высокой вероятностью столкнется с проблемами в будущем.
Также не совсем ясно, зачем автор вводит новую терминологию, вроде «общительных» тестов. Чем не устраивают классические e2e-тесты?
Ну и в статье из рубрики «как тестировать» я бы ожидал увидеть больше «мяса»: какие бывают метрики тестирования, как писать тестируемый код и так далее.
Если уж рекламируете свои сервера с почасовой оплатой, показали бы, как поднимать такой сервер через API из кода, чтобы не тыкать ручками в интерфейсе, а делать все программно по потребности.
WUJI полноценно исполняет стандартные 32-битные инструкции RISC-V, корректно выполняет арифметические операции с числами до 4,2 миллиарда и поддерживает адресацию гигабайтных объемов данных
Разве тут не написано 3 раза одно и то же?
Ну и по статье я так и не понял, чем же эти новые процессоры лучше старых, хотя бы в перспективе и в теории.
Конкретное хорошее соотношение кода и тестов очень сильно зависит от области, обычно это чет типа интуиции, которая постепенно вырабатывается, и 1 к 5 - это моя личная интуиция, ниже этих цифр по моему опыту код был явно ненадежным и часто стрелял. Возможно, для около-математического кода она была бы немного иной. В этой области вообще нет четких ответов, многое до сих пор опирается на интуитивные суждения.
Метрики типа покрытия (кстати, настоятельно рекомендую помимо обычного покрытия считать также покрытие "по бранчам", т.е. с автоматической проверкой, что обе ветки любого условия были протестированы) хороши только в качестве нижней планки. Лично у меня для библиотек включен трэшхолд в 100% покрытия по строкам и бранчам, на 99% и ниже просто CI не пройдет. Но это именно нижняя планка, 100% легко достичь, ничего на самом деле не протестировав, поэтому приходится иметь дополнительные интуиции, указывающие на возможные проблемы.
Из более интересных метрик могу посоветовать попробовать мутационное тестирование, возможно вам зайдет, раз вы интересуетесь эволюционными алгоритмами :) Возможно, получится разово словить какие-то инсайты от запуска mutmut, хотя готового прям к повседневному исследованию тулинга в этой области для Python пока нет (но я прямо сейчас работаю над этим). В целом это полезная штука, когда покрытие уже 100%, и все очевидные идеи, что можно протестировать, уже исчерпаны.
13 000 строк Python, из которых большая часть — основной функционал, а четверть — тесты
Это ужасное соотношение, библиотеку вряд ли можно назвать протестированной. Обычно хорошее соотношение кода к тестам начинается где-то от 1 к 5, т.е. в данном случае нужно примерно в 20 раз больше тестов.
У нейросетей нет кнопочек. Вы использовали какое-то странное приложение для инференса, прибитое гвоздями, как я понял, к какой-то модели. Используйте другое приложение для выбранной модели.
В начале войны я был более оптимистичен. Я предполагал, что будут проблемы с поставками железа, и думал, что это мотивирует вкладываться в бережливую разработку, спровоцирует интерес к более вычислительно эффективным системам/алгоритмам/языкам, повысит культуру перфоманса и качества ПО, побудит к хитрым оптимизациям вроде той, где дипсик в умудрился в 10 раз удешевить инференс на видеокартах. То есть я думал, что мы закроем дефицит железа интеллектом. По факту кое-где сейчас это и правда так, но, кажется, основной эффект противоположный: компании стали экономить на разработчиках, а продолжающие расти расходы перекладываются на потребителя, разгоняя инфляцию.
А где технические подробности? Что улетает в контекст для LLMки, используются ли RAGи, и если да, то как для них нарезается исходный код? Как подбирались промпты, и какие они сейчас? Есть ли ограничения по языкам программирования?
Локальный запуск LLM для ревью прямо внутри раннера гитхаба — мечта.
А где технические детали решения? Где там какие RAGи под капотом, что подавали в контекст нейронке, какую нейронку выбрали и через какого провайдера подключали (а может на локальной все собрали?), какие промпты использовали? Почему не использовали одно из готовых решений?
Прежде всего, тесты бывают 2 видов:
Для переиспользуемого кода (библиотек, например)
Для «одноразового» кода (веб-сервисы и подобное)
В статье стоило уточнить, что речь именно про второе. Код библиотек нуждается в сильно более полном покрытии тестами. Если кто-то поверит статье и протестирует библиотеку по принципу «нет смысла покрывать юнит-тестами тривиальный код», он с крайне высокой вероятностью столкнется с проблемами в будущем.
Также не совсем ясно, зачем автор вводит новую терминологию, вроде «общительных» тестов. Чем не устраивают классические e2e-тесты?
Ну и в статье из рубрики «как тестировать» я бы ожидал увидеть больше «мяса»: какие бывают метрики тестирования, как писать тестируемый код и так далее.
Вроде что-то прочитал, а вроде и вода-водой.
возможно мы в пузыре пузырей
Если уж рекламируете свои сервера с почасовой оплатой, показали бы, как поднимать такой сервер через API из кода, чтобы не тыкать ручками в интерфейсе, а делать все программно по потребности.
Разве тут не написано 3 раза одно и то же?
Ну и по статье я так и не понял, чем же эти новые процессоры лучше старых, хотя бы в перспективе и в теории.
Mermaid умеет рендериться только на десктопном гитхабе. Гитхаб-мобайл не умеет отображать эти схемы.
На малинах будет работать?
Надпись "Как мы делаем Яндекс" под этой статьей особенно символична.
Проект выглядит охренительно, жаль я вообще из другой области, но звездочку занес.
А ссылки где?
Куда уж базированнее то?
По Numba-коду тоже можно считать покрытие.
Конкретное хорошее соотношение кода и тестов очень сильно зависит от области, обычно это чет типа интуиции, которая постепенно вырабатывается, и 1 к 5 - это моя личная интуиция, ниже этих цифр по моему опыту код был явно ненадежным и часто стрелял. Возможно, для около-математического кода она была бы немного иной. В этой области вообще нет четких ответов, многое до сих пор опирается на интуитивные суждения.
Метрики типа покрытия (кстати, настоятельно рекомендую помимо обычного покрытия считать также покрытие "по бранчам", т.е. с автоматической проверкой, что обе ветки любого условия были протестированы) хороши только в качестве нижней планки. Лично у меня для библиотек включен трэшхолд в 100% покрытия по строкам и бранчам, на 99% и ниже просто CI не пройдет. Но это именно нижняя планка, 100% легко достичь, ничего на самом деле не протестировав, поэтому приходится иметь дополнительные интуиции, указывающие на возможные проблемы.
Из более интересных метрик могу посоветовать попробовать мутационное тестирование, возможно вам зайдет, раз вы интересуетесь эволюционными алгоритмами :) Возможно, получится разово словить какие-то инсайты от запуска mutmut, хотя готового прям к повседневному исследованию тулинга в этой области для Python пока нет (но я прямо сейчас работаю над этим). В целом это полезная штука, когда покрытие уже 100%, и все очевидные идеи, что можно протестировать, уже исчерпаны.
Удачи с проектом!
Это ужасное соотношение, библиотеку вряд ли можно назвать протестированной. Обычно хорошее соотношение кода к тестам начинается где-то от 1 к 5, т.е. в данном случае нужно примерно в 20 раз больше тестов.
У нейросетей нет кнопочек. Вы использовали какое-то странное приложение для инференса, прибитое гвоздями, как я понял, к какой-то модели. Используйте другое приложение для выбранной модели.
Большинство сегодня пишет на мультипарадигменных языках, где подобной дихотомии просто нет.
В начале войны я был более оптимистичен. Я предполагал, что будут проблемы с поставками железа, и думал, что это мотивирует вкладываться в бережливую разработку, спровоцирует интерес к более вычислительно эффективным системам/алгоритмам/языкам, повысит культуру перфоманса и качества ПО, побудит к хитрым оптимизациям вроде той, где дипсик в умудрился в 10 раз удешевить инференс на видеокартах. То есть я думал, что мы закроем дефицит железа интеллектом. По факту кое-где сейчас это и правда так, но, кажется, основной эффект противоположный: компании стали экономить на разработчиках, а продолжающие расти расходы перекладываются на потребителя, разгоняя инфляцию.
А где технические подробности? Что улетает в контекст для LLMки, используются ли RAGи, и если да, то как для них нарезается исходный код? Как подбирались промпты, и какие они сейчас? Есть ли ограничения по языкам программирования?
Локальный запуск LLM для ревью прямо внутри раннера гитхаба — мечта.
А где технические детали решения? Где там какие RAGи под капотом, что подавали в контекст нейронке, какую нейронку выбрали и через какого провайдера подключали (а может на локальной все собрали?), какие промпты использовали? Почему не использовали одно из готовых решений?
Будто бы из разработчиков вряд ли кого-то интересуют виндо-проблемы, а сам редактор на сегодня топовый.
А где Zed?