The Crash Driven Development
Автор: empat
Insight IT #1
Друзья, как вы, наверное, заметили, у нас в блоге стали появляться около-ИТшные темы, которые являются непосредственным результатом активного развития ИТ отдела в нашей компании. Кроме того, как вы помните, мы просто обожаем различные междисциплинарные направления. Поэтому с этого поста мы решили открыть раздел Insight IT, в который будем публиковать интересные темы из сферы информационных технологий и их применения в бизнесе и управлении.
Если Вы находитесь “на волне” в области IT-разработки, то, вероятно, знаете, что вторая половина 20 века принесла человечеству – наряду с очевидно полезными вещами – и невероятное количество разношерстных “DD” – то бишь, методологий, методик и методичек по поводу того, как верно разрабатывать софт. Ну вот, например, MDD (Model Driven Development), TDD (Test), BDD (Behaviour) и даже DDD (Design) .
Все эти концепции, конечно, придуманы не абы кем (и весьма умными головами) – однако у программистов-пролетариев при упоминании хотя бы одного из этих страшных слов начинается мигрень, мутнеет взгляд и опускаются руки. Результат один – затяжная депрессия, и каждый вновь написанный скучный тест приближает на шаг к могиле.
Что делать?
Для начала – посмотреть вглубь себя. И, как ни странно, именно здесь разглядеть коренной недостаток достаточно формальных систем вроде TDD. Они убивают драйв. И ни гигантская зарплата, ни даже эстетическое удовольствие от построения целостного, с безысходностью верно работающего продукта часто не способны покрыть отсутствие удовольствия от самого процесса разработки.
Назад, к инстинктам! Вот три истинных и вечных, как мир, утверждения:
- Рыбаки любят ловить рыбу;
- Охотники любят отлавливать добычу;
- Программисты любят отлавливать баги.
Даже несмотря на то, что далеко не всякий баг возможно изжарить и с аппетитом съесть, в основе каждой из вышеперечисленных деятельностей лежит одно и то же фундаментальное свойство человеческой природы.
Так пусть в Вашем коде будут ошибки! Положите в ящик измучивший Вас шаблон “тесты – модуль”. Просто берите и пишите! Необязательно все сразу – а ровно столько, сколько захотят танцевать пальцы на клавиатуре. Теперь скомпилируйте. Все умерло? Ничего не работает? Ах, и как это хорошо!
Подумайте, сколько Вы способны потратить времени на скрупулезное написание (почти) идеально работающего кода? Час, два, три? Пять – Вы герой. А сколько – на отлавливание багов?.. Больше, много больше. Они не дают спать ночами. Они манят подобно тому, как мыши манят котов – и Вы просто не способны заниматься ничем другим до тех пор, пока все не заработает так, как нужно. А этот последний момент!.. Чистая радость познания, описываемая Платоном, оказывается ничтожной по сравнению с тем, что испытывает настоящий программист в момент устранения ошибки.
Итак, если Вы:
- Пишете небольшую систему и в небольшой команде,
- Не зажаты слишком жесткими рамками по времени выполнения,
- Не связаны сильной взаимозависимостью кода различных разработчиков,
- Ощущаете недостаточность внешней мотивации, эстетической и денежной, -
Возможно, Ваш выбор – то, что я называю Crash Driven Development. Где “driven” – от слова “драйв”.
Конечно, вовсе не стоит намеренно писать код так, чтобы он содержал ошибки. Просто будьте вольным художником – оформляйте свои идеи в код, не отвлекаясь на тесты до поры. Будьте уверены: Вы непременно где-нибудь ошибетесь И тогда – вооружайтесь. Отключайте телефоны, включайте логгер, дебаггер – и ощущайте, как Ваши собственные ошибки двигают Вас вперед, превращая разработку в настоящий addiction.
…”Паша,” – кричит мой брат, – “чай уже остыл!”. Сейчас, сейчас… Я почти нашел, в чем причина…
Оформить и получить займ на карту мгновенно круглосуточно в Москве на любые нужды в день обращения. Взять мгновенный кредит онлайн на карту в банке без отказа через интернет круглосуточно.
By Bayram Annakov, December 22, 2010 @ 9:35 am
По этому поводу вспомнилось следующее из “Мозг фирмы”:
Ошибка, контролируемая на разумном уровне, не есть абсолютный порок, как нам внушают. Наоборот, она является предварительным условием выживаемости.
Ответить
pavel.kabir Ответ:
December 23rd, 2010 at 12:00 am
Да, это глубоко…
Мне Влад Шулюгин вчера переслал еще цитату, вписывающуюся в тот же ассоциативный ряд.
“Мы видим предмет благодаря несовершенству нашего видения. При совершенном видении мы видим гармонию, а предмета не замечаем.”
Владимир Вейсберг
Ответить
By Anne, December 22, 2010 @ 1:54 pm
Ах как приятно читать этот пост, я думаю Байрам меня понимает. Вот сидишь проверяешь работоспособность продукта и находишь кучу мелких и не очень даже мелких ошибок, отправляешь программисту и у него начинается “веселье”. Как же я люблю доставлять им это “удовольствие”.
И теперь посерьезней. Любая методология, будь TDD, Agile, Waterfall…которая сможет вести к успеху и пробудить азарт к улучшению продукта – будет лучшей для команды. Главное чтобы вся команда ясно видела цель и шла к ней. И даше ошибки будут радовать, потому что будет место для улучшения, и такой подход только увеличит мотивацию. А лучшим залогом успеха будет качество.
Ответить
pavel.kabir Ответ:
December 22nd, 2010 at 11:56 pm
Anne, я очень согласен, что никакая вещь не должна претендовать на абсолютную общность. Думается, максимум “кайфа” (без иронии) человек ловит тогда, когда он все еще погружен в задачу. Исправлять же свежеобнаруженные ошибки двухлетней давности, как верно подмечал Брайан Харри из Microsoft – “is. not. fun.”
Памятуя о границах применимости, я и попытался перечислить предпосылки (надо сказать, довольно сильные и ограничивающие), при которых столь сомнительная концепция, как “CDD”, вовсе может использоваться в реальных проектах
Ответить
By Dmitry Stepanov, December 23, 2010 @ 12:00 am
А как обеспечить качество ПО без тестов?
Всё-таки, test-driven гарантирует, что тесты вообще будут написаны
Да и не меньшее удовольствие получаешь, когда пишешь что-то, что проходит тесты.
Рефакторингом без тестов заниматься страшно.
Ответить
pavel.kabir Ответ:
December 23rd, 2010 at 12:22 am
Дим, я совершенно без шуток верую, что TDD – великая вещь и несет людям свет. Все, что я хочу сказать этим постом – это то, что (по моему опыту) иногда можно обойтись и без него.
Часто на помощь менеджеру, помимо формальных инструментов, могут приходить и старые добрые человеческие отношения, роль которых трудно переоценить, особенно в некрупных проектах. Я думаю, что едва ли нужно устанавливать жесткий контроль над человеком, относительно которого ты знаешь: он напишет все тесты постфактум, в конце текущей итерации. А теперь нужно дать ему проявить свое творческое начало. Если задушить формальностью, когда это не требуется – иной человек увянет, и это уже страшно.
Наконец, огромную роль играет специфика самой системы – а значит, и контекст разработки. Так, на последней SECR 2010 отец С++ Бьярн Страуструп на вопрос о том, занимается ли он TDD, ответил коротко: нет; и мол, то, что он пишет, не испытывает необходимости в столь мощном инструментарии.
…Одним словом, границы применимости. Которым, наверное, можно и нужно посвятить не один отдельный пост.
Ответить
Bayram Ответ:
December 23rd, 2010 at 7:21 pm
+1 про границы применимости
Ответить