О TDD, ретроградстве и варении в собственном соку

[metaclass]

По мотивам предыдущего поста про taucraft: решарпер там или не решарпер, но Test-Driven-Development штука (вроде бы) объективно полезная.

При этом я почти уверен, что я TDD не использую, т.к. уже 15 лет занимаюсь всякой хренью в экстренном темпе, тесты у меня все заключаются в "проверить 10 раз чтобы миграция 30 Гб БД прошла успешно" и "отчетность видна от имени пользователя, который ей будет пользоваться".

Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии, наличия нескольких путей расчета одной и той же цифры и статических гарантий (т.е., например, я никогда не стану делать отчет отдельными запросами по списку аналитических кодов, если его можно сделать одним select/group by, при этом в него нужная аналитика попадет гарантированно). Плюс функциональщина, статические типы, кодогенерация - ну невозможно ошибится в коде, если у тебя источник информации для кода всегда один. А ошибки вида "не так спроектировали" - тестами не лечатся.

Еще я не использую разного рода современные инструменты, версии студии меняю через 2-3 года после их выхода, склонен использовать самодельные компоненты вместо готовых и вообще страдаю ретроградством.

Проблема в том, что у меня совершенно нет критериев оценки, где я прав и пропускаю ненужные buzz-words мимо ушей, а где не прав, и упускаю полезные инструменты. Потому что на всех работах инструменты/платформы/методики работы выбираю я и обсудить этот выбор на адекватном уровне не с кем.
Раньше хотя бы был вменяемый критерий "успеем проект сдать вовремя или не сделаем вообще", а сейчас и он смысл потерял - это вообще перестало зависеть от используемых технологий, а стало зависеть от наличия бабла у клиентов и правильной организации труда.

Т.е. та же проблема, что в любых НИИГиТ - сидит 50летний мега-гуру, всю жизнь варившийся в собственном соку, который уже не в состоянии различить, где бессмысленная гонка за новизной или просто неподходящая технология, а где реально нужно отрывать жопу от стула и менять себе мозг.

Comments

[raydac.livejournal.com]

имхо TDD штука хорошая но надо ряд условий
- заказчик знает что хочет
- у заказчика полно бабла
- у заказчика полно времени
- есть разработанная устойчивая архитектура

[metaclass.livejournal.com]

Хм, у меня ни одно из условий не выполнено, за исключением последнего, разве что.

[vit-r.livejournal.com]

Ха. При таких условиях чего угодно работать будет. Особенно, если выполнено первое.

[besm6.livejournal.com]

Надо сказать, современные TDD фреймворки как раз замечательно упускают тестирование апгрейда с одного релиза на другой и тестирование ошибок в миграции реальных БД :) Я тут это некоторое время назад в количестве пронаблюдал на рельсах. В общем, разработчик даже пишет тесты. И они даже в 30% случаев тестируют то, что надо (в остальных 70 - то, что получилось, т.е. при смене требований их все надо переписывать). И с завидной регулярностью валится (или хуже того, проходит с неверным результатом) миграция БД. Потому как ORM во время миграции - штука не просто тонкая, а ОЧЕНЬ тонкая, а фреймворка тестов на это никто не придумал.

В общем, доказательство программ порой оказывается не только надежнее, но и дешевле :)

А вот работа в паре (и ряд других техник из баззворда "XP") - штука весьма полезная, но где ж ты себе пару найдешь?

[metaclass.livejournal.com]

Работа в паре у нас как раз есть, когда над одним проектом работаем, а не над 4 разными сразу :)

[blackyblack.livejournal.com]

"Правильность же реализации/рефакторинга/замены всего с нуля проверяется за счет двойной записи бухгалтерии"
Очень весело тестировать новую фичу при помощи бухгалтеров.

TDD позволяет делать две важные вещи:
1. Фиксирует требования в виде достаточно простого кода (тестов).
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.

Я тоже раньше думал, что раз ФП, то и тесты писать не нужно. Но один раз написал и вскоре обнаружил багу, а дальше рефакторинг попёр как по рельсам. С TDD исчёзает масса отвлекающих факторов: архитектура уже готова для тестирования, следовательно и для добавления новых фич; не нужно думать о связанных системах при курочении кода.

Да, тестируется далеко не всё. Тестируются форматы данных, логика приложения. UI, базы данных, сетевые сервисы фактически не тестируются. И тем не менее, и здесь TDD будет полезен тем, что вытащит всё это говно за пределы логики ПО.

[metaclass.livejournal.com]

1. Фиксирует требования в виде достаточно простого кода (тестов).
2. Требует программиста переработать архитектуру для тестируемости. Для ФП не так актуально, но тоже достаточно ценно.

Эти два пункта есть, TDD нет :)

Базы данных кстати, тестируются. Я каждый раз для тестов запускаю автоматическую генерилку данных и далее паралллельно заполняю ей БД и выполняю по БД расчеты-аналитику-тесты бизнес логики итд.

UI тяжело, да. Особенно если глаза замылены и этот интерфейс уже 5 год видишь.

[prote-je-moi.livejournal.com]

святые угоднікі.

[metaclass.livejournal.com]

Перевожу на русский:
"как силами одного необученного, но с врожденной грамотностью, журналиста без редакторов, полиграфии и рекламы выпустить одновременно глянцевый журнал, газету для домохозяек и серьезное аналитическое издание и при этом не сойти нахер с ума" :)

[besm6.livejournal.com]

