"Разработка через тестирование"?
Александр зимой презентовал мне "Разработку через тестирование". Хорошая, с чувством написанная, я перечитал её пару раз, наверное. Ну и так, акцидентально, обращаюсь. Уже несколько лет мы стараемся применять тесты для получения дополнительных гарантий качества кода и иногда это неплохо получается. Всё, что может помочь упростить код или уменьшить его количество - применяется. Тесты не исключение. Но поскольку много лет назад, как и многие другие, я прочитал Мифический человеко-месяц, а после него - "... Серебряную пулю", то верить в то, что тесты - это то самое я не мог. И не зря. На днях была выпущена большая новая версия: много нового кода, много исправлений, в том числе и базы данных. Перед выпуском всё проверялось и неоднократно. Код проверялся тестами, интерфейс - протыкиванием, обновления базы данных - нашими утилитами обновления рабочих баз. После сборки msi мы проверили и его(её?). Версия под панфары была отправлена по адресу.
Утро следующего дня началось с письма:
После загрузки последного обновления вся моя работа пропала. Что делать?Как она могла пропасть, если мы всё проверяли?! Правда, пользователь попался умный и не вредный - дал нашему автоматическому отчёту о сбое отправить состояние стека. 5 минут изучения, проверка обновления БД и вот: отсутствие обратной совместимости в очередном исправлении БД. У нас оно работало потому что база заполнялась-стиралась-заполнялась. Перед применением исправления она всякий раз оказывалась пустой и после того, как patcher её обновлял - программа работала как ни в чём не бывало. А у пользователя там были данные. Всё тоже обновилось, без ошибок, правильно. И умерло.
Первая мысль была - как бы это не повторить в будущем (базу товарищу мы вернули в нормальное состояние и с извинениями выслали обратно), а вторая - как ни старайся притянуть разработку через тестирование ко всему, во-первых, ничего не получится, а во-вторых, везде это не нужно. До сих пор пользовательский интерфейс проверяем на живых человеках и пока что альтернативы этому не видно.
6 комментариев:
Ну, разработка через тестирование - это механизм относительно безошибочного написания программного кода, основанный на фиксации требований к коду в программном же коде.
Беда с БД в том, что это не только программный код (ХП и функции можно, хотя и не так легко, тестировать в рамках TDD), но и структура данных и сами данные. А эти сущности, согласись, к процессу программирования имеют не так много отношения.
Еще один момент: если бы ты ставил перед собой задачу обратной совместимости, то соответствующий тест (в том или ином виде) был бы написан, но ты сам признаешь, что такая задача явно не ставилась и явно не контролировалась... А TDD работает таким образом, что учитывает только явно поставленные задачи.
Это не механизм. Это такая отвёртка, под которую в любом проекте есть процентов 40 шурупов. Причём, отвёртка сделанная очень весёлыми парнями: на ручке есть надпись - "Пилите, Шура, пилите! Они золотые!"
В итоге одновременно хочется крутить эти шурупы, смеяться, рыдать и выкинуть отвёртку к хуямЪ.
Ну перестань.
Если это отвертка - то ты прекрасно видишь, к каким шурупам она подходит, и нефиг ей гвозди заколачивать.
Просто и Кент, и Мартин по-правде не в курсе, что бывают еще и гвозди. Но согласись, TDD для шурупов и болтов - супер.
Но для строгания...
Во-первых, подписывайся, если нету сил завести account на gmail (я тебе приглашение со своего выслал, на всякий случай). Во-вторых, это всё напоминает спор ради спора: отвёртка, ok, что дальше? Методика не захватывает даже половины сравнительно реальных случаев.
Инженерия ПО - это фикция и миф. Это неинженерная отрасль, так как программистами работают те, у кого диплома инженера-программиста нет (представляешь себе кардиолога без диплома)? И если люди претендуют на то, что они дают метод работы, если подоводят под него научную базу, то пусть ответят, почему аппарат этого подхода разработан так слабо? Чем мне покрыть остальные 60% случаев кроме эвристического протыкивания "окон"? А если мыслей у парней никаких нет, чем, то я был бы не прочь, чтобы они заткнулись и не выступали на тему того, что каждый программист обязан там что-то... Если нет программирования, как инженерной дисциплины, то нет и никаких методик, а есть какие-то высосанные из пальца (или ещё каким способом добытые) подходы, которые могут нравиться дяде Васе и не нравиться мне. А также наоборот.
Вот такие мои соображения.
Аккаунт у меня был, и давно, просто я не рассмотрел, что там можно свое почтомыло писать, думал, что это еще какой-то аккаунт...
Я понял твою мысль, и ты прав, просто я никогда и ни к чему из рефакторингов, шаблонов, и причих ТДД не относился так же, как, скажем, к справочникам по расчету газгольдеров - в справочниках все четко указано: что, как, когда и сколько. Разработка ПО сейчас действительно не является инженерной дисциплиной но не только потому, что нет инженерских образований, это-то как раз легко теперь... Это не инженерная дисциплина еще и оттого, что до сих пор не сложились и не устоялись методики работы - те самые, которые мы с тобой обсуждаем. В общем, как у Пруткова: кто еще к кому приделан - хвост к собаке или собака к хвосту...
Всё это вместе объясняет, почему загнулся глубокомысленный ресурс, а на его месте появился шарашмонтаж. Ра-зо-ча-ро-ва-ни-е.
Отправить комментарий