![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
О TDD, ретроградстве и варении в собственном соку
По мотивам предыдущего поста про taucraft: решарпер там или не решарпер, но Test-Driven-Development штука (вроде бы) объективно полезная.
При этом я почти уверен, что я TDD не использую, т.к. уже 15 лет занимаюсь всякой хренью в экстренном темпе, тесты у меня все заключаются в "проверить 10 раз чтобы миграция 30 Гб БД прошла успешно" и "отчетность видна от имени пользователя, который ей будет пользоваться".
Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии, наличия нескольких путей расчета одной и той же цифры и статических гарантий (т.е., например, я никогда не стану делать отчет отдельными запросами по списку аналитических кодов, если его можно сделать одним select/group by, при этом в него нужная аналитика попадет гарантированно). Плюс функциональщина, статические типы, кодогенерация - ну невозможно ошибится в коде, если у тебя источник информации для кода всегда один. А ошибки вида "не так спроектировали" - тестами не лечатся.
Еще я не использую разного рода современные инструменты, версии студии меняю через 2-3 года после их выхода, склонен использовать самодельные компоненты вместо готовых и вообще страдаю ретроградством.
Проблема в том, что у меня совершенно нет критериев оценки, где я прав и пропускаю ненужные buzz-words мимо ушей, а где не прав, и упускаю полезные инструменты. Потому что на всех работах инструменты/платформы/методики работы выбираю я и обсудить этот выбор на адекватном уровне не с кем.
Раньше хотя бы был вменяемый критерий "успеем проект сдать вовремя или не сделаем вообще", а сейчас и он смысл потерял - это вообще перестало зависеть от используемых технологий, а стало зависеть от наличия бабла у клиентов и правильной организации труда.
Т.е. та же проблема, что в любых НИИГиТ - сидит 50летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.
При этом я почти уверен, что я TDD не использую, т.к. уже 15 лет занимаюсь всякой хренью в экстренном темпе, тесты у меня все заключаются в "проверить 10 раз чтобы миграция 30 Гб БД прошла успешно" и "отчетность видна от имени пользователя, который ей будет пользоваться".
Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии, наличия нескольких путей расчета одной и той же цифры и статических гарантий (т.е., например, я никогда не стану делать отчет отдельными запросами по списку аналитических кодов, если его можно сделать одним select/group by, при этом в него нужная аналитика попадет гарантированно). Плюс функциональщина, статические типы, кодогенерация - ну невозможно ошибится в коде, если у тебя источник информации для кода всегда один. А ошибки вида "не так спроектировали" - тестами не лечатся.
Еще я не использую разного рода современные инструменты, версии студии меняю через 2-3 года после их выхода, склонен использовать самодельные компоненты вместо готовых и вообще страдаю ретроградством.
Проблема в том, что у меня совершенно нет критериев оценки, где я прав и пропускаю ненужные buzz-words мимо ушей, а где не прав, и упускаю полезные инструменты. Потому что на всех работах инструменты/платформы/методики работы выбираю я и обсудить этот выбор на адекватном уровне не с кем.
Раньше хотя бы был вменяемый критерий "успеем проект сдать вовремя или не сделаем вообще", а сейчас и он смысл потерял - это вообще перестало зависеть от используемых технологий, а стало зависеть от наличия бабла у клиентов и правильной организации труда.
Т.е. та же проблема, что в любых НИИГиТ - сидит 50летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.
no subject
no subject
Но как эту закономерность выразить, не влезая в специфику, я не знаю...
Ну, естественно, что начинали без маньячения, без желания доказать всё-всё и больше никак.
В первую очередь, что было попроще, и постепенно, всё больше доказательств стало получаться записать относительно сходу.
Ну и, понятное дело, что доказательство, это тоже код на функциональном языке.
И его тоже можно (и нужно!) делать модульным.
no subject
no subject
no subject
TEST_NOTNULL(f(a1)) для граничного а1
...
TEST_NOTNULL(f(an)) для граничного an
что-типа
PROVE_NOTNULL(f(x)) для любого х из области определения f
(ваш КО)
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
> И его тоже можно (и нужно!) делать модульным.
Возникает резонный вопрос: надо ли тестировать код доказательства? Или доказывать корректность доказательства? :)
А если серьезно - очень хотелось бы увидеть примеров в коде. Как тесты заменяются доказательствами. Пусть даже даже примеры будут синтетическими.
no subject
Да, вопрос вполне резонный. Мы пока этого почти не делали.
А при чём-то очень большом, может быть, что и потребуется.
И долго спорили, можно ли сделать пирамиду таких доказательств (то есть, чтобы спецификация на спецификацию была короче спецификации)...
> Как тесты заменяются доказательствами.
> Пусть даже даже примеры будут синтетическими.
Нублин, ребята — осваивайте да сами смотрите...
Либо какие-то из открытых проектов можно посмотреть.
no subject
берите пример с Вирта ;)
no subject
no subject
а вот чтобы от года к году они были всё короче и короче - это он даёт хорошие примеры :)
no subject
Вот если бы от дня к дню — тогда было бы хорошо.
no subject
no subject
Но доля правды в этом есть — надо таки стремиться к бОльшей технологичности этого процесса.
no subject
no subject
А вы про что подумали?
no subject