The Crash Driven Development

Insight IT #1

Друзья, как вы, наверное, заметили, у нас в блоге стали появляться около-ИТшные темы, которые являются непосредственным результатом активного развития ИТ отдела в нашей компании. Кроме того, как вы помните, мы просто обожаем различные междисциплинарные направления. Поэтому с этого поста мы решили открыть раздел  Insight IT, в который будем публиковать интересные темы из сферы информационных технологий и их применения в бизнесе и управлении.

Если Вы находитесь “на волне” в области IT-разработки, то, вероятно, знаете, что вторая половина 20 века принесла человечеству – наряду с очевидно полезными вещами – и невероятное количество разношерстных “DD” – то бишь, методологий, методик и методичек по поводу того, как верно разрабатывать софт. Ну вот, например, MDD (Model Driven Development), TDD (Test), BDD (Behaviour) и даже DDD (Design) .

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

Что делать?

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

Назад, к инстинктам! Вот три истинных и вечных, как мир, утверждения:

• Рыбаки любят ловить рыбу;
• Охотники любят отлавливать добычу;
• Программисты любят отлавливать баги.

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

Так пусть в Вашем коде будут ошибки! Положите в ящик измучивший Вас шаблон “тесты – модуль”. Просто берите и пишите! Необязательно все сразу – а ровно столько, сколько захотят танцевать пальцы на клавиатуре. Теперь скомпилируйте. Все умерло? Ничего не работает? Ах, и как это хорошо!

Подумайте, сколько Вы способны потратить времени на скрупулезное написание (почти) идеально работающего кода? Час, два, три? Пять – Вы герой. А сколько – на отлавливание багов?.. Больше, много больше. Они не дают спать ночами. Они манят подобно тому, как мыши манят котов – и Вы просто не способны заниматься ничем другим до тех пор, пока все не заработает так, как нужно. А этот последний момент!.. Чистая радость познания, описываемая Платоном, оказывается ничтожной по сравнению с тем, что испытывает настоящий программист в момент устранения ошибки.

Итак, если Вы:

• Пишете небольшую систему и в небольшой команде,
• Не зажаты слишком жесткими рамками по времени выполнения,
• Не связаны сильной взаимозависимостью кода различных разработчиков,
• Ощущаете недостаточность внешней мотивации, эстетической и денежной, -

Возможно, Ваш выбор – то, что я называю Crash Driven Development. Где “driven” – от слова “драйв”.

Конечно, вовсе не стоит намеренно писать код так, чтобы он содержал ошибки. Просто будьте вольным художником – оформляйте свои идеи в код, не отвлекаясь на тесты до поры. Будьте уверены: Вы непременно где-нибудь ошибетесь И тогда – вооружайтесь. Отключайте телефоны, включайте логгер, дебаггер – и ощущайте, как Ваши собственные ошибки двигают Вас вперед, превращая разработку в настоящий addiction.

…”Паша,” – кричит мой брат, – “чай уже остыл!”. Сейчас, сейчас… Я почти нашел, в чем причина…

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

7 отзывов

• 

  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 про границы применимости

  Ответить

Ссылки на эту статью

Оставить отзыв