![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassПо мотивам предыдущего поста про 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летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-09-25 09:47 am (UTC)2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.
Эти два пункта есть, TDD нет :)
Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд.
UI тяжело, да. Особенно если глаза замылены и этот интерфейс уже 5 год видишь.
no subject
Date: 2012-09-25 09:49 am (UTC)и
"Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд."
Нет ли здесь взаимоисключающих параграфов?
no subject
Date: 2012-09-25 09:56 am (UTC)У меня архитектура изначально проектировалась из соображения "должна проверятся из консольной проги в три строчки".
no subject
Date: 2012-09-25 10:06 am (UTC)no subject
Date: 2012-09-25 10:23 am (UTC)Отвязываться от БД в моем случае - более чем бесполезное занятие.
Возможно, сменить БД на другую, добавив в кодогенератор ее поддержку - ок.
Возможно, некоторые подсистемы, не совсем адекватно ложащиеся на RDBMS (сложные графы+иммутабельность+версионность), придется из нее выселять. Но результатом все равно будет очередной колхоз с функциональщиной для запросов.
no subject
Date: 2012-09-25 10:33 am (UTC)no subject
Date: 2012-09-25 10:42 am (UTC)no subject
Date: 2012-09-25 10:43 am (UTC)no subject
Date: 2012-09-25 10:45 am (UTC)no subject
Date: 2012-09-25 11:02 am (UTC)no subject
Date: 2012-09-25 12:04 pm (UTC)Неужели жалеть каких-то там N kбаксов на хорошую, работающую вещь?
no subject
Date: 2012-09-25 12:12 pm (UTC)no subject
Date: 2012-09-25 12:23 pm (UTC)no subject
Date: 2012-09-25 11:01 am (UTC)Зачем это?
no subject
Date: 2012-09-25 12:07 pm (UTC)О прагматичном программировании чел и не слышал.
Что реальность -- она чтой-то совсем не такая как в разноцветных книжечках описана.
no subject
Date: 2012-09-25 06:38 pm (UTC)no subject
Date: 2012-09-26 07:02 am (UTC)что прагматичность бывает разная. ;)
Вот у вас, "прагматичность" какой системы? :)
no subject
Date: 2012-09-26 07:12 am (UTC)no subject
Date: 2012-09-25 11:17 am (UTC)no subject
Date: 2012-09-25 11:27 am (UTC)no subject
Date: 2012-09-25 05:57 pm (UTC)no subject
Date: 2012-09-26 02:12 am (UTC)no subject
Date: 2012-09-25 11:31 am (UTC)no subject
Date: 2012-09-25 06:38 pm (UTC)