Чистый дизайн. Практика эмпирического проектирования ПО

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу

comp@sprintbook.kz

(издательство «SprintBook», компьютерная редакция).

Мы будем рады узнать ваше мнение!

Светлой памяти профессора Барри Дволацки (Barry Dwolatzky), выдающегося технического специалиста, стихийной силы и источника вдохновения.

Вступительное слово

Эта небольшая книга, первая в серии, предназначена для профессио­нальных разработчиков — тех, кто с глубоким интересом относится к своему ремеслу и к возможности совершенствовать свой результат понемногу, но с высокой отдачей. Автор, Кент Бек, как раз из таких профессионалов — преданный своему делу, всегда внимательный к деталям и никогда не забывающий о главных проблемах и масштабной картине.

Практикующие разработчики часто не уделяют должного внимания теории, но Кент знает, о чем говорит, когда объединяет практику и теорию в руководство по очистке кода, одновременно доступное и полезное.

«В теории нет разницы между теорией и практикой. А на практике есть». Разные версии этой фразы часто и ошибочно приписываются Альберту Эйнштейну, Йоги Берра и другим знаменитостям. Только дотошный автор (каюсь, виноват!) докопается до того, что эта фраза принадлежит Бенджамину Брюстеру (Benjamin Brewster), студенту Йельского университета, написавшему в 1882 году статью для университетского литературного журнала. Благодаря самоотверженной работе специалистов с QuoteInvestigator.com я могу поделиться с читателями этой малоизвестной деталью, будучи уверенным: в нашей профессии важна точность всех деталей.

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

Теория гласит, что сложность кода зависит от того, как он разделен на части, насколько сильно сцепление этих частей и какова связность между этими частями. В качестве источника теории сцепления (coupling) и связности (cohesion) обычно указывается моя книга Structured Design (Yourdon Press, 1975; Prentice Hall, 1979), написанная совместно с Эдом Йордоном (Ed Yourdon), хотя истоки этой теории прослеживаются до презентации на конференции 1968 года в Кембридже, штат Массачусетс. Темы сцепления и связности едва не были исключены из издания Prentice Hall 1979 года. Редакторы убеждали меня и Эда убрать две главы, потому что «теория никого не интересует». К счастью для истории программирования, авторы победили, а редакторы оказались не правы. С тех пор теория была проверена на полувековой практике, а также сотнях научных исследований.

Сцепление и связность — простые метрики сложности компьютерного кода: не с точки зрения компьютеров, выполняющих программы, а с точки зрения людей, пытающихся понять код. Если вы хотите понять любую программу (чтобы создать ее с нуля, внести исправление или изменение), необходимо понимать не только блок кода, находящийся непосредственно перед вами, но и другие блоки, с которыми он соединен, от которых он зависит, на которые он влияет или которые влияют на него. Отдельный фрагмент кода понять легче, если он представляет единое целое и имеет единый смысл, если он образует то, что когнитивные психологи называют гештальтом. Это связность. Кроме того, понять происходящее в контексте отношений с другими частями кода проще, если эти отношения немногочисленны, относительно слабы или сильно ограничены. Это сцеп­ление. Сцепление и связность в действительности означают только то, как ваш мозг воспринимает сложные системы.

Видите? Красиво и четко. Но это в теории. Теперь нужно перейти к практическим деталям и добавить ровно столько теории, чтобы происходящее было понятно. Кент Бек станет вашим опытным проводником на этом пути.

— Ларри Константайн (Larry Constantine) Роули, штат Массачусетс. 9 октября 2023 г.

Ларри Константайн — бывший профессор университета Мадейры, Португалия, и Технологического университета Сиднея, Австралия. Он автор более 200 статей и трех десятков книг, в том числе книги Software for Use¹ (Addison Wesley, 1999), написанной совместно с Люси Локвуд (Lucy Lockwood) и отмеченной премией Jolt Award, а также 15 сочинений под псевдонимом Лайор Сэмсон (Lior Samson).

¹ Константайн Л., Локвуд Л. «Разработка программного обеспечения». — Санкт-Петербург, издательство «Питер».

Предисловие

О чем эта книга?

«Мне нужно изменить код, но в нем сплошной бардак. С чего начать?»

«Может, стоит сначала почистить код, прежде чем вносить изменение? Может быть. В некоторых местах. А может быть, и нет?»

Это вопросы, которые вы могли задавать себе. И если бы на них были простые ответы, мне не пришлось бы писать для этого целую книгу.

Книга расскажет:

• Когда стоит чистить грязный код, прежде чем менять то, что он делает.

• Как безопасно и эффективно очистить грязный код.

• На чем завершать очистку грязного кода.

• Почему очистка работает?

Дизайн ПО — это упражнение на налаживание взаимоотношений между людьми. Мы начнем с пресловутого человека из зеркала — с отношений разработчика с самим собой. Почему мы не выделяем время на заботу о себе? Время на то, чтобы упростить себе работу? Почему мы так увлекаемся очисткой кода, что убираем из него то, что создаст ценность для пользователей?

Эта книга — первый шаг моей миссии: помочь разработчикам чувствовать себя в безопасности в этом мире. Кроме того, она описывает первое, что нужно сделать, сталкиваясь с грязным кодом. Дизайн ПО — мощный инструмент для решения проблем… при правильном использовании. При неправильном обращении он способен только затруднить разработку и снизить ее эффективность.

Это первая книга в серии, посвященной дизайну ПО. Моя цель — сделать дизайн простым и полезным, поэтому я начну с вопросов, которые можно решить самостоятельно. В следующих книгах мы коснемся тех аспектов дизайна, которые затрагивают отношения в команде, а затем перейдем к самой серьезной части: отношениям между бизнесом и технологией. Но сначала необходимо разобраться в дизайне и научиться проектировать так, чтобы это приносило пользу повседневной работе.

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

Я подкрепляю свои советы практикой — в примерах книги очистка осуществляется небольшими частями и указывается, когда и где можно применять описанные приемы. Таким образом, не нужно пытаться очистить весь код сразу, следует выполнять очистку поэтапно, небольшими шагами, которые имеют смысл применительно к вашей задаче. Книга также поясняет теоретические концепции, лежащие в основе дизайна ПО: сцепление, связность, анализ дисконтирования денежных потоков и