Стоит почитать: принципы гибкой разработки на С#
Предлагаем вашему вниманию краткий обзор книги «Принципы, паттерны и методики гибкой разработки на языке С#», которую написал Роберт Мартин, американский разработчик, инженер и консультант.
Эта книга считается классикой и рекомендуется к прочтению каждому C#-программисту. К тому же, ее написал известнейший специалист в этой области, из-под пера которого вышли такие книги, как «Идеальный программист» и «Чистый код», ставшие культовыми.
Роберт Мартин, он же «Дядя Боб» не просто теоретик, а практикующий эксперт. В этой книге он рассказывает о том, как лучше написать хороший и безопасный код и сделать это в мире, где заказчик меняет требования, что называется, на ходу.
Уже в самых первых главах кратко рассказывается, что собой представляют экстремальное программирование и гибкая разработка. Автор рассуждает, какие плюсы можно получить от введения гибкой разработки, а также с чего стоит начинать. Вы узнаете, как правильно вести планирование и успешно выполнять ежедневные задачи. Каков процесс и какой должен быть итог.
Test Driven Development
Чем раньше и чаще проводится тестирование, тем раньше заметны отклонения и больше вероятность получения рабочего продукта на любом этапе разработки.
Тестированию в книге уделено особое внимание. Автор рассказывает о TDD, ведь разработка через тестирование обладает заметными преимуществами. При разработке тестов большинство программистов продумывают архитектуру в целом. А еще Test Driven Development дает возможность сэкономить на работе тестировщиков и одновременно с этим выпускать более чистые билды, то есть стадия полировки продукта сокращается.
Говорят, что практически в любой команде существует разработчик, который не только знает про TDD, но и мечтает внедрить этот подход в свой проект. К сожалению, нередко специфика коммерческих проектов не позволяет это сделать, ведь многие заказчики не готовы отдельно оплачивать процесс написания тестов. Не говоря уже о том, что просто нерационально затрачивать время на написание тестов, когда приносят заказ, который должен быть выполнен еще «вчера».
Рефакторинг
Рефакторинг можно сравнить с уборкой с послеобеденного стола. Конечно, если со стола не убирать, обед закончится быстрее. Однако в следующий раз вы столкнетесь с отсутствием чистой посуды и пустого места. В результате следующий обед придется готовить дольше. И убирать потом тем более не захочется. И так далее.
Именно рефакторингу посвящена одна из глав книги. Возвращаясь к нашему «столу», скажем, что после трудов высококлассного клининг-менеджера, код станет чище и приятнее, да и, в конце концов, быстрее. Таким образом, рефакторинг следует выполнять после завершения задачи.
В целом, ценность данной главы заключается не только в советах и рассуждениях автора, а в том, что он показывает, как проводить рефакторинг на практических примерах.
Эпизод
Это одна из наиболее интересных глав. В качестве аналогии приводится игра в боулинг. Перед читателями — общение между 2-мя специалистами. Диалоги здесь максимально приближены к реальности, то есть перед нами ситуация, когда правки поступают от заказчика неисчерпаемым потоком, а программисту надо успеть адаптировать код под измененные требования.
Главу можно назвать уникальной в своем роде — сложно найти что-нибудь похожее в других книгах по программированию (к сожалению, во многих из них зачастую дают теорию без практики).
Гибкое проектирование
В этой части дается вводная в объектно-ориентированную разработку. Автор рассказывает, что это, учит методам оптимизации, а также тому, как управлять сложностями.
Разъясняются значения таких аббревиатур, как OCP, SRP, LSP, DIP, ISP. При этом делается это настолько доступным языком, что разъяснения будут понятны даже первокурсникам. И если вы не помните хотя бы 2 из вышеописанных значений, обязательно прочитайте книгу или хотя бы соответствующую главу.
Далее идут диаграммы. Конечно, разработчики не очень любят их рисовать, однако этап проектирования дает возможность избежать лишней работы далее. Следовательно, уметь рисовать UML-диаграммы должен уметь каждый.
Паттерны
Куда же без них, ведь паттерны разработчики применяют чуть ли не ежедневно, внедряя их на практике. Тем не менее порой можно слышать программиста, который говорит, что он паттернов не знает и прекрасно без них обходится.
На самом деле знать паттерны просто необходимо, ведь они могут значительно ускорить разработку. Можно сказать, что вся работа состоит из различных паттернов, ведь действительно уникальные вещи встречаются крайне редко.
Вывод
Пожалуй, эту книгу можно порекомендовать разработчикам любого уровня. Она особенно важна для тех, кто находится на пути становления, но будет весьма полезна и опытным коллегам, т. к. поможет заполнить существующие пробелы в знаниях.
