![[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
Очень весело тестировать новую фичу при помощи бухгалтеров.
TDD позволяет делать две важные вещи:
1. Фиксирует требования в виде достаточно простого кода (тестов).
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.
Я тоже раньше думал, что раз ФП, то и тесты писать не нужно. Но один раз написал и вскоре обнаружил багу, а дальше рефакторинг попёр как по рельсам. С TDD исчёзает масса отвлекающих факторов: архитектура уже готова для тестирования, следовательно и для добавления новых фич; не нужно думать о связанных системах при курочении кода.
Да, тестируется далеко не всё. Тестируются форматы данных, логика приложения. UI, базы данных, сетевые сервисы фактически не тестируются. И тем не менее, и здесь TDD будет полезен тем, что вытащит всё это говно за пределы логики ПО.
no subject
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.
Эти два пункта есть, TDD нет :)
Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд.
UI тяжело, да. Особенно если глаза замылены и этот интерфейс уже 5 год видишь.
no subject
и
"Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд."
Нет ли здесь взаимоисключающих параграфов?
no subject
У меня архитектура изначально проектировалась из соображения "должна проверятся из консольной проги в три строчки".
no subject
no subject
Отвязываться от БД в моем случае - более чем бесполезное занятие.
Возможно, сменить БД на другую, добавив в кодогенератор ее поддержку - ок.
Возможно, некоторые подсистемы, не совсем адекватно ложащиеся на RDBMS (сложные графы+иммутабельность+версионность), придется из нее выселять. Но результатом все равно будет очередной колхоз с функциональщиной для запросов.
no subject
no subject
no subject
no subject
no subject
no subject
Неужели жалеть каких-то там N kбаксов на хорошую, работающую вещь?
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