97 этюдов для программистов. Опыт ведущих экспертов

Ричард Монсон-Хейфел (Richard Monson-Haefel) — редактор серии «97 Things» и редактор первой книги из этой серии, «97 Things Every Software Architect Should Know»,[1] в написании которой я принимал участие. Спасибо Ричарду за идею серии и за ее открытость для потенциальных участников, а также за то, что он так энергично поддерживал мои предложения по данной книге.

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

Я также благодарен за дополнительные отзывы, комментарии и предложения, авторами которых были Джованни Аспрони (Giovanni Asproni), Пол Колин Глостер (Paul Colin Gloster) и Микаэль Хунгер (Michael Hunger).

Спасибо O’Reilly за предоставленную этому проекту поддержку — от вики-хостинга, сделавшего книгу реальностью, до обеспечения всех стадий процесса публикации в бумажном виде. Сотрудники O’Reilly, которых я хотел бы особо поблагодарить: Майк Лукидес (Mike Loukides), Лорел Акерман (Laurel Ackerman), Эди Фридман (Edie Freedman), Эд Стивенсон (Ed Stephenson) и Рейчел Монахан (Rachel Monaghan).

Дело не только в том, что текст книги рождался в среде Веб: через Веб проект также приобрел известность и популярность. Спасибо всем, кто распространял сведения о нем через социальные сети, блоги и прочими путями.

Хочу также поблагодарить свою жену Кэролин за то, что привносит порядок в мой хаос, и двух моих сыновей, Стефана и Янника, за то, что часть этого порядка они вновь превращают в хаос.

Надеюсь, что эта книга станет для вас источником информации, открытий и вдохновения.

Приятного чтения!

Кевлин Хенни

(Kevlin Henney)

Будьте благоразумны Себ Роуз

В любом деле будь благоразумен и думай о последствиях.

Неизвестный

Как бы успокаивающе ни выглядел график работы в начале итерации, в какой-то момент неизбежно возникает нехватка времени. Если приходится разрываться между «сделать правильно» и «сделать быстро», часто возникает соблазн «сделать быстро» с оговоркой, что вы исправите решение позже, когда появится время. Вы совершенно искренне даете обещание именно так и поступить — даете самому себе, команде или заказчику. Но очень часто на следующей итерации возникают уже другие проблемы, которым и приходится посвящать свое внимание. Такую отложенную работу называют техническим долгом, и хорошего от него не жди. В своей классификации технических долгов Мартин Фаулер называет такой вид долга умышленным техническим долгом, и его не следует путать с непреднамеренным техническим долгом.[2]

Технический долг подобен кредиту: в краткосрочной перспективе он выгоден, но по нему приходится выплачивать проценты до полного погашения займа. Срезая углы при написании кода, вы затрудняете как разработку новой функциональности, так и рефакторинг. Это создает благоприятную почву для появления ошибок и нестабильных тестовых сценариев (test cases). Чем дольше долг существует, тем тяжелее последствия. К тому времени, как дойдут руки внести запланированные исправления, может оказаться, что на основе изначального сомнительного кода уже выстроена целая гора не вполне верных с точки зрения проектирования решений, а это значительно осложнит рефакторинг и исправление этого кода. На самом деле, к решению изначальной проблемы часто возвращаются лишь тогда, когда уже нет выбора, кроме как вернуться и все исправить. И зачастую к этому моменту исправление оказывается уже настолько сложным, что вы просто не можете себе позволить потерять так много времени или пойти на подобный риск.

Бывают ситуации, когда приходится идти на создание технического долга, если необходимо уложиться в срок или частично реализовать некую функциональность. Старайтесь не оказываться в таких ситуациях, однако если положение совершенно безвыходное, действуйте. Но (и это увесистое но) вы должны вести учет своего технического долга и гасить его как можно скорее, иначе проблемы растут, как снежный ком. И если уж вы пошли на такой компромисс, составьте карточку с заданием (task card) или создайте запись в системе учета дефектов, чтобы не забыть о проблеме.