AV
Вообще зависит от того, что за проект, если это штука, которая будет опущена в бункер под океаном без доступа; или это сервис, который постоянно развивается
Size: a a a
2020 August 28
AV
Зависит от сложности, изменчивости и т.п.
ЕХ
Вообще зависит от того, что за проект, если это штука, которая будет опущена в бункер под океаном без доступа; или это сервис, который постоянно развивается
Вот-вот, или Боинг 747 Макс...
AV
Из хаскелистов я видел тех, кто пытался верифицировать что-то честно только блокчейнеров
AV
В одной компании делали модельки на spin/promela. В другой заделали свой язык и библиотеку, и кодировали правила вывода из спеки, на основе которых генерировались тесты, и которые проверяли, что то, что происходит действительно верно
AV
Мы когда делали consensus, для управления кластером тоже делали верификацию (это можно верификацией называть?) на spin/promela, но там были именно модели и только для реально опасных мест
A
Вот-вот, или Боинг 747 Макс...
там как раз покрытие кода тестами было хорошее, устные договоренности тоже были, все старались..
A
Да у меня есть приложулька на JS с 0 тестов, не говоря уже про типы или верификацию – и ничего, работает, багов почти и не выявляется (в продакшене), пользу людям приносит.
примерно такое и у меня есть 😊
K
А можно не абстрактную теорию обсуждать, а практику?
Я хочу в clojure/script сделать что-то вроде интерпретатора эффектов.
Т.е. разделить логику от интерпретации эффектов.
Если кому haskell ближе, то это free monad.
Если кому ближе js, то это генераторы.
У меня есть вопросы и рассуждения, они вот тут.
https://gist.github.com/darkleaf/f0cbfe38eaad82cb44758aef1228287f
Собственно там первая ссылка на уже существующую мою библиотеку
и там есть rationale https://github.com/darkleaf/effect/blob/doc-2/README.md#rationale
Я хочу в clojure/script сделать что-то вроде интерпретатора эффектов.
Т.е. разделить логику от интерпретации эффектов.
Если кому haskell ближе, то это free monad.
Если кому ближе js, то это генераторы.
У меня есть вопросы и рассуждения, они вот тут.
https://gist.github.com/darkleaf/f0cbfe38eaad82cb44758aef1228287f
Собственно там первая ссылка на уже существующую мою библиотеку
и там есть rationale https://github.com/darkleaf/effect/blob/doc-2/README.md#rationale
Я бы параметризовал всё объектом, методы которого являются реализациями. Вот только делать ностоящую монаду в кложе не стоит. А без настоящий монады, все функции, вызывающие компоненты, будут иметь этот объект параметром.
ЕХ
там как раз покрытие кода тестами было хорошее, устные договоренности тоже были, все старались..
Неужели они поэтому и стали пачками падать?! Ох, уж эти индусы...
AT
ну т.е. я никак не пойму, где формальная та граница между тестами и верификацией, чтобы точно сказать, что тут выгоднее тесты, а тут верификацию.
так как сам не пишу ни тесты, ни уж тем более верификацию!
так как сам не пишу ни тесты, ни уж тем более верификацию!
Тесты и верификация в некотором смысле дуальны: тесты выявляют наличие ошибок, верификация доказывает отсутствие ошибок в заданных рамках.
Тесты обычно могут выразить больший спектр свойств (в особенности, нефункциональных) и их как правило проще написать. Но, соответственно, меньше гарантий.
С обратной стороны на cost-benefit curve влияет сложность кода. Простой код проще верифицировать, чем исчерпывающе протестировать. Сложный код хрен специфицируешь, не говоря уже про верификацию.
Тесты обычно могут выразить больший спектр свойств (в особенности, нефункциональных) и их как правило проще написать. Но, соответственно, меньше гарантий.
С обратной стороны на cost-benefit curve влияет сложность кода. Простой код проще верифицировать, чем исчерпывающе протестировать. Сложный код хрен специфицируешь, не говоря уже про верификацию.
MK
Я бы параметризовал всё объектом, методы которого являются реализациями. Вот только делать ностоящую монаду в кложе не стоит. А без настоящий монады, все функции, вызывающие компоненты, будут иметь этот объект параметром.
Если бы ты посотреть материалы, то такого вопроса бы не было.
Там речь о том, что я хочу писать один код для платформы как с блокирующим, так и не блокирующим вводом-выводом.
Там речь о том, что я хочу писать один код для платформы как с блокирующим, так и не блокирующим вводом-выводом.
A
Неужели они поэтому и стали пачками падать?! Ох, уж эти индусы...
часть отдавали на аутсорсинг в CIS регион, причем не делясь знаниями/спецификациями
MK
и простая dependency injection тут не работает
MK
и простая dependency injection тут не работает
https://blog.ploeh.dk/2017/02/02/dependency-rejection/
вот тут наглядно объясняют почему так
вот тут наглядно объясняют почему так
ЕХ
часть отдавали на аутсорсинг в CIS регион, причем не делясь знаниями/спецификациями
Так инженеров же ж посокращали, вот и некому было делиться.
A
Тесты и верификация в некотором смысле дуальны: тесты выявляют наличие ошибок, верификация доказывает отсутствие ошибок в заданных рамках.
Тесты обычно могут выразить больший спектр свойств (в особенности, нефункциональных) и их как правило проще написать. Но, соответственно, меньше гарантий.
С обратной стороны на cost-benefit curve влияет сложность кода. Простой код проще верифицировать, чем исчерпывающе протестировать. Сложный код хрен специфицируешь, не говоря уже про верификацию.
Тесты обычно могут выразить больший спектр свойств (в особенности, нефункциональных) и их как правило проще написать. Но, соответственно, меньше гарантий.
С обратной стороны на cost-benefit curve влияет сложность кода. Простой код проще верифицировать, чем исчерпывающе протестировать. Сложный код хрен специфицируешь, не говоря уже про верификацию.
это очевидно мне минимум из сегодняшней дискуссии. мне казалось, что @graninas не понимает этого, но теперь вижу, что понимает, но нарочно троллит, т.к. защищает тесты через нападение на верификацию. @GabrielFallen тактично защищаете подход, который вам ближе.
ЕХ
Мы когда делали consensus, для управления кластером тоже делали верификацию (это можно верификацией называть?) на spin/promela, но там были именно модели и только для реально опасных мест
Моделирование - сила! Но ещё не познанная!
AT
это очевидно мне минимум из сегодняшней дискуссии. мне казалось, что @graninas не понимает этого, но теперь вижу, что понимает, но нарочно троллит, т.к. защищает тесты через нападение на верификацию. @GabrielFallen тактично защищаете подход, который вам ближе.
Я уже всосал литр IPA, так что я ХЗ что я тут делаю... 😂