Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Грязный код создает проблемы. Чтобы код было проще читать, проходится проводить его очистку, разбивая на части, с которыми удобно работать. Кент Бек, создатель методологии экстремального программирования и первопроходец в области паттернов проектирования, рассказывает нам, где и когда лучше проводить очистку для улучшения кода с учетом общей структуры системы. Книга не заставляет читателя проводить очистку сразу и целиком, а позволяет протестировать несколько примеров, которые подходят для поставленной задачи. Вы узнаете, как логически разделить на части большую функцию, содержащую множество строк кода. Познакомитесь с теоретическими понятиями программного дизайна: сцеплением, связностью, дисконтированными денежными потоками и вариативностью.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 100
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик Е. Матвеев
Кент Бек
Чистый дизайн. Практика эмпирического проектирования ПО. — Астана: "Спринт Бук", 2024.
ISBN 978-601-08-3730-0
© ТОО "Спринт Бук", 2024
Оглавление
Отзывы о книге
Кент Бек — тот человек, к которому всегда стоит прислушаться, и я ждал этой книги не один десяток лет. Книга переводит фокус разработки с инструментов и технологий на то, что действительно важно, — дизайн! Дизайн — это форма, которую мы задаем в коде, и Кент помогает создавать более изящную форму. Это важная книга на важную тему.
— Дэйв Фарли (Dave Farley), основатель и директор Continuous Delivery Ltd.
Разобраться в коде бывает нелегко, и разработчик порой не знает, с чего начать. Практические советы, собранные в этой книге, помогут разработчикам любого уровня улучшить код, с которым они имеют дело.
— Сэм Ньюман (Sam Newman), независимый консультант, специалист по технологиям и автор книг Building Microservices и Monolith to Microservices
Кент Бек делится с читателями доступными идеями о том, как упростить запутанный код. Эти идеи лежат на поверхности, но, читая книгу, вы часто будете спрашивать себя, почему они не приходили вам в голову раньше. Книга рекомендуется всем, чья цель — чистый код, который легко читать.
— Гергели Орош (Gergely Orosz), сайт The Pragmatic Engineer
Десятилетиями книги по рефакторингу затрагивали вопросы только нисходящего, объектно-ориентированного дизайна. Эта книга ломает стереотипы, предлагая практический подход инкрементного улучшения существующего рабочего кода.
— Мод Лемэр (Maude Lemaire), автор книги Refactoring at Scale
Скажем честно: 99 % своего времени разработчик имеет дело с кодом, который уже был написан до него. Это непростая задача, особенно если создатели кода не старались делать его удобочитаемым. Кент Бек меняет этот подход, выводя на первый план человеческие отношения. Он коротко и ясно объясняет, как улучшить дизайн кода, постепенно внося небольшие изменения, благодаря которым код станет понятнее вам и вашим коллегам.
— Влад Кононов, автор книги Learning Domain-Driven Design
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу
(издательство «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 Use1 (Addison Wesley, 1999), написанной совместно с Люси Локвуд (Lucy Lockwood) и отмеченной премией Jolt Award, а также 15 сочинений под псевдонимом Лайор Сэмсон (Lior Samson).
1 Константайн Л., Локвуд Л. «Разработка программного обеспечения». — Санкт-Петербург, издательство «Питер».
Предисловие
О чем эта книга?
«Мне нужно изменить код, но в нем сплошной бардак. С чего начать?»
«Может, стоит сначала почистить код, прежде чем вносить изменение? Может быть. В некоторых местах. А может быть, и нет?»
Это вопросы, которые вы могли задавать себе. И если бы на них были простые ответы, мне не пришлось бы писать для этого целую книгу.
Книга расскажет:
• Когда стоит чистить грязный код, прежде чем менять то, что он делает.
• Как безопасно и эффективно очистить грязный код.
• На чем завершать очистку грязного кода.
• Почему очистка работает?
Дизайн ПО — это упражнение на налаживание взаимоотношений между людьми. Мы начнем с пресловутого человека из зеркала — с отношений разработчика с самим собой. Почему мы не выделяем время на заботу о себе? Время на то, чтобы упростить себе работу? Почему мы так увлекаемся очисткой кода, что убираем из него то, что создаст ценность для пользователей?
Эта книга — первый шаг моей миссии: помочь разработчикам чувствовать себя в безопасности в этом мире. Кроме того, она описывает первое, что нужно сделать, сталкиваясь с грязным кодом. Дизайн ПО — мощный инструмент для решения проблем… при правильном использовании. При неправильном обращении он способен только затруднить разработку и снизить ее эффективность.
Это первая книга в серии, посвященной дизайну ПО. Моя цель — сделать дизайн простым и полезным, поэтому я начну с вопросов, которые можно решить самостоятельно. В следующих книгах мы коснемся тех аспектов дизайна, которые затрагивают отношения в команде, а затем перейдем к самой серьезной части: отношениям между бизнесом и технологией. Но сначала необходимо разобраться в дизайне и научиться проектировать так, чтобы это приносило пользу повседневной работе.
Представьте, что у вас есть большая функция со множеством строк кода. Прежде чем изменять ее, вы читаете код и пытаетесь понять, что он делает. В процессе чтения вы замечаете, как можно логически разделить код на меньшие части. Извлечение этих частей означает очистку кода. Среди других видов очистки можно выделить охранные выражения (guard clauses), содержательные комментарии и функции-хелперы.
Я подкрепляю свои советы практикой — в примерах книги очистка осуществляется небольшими частями и указывается, когда и где можно применять описанные приемы. Таким образом, не нужно пытаться очистить весь код сразу, следует выполнять очистку поэтапно, небольшими шагами, которые имеют смысл применительно к вашей задаче. Книга также поясняет теоретические концепции, лежащие в основе дизайна ПО: сцепление, связность, анализ дисконтирования денежных потоков и вариативность.
Для кого эта книга
Эта книга предназначена для разработчиков, лидов, практикующих архитекторов ПО и технических руководителей. Она не привязана к конкретному языку программирования, и все разработчики смогут прочитать ее и применить представленные концепции в своих проектах. Предполагается, что читатель уже имеет опыт программирования.
Что вы узнаете
К концу этой книги вы будете понимать:
• Фундаментальное отличие между изменением поведения системы и изменением ее структуры.
• Ценность чередования вложений в структуру и вложений в поведение при изменении кода одним человеком.
• Основы теории дизайна ПО и факторы, которые на него влияют.
Также вы научитесь:
• Делать процесс программирования более приятным, проводя очистку сначала (а иногда — потом).
• Вносить крупные изменения небольшими, безопасными шагами.
• Воспринимать дизайн как деятельность людей, чьи интересы могут расходиться.
Структура книги
Книга состоит из введения и трех частей.
Введение
Я начну с краткого описания того, почему я написал эту книгу, как я решил написать ее, для кого она предназначена и чего от нее ожидать. Затем перейдем к сути.
Часть I. Очистка
Очистка — своего рода миниатюрный рефакторинг. Каждая короткая глава посвящена определенному действию по очистке. Если вы видите «вот такой» код, замените его «вот этаким» кодом и отправляйте на продакшен.
Часть II. Управление
В следующей части рассматривается управление процессом очистки. Один из принципов философии очистки заключается в том, что очистку никогда не нужно выделять в отдельную задачу. О ней никогда не следует отчитываться, ее необязательно отслеживать или планировать. Вам нужно изменить код; это сложно, потому что он грязный и запутанный, поэтому вы начинаете с его очистки. Это часть повседневной работы и процесс, который можно улучшить разумным подходом.
Часть III. Теория
Здесь я наконец расправлю крылья и погружусь в тему, которая вызывает у меня неподдельный интерес. Что я имею в виду, говоря, что дизайн ПО — это проверка человеческих отношений? Кто эти люди? Почему улучшение дизайна поможет лучше удовлетворять их потребности? Почему программные продукты такие дорогие? Что с этим можно сделать (спойлер: дизайн ПО)? Сцепление? Связность? Степенной закон?
Я старался, чтобы читатель, начав читать эту книгу утром, к обеду мог улучшить качество своего дизайна. А затем еще понемногу улучшать его каждый последующий день. И скоро дизайн перестанет быть слабейшим звеном в цепочке создания ценности продукта.
Почему дизайн «эмпирический»?
Самые громкие споры в области дизайна ПО, очевидно, ведутся о том, что проектировать:
• Насколько большими должны быть сервисы?
• Насколько большими должны быть репозитории?
• События или явный вызов сервисов?
• Объекты? Функции? Или императивный код?
Все эти споры на тему «что» скрывают более фундаментальное расхождение: когда? Приведем несколько карикатурное представление полюсов этого расхождения.
Спекулятивный дизайн
Мы знаем, какой следующий компонент надо создавать, поэтому разработаем его дизайн сегодня. Это будет дешевле. Кроме того, когда продукт выйдет на продакшен, у нас уже не будет возможности заняться дизайном, поэтому сделаем все сразу и сейчас.
Реактивный дизайн
Функциональность — вот что действительно важно, поэтому сегодня заниматься дизайном будем по минимуму и уделим все внимание функциональности. Только когда добавлять функции станет практически невозможно, мы с неохотой перейдем к дизайну, и то только затем, чтобы опять вернуться к функциям.
Обычно я стараюсь отвечать на вопрос «когда?» словами «где-то в середине». Если мы замечаем, что с добавлением функциональности возникают сложности, мы переходим к работе над дизайном, пока эти сложности не исчезнут. Мы начинаем с минимальной проработки дизайна, с которой запустится цикл обратной связи.
Функциональность
Что нужно пользователям?
