О 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
(no subject)
(no subject)
(no subject)
(no subject)
no subject
В общем, доказательство программ порой оказывается не только надежнее, но и дешевле :)
А вот работа в паре (и ряд других техник из баззворда "XP") - штука весьма полезная, но где ж ты себе пару найдешь?
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Очень весело тестировать новую фичу при помощи бухгалтеров.
TDD позволяет делать две важные вещи:
1. Фиксирует требования в виде достаточно простого кода (тестов).
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.
Я тоже раньше думал, что раз ФП, то и тесты писать не нужно. Но один раз написал и вскоре обнаружил багу, а дальше рефакторинг попёр как по рельсам. С TDD исчёзает масса отвлекающих факторов: архитектура уже готова для тестирования, следовательно и для добавления новых фич; не нужно думать о связанных системах при курочении кода.
Да, тестируется далеко не всё. Тестируются форматы данных, логика приложения. UI, базы данных, сетевые сервисы фактически не тестируются. И тем не менее, и здесь TDD будет полезен тем, что вытащит всё это говно за пределы логики ПО.
no subject
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.
Эти два пункта есть, TDD нет :)
Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд.
UI тяжело, да. Особенно если глаза замылены и этот интерфейс уже 5 год видишь.
(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)
(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
http://www.strana-pc.ru/content/1777
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
Во-первых - элементарные функции тестировать юнит-тестами и рандомно - чтобы они в области определения вели себя хорошо, ошибались предсказуемо и падали с красивыми исключениями либо не падали вообще (пока память не битая и проц на месте).
Во-вторых - архитектура должна быть такой, чтобы комбинирование функций не влияло на них по отдельности никак. Т.е. не должно быть такого, что + в одном вызове работает хорошо, в другом плохо (такое есть на уровне проца и контрольных слов FPU кстати :)). В коде не должно быть неконтролируемых зависимостей.
В третьих - ошибки вида "в десяти разных местах сошлись нехорошо звезды и все ебнулось" крайне редки, обычно совершаются ошибки вида "обработка ошибок сделана через задницу" и "забыли инициализировать переменную".
Это все лечится нормальными системами типов (либо их имитацией на языках, где это невозможно).
(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)
(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)
(no subject)
(no subject)
no subject
no subject
И да, у меня рефакторинг часто сводится к "выкинуть все и сделать правильно", т.к. починка существующего кода - это как кровати в борделе переставлять.
(no subject)
(no subject)
no subject
http://www.joelonsoftware.com/items/2009/09/23.html
no subject
TDD - это такой вид маразма, когда кода еще нет, а тесты уже есть, есть дохера времени и дури в голове.
no subject
no subject
no subject