Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Предлагаем вашему вниманию краткий обзор книги "<strong>Принципы, паттерны и методики гибкой разработки на языке С#"</strong>, которую написал Роберт Мартин, американский разработчик, инженер и консультант.</p>

2 <p>Эта книга считается классикой и рекомендуется к прочтению каждому C#-программисту. К тому же, ее написал известнейший специалист в этой области, из-под пера которого вышли такие книги, как "Идеальный программист" и "Чистый код", ставшие культовыми.</p>

3 <p>Роберт Мартин, он же "Дядя Боб" не просто теоретик, а практикующий эксперт. В этой книге он рассказывает о том, как лучше написать хороший и безопасный код и сделать это в мире, где заказчик меняет требования, что называется, на ходу.</p>

4 <p>Уже в самых первых главах кратко рассказывается, что собой представляют экстремальное программирование и гибкая разработка. Автор рассуждает, какие плюсы можно получить от введения гибкой разработки, а также с чего стоит начинать. Вы узнаете, как правильно вести планирование и успешно выполнять ежедневные задачи. Каков процесс и какой должен быть итог.</p>

5 <h2>Test Driven Development</h2>

6 <p>Чем раньше и чаще проводится тестирование, тем раньше заметны отклонения и больше вероятность получения рабочего продукта на любом этапе разработки.</p>

7 <p>Тестированию в книге уделено особое внимание. Автор рассказывает о TDD, ведь разработка через тестирование обладает заметными преимуществами. При разработке тестов большинство программистов продумывают архитектуру в целом. А еще Test Driven Development дает возможность сэкономить на работе тестировщиков и одновременно с этим выпускать более чистые билды, то есть стадия полировки продукта сокращается.</p>

8 <p>Говорят, что практически в любой команде существует разработчик, который не только знает про TDD, но и мечтает внедрить этот подход в свой проект. К сожалению, нередко специфика коммерческих проектов не позволяет это сделать, ведь многие заказчики не готовы отдельно оплачивать процесс написания тестов. Не говоря уже о том, что просто нерационально затрачивать время на написание тестов, когда приносят заказ, который должен быть выполнен еще "вчера".</p>

9 <h2>Рефакторинг</h2>

10 <p>Рефакторинг можно сравнить с уборкой с послеобеденного стола. Конечно, если со стола не убирать, обед закончится быстрее. Однако в следующий раз вы столкнетесь с отсутствием чистой посуды и пустого места. В результате следующий обед придется готовить дольше. И убирать потом тем более не захочется. И так далее.</p>

11 <p>Именно рефакторингу посвящена одна из глав книги. Возвращаясь к нашему "столу", скажем, что после трудов высококлассного клининг-менеджера, код станет чище и приятнее, да и, в конце концов, быстрее. Таким образом, рефакторинг следует выполнять после завершения задачи.</p>

12 <p>В целом, ценность данной главы заключается не только в советах и рассуждениях автора, а в том, что он показывает, как проводить рефакторинг на практических примерах.</p>

13 <h2>Эпизод</h2>

14 <p>Это одна из наиболее интересных глав. В качестве аналогии приводится игра в боулинг. Перед читателями - общение между 2-мя специалистами. Диалоги здесь максимально приближены к реальности, то есть перед нами ситуация, когда правки поступают от заказчика неисчерпаемым потоком, а программисту надо успеть адаптировать код под измененные требования.</p>

15 <p>Главу можно назвать уникальной в своем роде - сложно найти что-нибудь похожее в других книгах по программированию (к сожалению, во многих из них зачастую дают теорию без практики).</p>

16 <h2>Гибкое проектирование</h2>

17 <p>В этой части дается вводная в объектно-ориентированную разработку. Автор рассказывает, что это, учит методам оптимизации, а также тому, как управлять сложностями.</p>

18 <p>Разъясняются значения таких аббревиатур, как OCP, SRP, LSP, DIP, ISP. При этом делается это настолько доступным языком, что разъяснения будут понятны даже первокурсникам. И если вы не помните хотя бы 2 из вышеописанных значений, обязательно прочитайте книгу или хотя бы соответствующую главу.</p>

19 <p>Далее идут<strong>диаграммы</strong>. Конечно, разработчики не очень любят их рисовать, однако этап проектирования дает возможность избежать лишней работы далее. Следовательно, уметь рисовать UML-диаграммы должен уметь каждый.</p>

20 <h2>Паттерны</h2>

21 <p>Куда же без них, ведь паттерны разработчики применяют чуть ли не ежедневно, внедряя их на практике. Тем не менее порой можно слышать программиста, который говорит, что он паттернов не знает и прекрасно без них обходится.</p>

22 <p>На самом деле<strong>знать паттерны просто необходимо</strong>, ведь они могут значительно ускорить разработку. Можно сказать, что вся работа состоит из различных паттернов, ведь действительно уникальные вещи встречаются крайне редко.</p>

23 <h2>Вывод</h2>

24 <p>Пожалуй, эту книгу можно порекомендовать разработчикам любого уровня. Она особенно важна для тех, кто находится на пути становления, но будет весьма полезна и опытным коллегам, т. к. поможет заполнить существующие пробелы в знаниях.</p>

25 <p><em><a>Источник</a></em></p>