И кстати, может, я слышу меньше баззвордов, но те, что я слышу - они в основном как раз о технологиях правильной организации труда, а не об инcтрументах. Вопрос, конечно, насколько они действительно эффективны, а насколько - чистый базз...

[bydlorus.livejournal.com]

Программисты в собственном соку:

[nivanych.livejournal.com]

Ready Teddy Programmer

[jakobz.livejournal.com]

Ну, перегибать палку, конечно, не стоит. Я тесты где-то пишу, где-то нет. До или после написания кода - тоже по вкусу. Для меня повод написать тест - это или если видишь что руками проверять будет геморнее, или если есть неиллюзорный шанс что кто-то что-то по непониманию поломает.

[dr-hyder.livejournal.com]

Ну TDD хотят писать функциональные тесты перед кодом, не юнит-тесты. Имхо писать функциональные тесты перед кодом в некоторых ситуациях имеет смысл а в некоторых не имеет, это не важно. Смысл в том что они не говорят писать ВСЕ тесты перед кодом.

[gineer.livejournal.com]

"“Всюду в процессе перевода Windows в защищенный режим какие-то ошметки, но в основном вы так и работаете закрываете глаза, и вперед! Вы не думаете о предстоящих проблемах, либо ны так ничего и не сделаете. Так, шаг за шагом, дело движется. Вот, есть уже драйверы клавиатуры, есть драйверы дисплея, на подходе графический интерфейс — ух, ты, да это же USER!”"

http://www.strana-pc.ru/content/1777

[vit-r.livejournal.com]

А ошибки вида "не так спроектировали" - тестами не лечатся.

Лечатся. Для этого надо систему тестов разрабатывать отдельной головой.

Насчёт же новизны. В нормальных командах любые технологии не берутся, а адаптируются. При этом часто, вутри уже существует аналог чего-то "модного", но без волшебного названия.

[migmit.livejournal.com]

Гм. У меня, как у любого (почти) мужчины, вторая голова, конечно, есть. Но крови хватает только на одну.

[guamoka.livejournal.com]

Лечатся. Для этого надо систему тестов разрабатывать отдельной головой

Главное, головой. А отдельной или нет- дело десятое.

[hshhhhh.livejournal.com]

В тестах меня смущает то что даже на самую тупую функцию которая складывает два числа можно придумать такое дикое колличество ситуаций которые ОЧЕНЬ НАДО проверить что пока их напишешь -- сойдешь с ума. А потом надо складывать три числа...

Я тесты могу рассматривать только с точки зрения "я написал тесты и они проверяют что в общем случае от того что я поменял кусок кода в одном месте в другом _вроде_как_ все продолжает работать". Но непонятно.

[metaclass.livejournal.com]

В общем, там можно избежать комбинаторного взрыва.
Во-первых - элементарные функции тестировать юнит-тестами и рандомно - чтобы они в области определения вели себя хорошо, ошибались предсказуемо и падали с красивыми исключениями либо не падали вообще (пока память не битая и проц на месте).
Во-вторых - архитектура должна быть такой, чтобы комбинирование функций не влияло на них по отдельности никак. Т.е. не должно быть такого, что + в одном вызове работает хорошо, в другом плохо (такое есть на уровне проца и контрольных слов FPU кстати :)). В коде не должно быть неконтролируемых зависимостей.
В третьих - ошибки вида "в десяти разных местах сошлись нехорошо звезды и все ебнулось" крайне редки, обычно совершаются ошибки вида "обработка ошибок сделана через задницу" и "забыли инициализировать переменную".
Это все лечится нормальными системами типов (либо их имитацией на языках, где это невозможно).

[nivanych.livejournal.com]

Интересно, а вот как бы выглядело "TDD" на агдочке, где вместо тестов — доказательства?

[gineer.livejournal.com]

Дык... запили. :)

[guamoka.livejournal.com]

Знаете ребе, у меня из головы всё не выходит случай, когда мне спустили достаточно такое ёмкое задание, я его наклепал, обернул этими самыми тестами, а потом мне заявили, "ой, а мы нафиг перепутали все таблицы, надо было взять совсем другие и сделать всё совсем по-другому". Т.е., фактически оказалось, что можно было результат двухдневной работы и сотни строк разношерстного кода взять и спустить в унитаз. Я и раньше-то понимал вторичность всей этой лабуды с тестами, что ничего ими не исправишь, если не под фонарем искать, но этот случай меня окончательно как-то добил.

[metaclass.livejournal.com]

Это совсем уже предельный случай. Обычно тесты чуть-чуть полезны, если код не совсем тривиальный и будет использоваться и дорабатываться.

И да, у меня рефакторинг часто сводится к "выкинуть все и сделать правильно", т.к. починка существующего кода - это как кровати в борделе переставлять.

[gineer.livejournal.com]

Классика
http://www.joelonsoftware.com/items/2009/09/23.html

[rashid80.livejournal.com]

ребе, а вы не путаете TDD с просто с написанием Unit test'ов?
TDD - это такой вид маразма, когда кода еще нет, а тесты уже есть, есть дохера времени и дури в голове.

[metaclass.livejournal.com]

Похоже, что путаю, да.

[rashid80.livejournal.com]

В опердени действительно многое можно проверить путем формирования некоего (бухгалтерского) баланса, до и после рефакторинга (на копиях систем). За выборочные даты.

[metaclass.livejournal.com]

Да, элемент халявы имеется - юнит-тесты за нас пишут бухгалтера и законодательство :)