DISCLAIMER: это моя типичная рецензия, в ней больше рассуждений на тему книги, чем информации о самой книге! Так что, не проходите мимо!
У стандартного процесса обучения есть интересная особенность. Как только мы решили узнать что-то новое, мы садимся за учебники, идем на курсы и получаем новые знания всеми доступными способами. Через время мы говорим себе «Фффатит!», забиваем на обучение и переходим к практике (на ранних этапах теория переплетается простыми практическими задачами, но они не оказывают существенного значения). После чего, мы начинаем применять наши новые знания на практике, и через время они практически полностью выветриваются из нашей славной головешки и их место занимает опыт.
Итак, что мы имеем? А имеем мы водопадную модель развития, когда на ранних этапах идет обучения, после которого начинается практика. И в чем проблема? А проблема здесь аналогична водопадной модели разработке ПО. Мы просто не в состоянии без должного опыта осознать все прелести сакральных знаний, которые нам пытаются вбить в голову на этапе обучения. У нас еще нет собственных набитых шишек, чтобы оценить эти советы по достоинству.
Процесс познания, как и процесс создания программных систем, должен быть итеративным. Мы изучаем что-то новое, применяем это что-то на практике, а потом снова возвращаемся к «основам», но смотрим на них уже совсем по-другому.
Самая большая опасность, которая может поджидать опытного специалиста – это уверенность в своих знаниях, которые вполне могут оказаться однобокими или протухшими. За 5-10-15 лет практики мы легко можем забыть причины, почему мы делаем так или иначе. Наш опыт очень часто достаточно однобок, что приводит к серьезным последствиям при разработке, например, новых систем. Мы привыкли работать с легаси кодом, ругать всех и вся, а как только появляется возможность сделать все с нуля, мы садимся в лужу, и начинаем повторять тот самый го#%о-код, который мы же сами ругали на предыдущих проектах. Почему? Да потому что тот самый го#%о-код является наиболее актуальным опытом, а как надо иначе мы просто не знаем (может и знали, да забыли).
Периодически нужно возвращаться к основам и стараться переосмыслить их согласно текущему опыту. Хороший букварь может уберечь и еще от одной типичной ловушки – от любви к крайностям. Человек их очень любит.
ЦИТАТА
Адаптивное планирование, а не предписывающее (Adaptive planning vs. Predictive planning). Высокоуровневое планирование все еще присутствует в гибких проектах, но низкоуровневое планирование существует лишь на одну-полторы итерации вперед.
Синхронный код плох, асинхронный рулит! И начинаем добавлять async-и с await-ами где ни попадя. Паттерны – круто, все остальное – ерунда! И давай их юзать десятками на страницу кода. Через время, набив шишек: Паттерны – фигня, гов#%-код – рулит, и давай выпиливать все паттерны на корню. Потом дело доходит до процессов и любовь к крайностям проявляется во всей красе: водопад - деревня, аджайл – крут! Теперь официально нам можно ничего не планировать, а сразу доставать шашку клавиатуру и начинать кодить!
Очевидно, что в каждом из приведенных выше примеров не хватает здравомыслия.
Agile не означает полное отсутствие планирования, не означает отсутствие архитектуры, не означает отсутствия риск-менеджемента! Все это там есть. Итеративность позволяет быстро получать обратную связь и корректировать курс на ее основе. Синхронный код бывает полезным, а правильное применение паттернов оправдывается очень быстро. Везде нужен здравый осмысленный подход.
ЦИТАТА
Итеративные методы гораздо старше, чем многие могут подумать. В конце 50-х годов прошлого века, в космической программе Меркурий применялась эволюционная, итеративная и инкрементальная разработка (IID, Iterative incremental development) вместо водопадной модели. А в начале 60-х помимо многих других проектов, эта же модель применялась при разработке проекта Трайдент. Первое печатная работа, которая продвигала итеративную разработку в противовес водопадной модели разработки, была опубликована в 1968 году в Исследовательском центре IBM имени Томаса Ватсона.
Если коснуться немного более подробно гибкой разработки, то она все равно подразумевает наличие нескольких этапов, таких как Inception (начало), Elaboration (развитие), Construction (разработка) и Transition (передача в эксплуатацию). Но, в отличие от водопадной модели, кодирование присутствует на каждом этапе, а анализ, проектирование и кодирование идут спиралью. Но начальные итерации все равно отличаются от остальных, поскольку на них большее внимание уделяется наиболее рискованным вопросам с точки зрения понимания требований, архитектуры или реализации.
При этом каждая итерация все же должна состоять из фаз анализа, разработки, тестирования и развертывания. Именно этот же процесс описывает Бертран Мейер в своей книге «Объектно-ориентированное конструирование программных систем»: каждая итерация – это мини-проект, который состоит из этапов анализа, проектирования, реализации, тестирования и развертывания. И теперь скажите, кто в «гибких» командах этому следует? А ведь это описано в книге по гибкой разработке!
ПРИМЕЧАНИЕ
Мейер идет еще дальше и предлагает выделить отдельный этап обобщения, о котором я писал в статье «О повторном использовании кода».
Проектирование – это еще одна тема, которая требует постоянных умственных усилий и пополнения багажа знаний. Сейчас каких только трехбуквенных сокращений нет, DDD, BDD, TDD, RDD. Такое чувство, что можно взять любые две буквы латинского алфавита, добавить D в конце и вы попадете на одну из известных методик проектирования. Но, как и во многих других вещах, нет ничего ценнее хороших фундаментальных знаний.
ЦИТАТА
Изучение требований и объектно-ориентированный анализ сосредоточены на понимании того, что именно нужно сделать (do the right thing). Т.е. на понимании некоторых ключевых целей и связанных с ними правил и ограничений. В то время как последующее проектирование сосредоточено на том, чтобы сделать это правильно (do the thing right). Т.е. умело спроектировать решение, которые будут удовлетворять поставленным требованиям.
Можно сколько угодно пытаться запомнить паттерны проектирования, а можно понять, что лежит в их основе. Это не только снизит нагрузку на память, но и позволит изучать новые паттерны, и, что самое главное, применять паттерны по назначению.
О книге “Applying UML and Patterns”
Из всех фундаментальных книг по проектированию (с полным списком можно ознакомиться здесь) я все еще не встречал ничего более фундаментального, чем книга Мейера. Но, нужно признать, книга Крэга Лармана “Applying UML and Patterns” тоже очень хороша.
В ней отлично показана связь современных процессов разработки с анализом и проектированием, роль UML (и вообще, визуального моделирования), рассмотрены фундаментальные принципы проектирования и приправлено все это паттернами.
The Good
Самое ценное в книге, ИМХО, это описание роли более формальных процессов в гибкой модели разработки. Поскольку «гибкость» сейчас очень часто ассоциируется с «берись и делай, а думать? Думать некогда!», то эта книга позволяет вернуться с небес на землю. Ларман очень хорошо описывает время и способы принятия архитектурных решений, способы описания архитектурных и проектных решений, и многие другие вопросы, которые сейчас, почему-то, ассоциируются со старой водопадной моделью.
ЦИТАТА
Мы используем понятия Слабой Связности (Low Coupling), чтобы оценить существующие проектные решения (designs) или чтобы сделать выбор между разными альтернативами – при прочих равных условий следует отдавать предпочтение решению, связность (coupling) которого будет минимальной.
Еще одной потрясающей особенностью книги является формализация процесса проектирования. Большинство разработчиков разбивают решение на компоненты, а компоненты на подкомпоненты скорее на уровне интуиции. GRASP-принципы, описанные в книге с помощью огромного числа примеров, дают понять, что должно лежать в основе наших решений.
“Ага, согласно принципу Информационного Эксперта этот метод нужно перенести в другой класс! Так, а в этом случае метод должен быть в этом классе, поскольку это будет лучше соответствует реальному миру! А вот в этом случае класс нужно убрать в другой слой, поскольку текущее решение нарушает принцип разделения модели от представления (Model View Separation Principle)”.
The Bad
Книга Лармана очень хороша, но не идеальна. Главным недостатком с моей точки зрения, является чрезмерное обилие диаграмм и юз-кейсов. Достаточно странно видеть в книге сотню UML-диаграмм и фразу типа «Хорошего проектировщика делает его опыт, а не инструменты». Если инструмент не столь важен, то зачем же ему уделять СТОЛЬКО внимания?
Также заметно, что книга является очередным изданием. Видно, что автор перешел от более формальных методов (типа RUP-а) к гибким методам. В книге десятки отсылок к RUP-овским принципам, которые мне не дают никакой пользы!
В результате, некоторые разделы приходится пробегаться по диагонали, поскольку пользы от них мало.
The Ugly
К оригинальному изданию никаких серьезных нареканий у меня нет. Чего нельзя сказать о переводе. Книги о проектировании переводить невероятно сложно, поскольку требует от переводчика полного понимания предмета. В результате, после недолгих мучений над отечественным изданием я переключился на оригинал.
Что в итоге?
Однозначно MUST READ!
Хорошая книга у меня вызывает массу мыслей, которые я публикую по ходу чтения. При чтении книги Лармана я написал 25 (!) заметок в Г+. Их легко найти с помощью поиска в Г+, а если лень, то ниже представлен список цитат в порядке от самых старых к новым.
Ссылка «О повторном использовании кода» битая
ОтветитьУдалитьСпасибо, поправил!
УдалитьСпасибо за очередную полезную статью! По мне, я бы поставил книгу Буча в один ряд.
ОтветитьУдалитьЯ бы сказал, что Буч менее формален и более философский, что-ли. Первая часть книги Буча - ИМХО, просто не заменима с точки зрения понимания вопросов сложности. Этого нет у Лармана.
УдалитьВ общем, я бы сказал, что каждая из них хороша и полезно прочитать их обе (плюс, Мейере, конечно).
Predictive planning - это все таки скорее Прогнозирующее планирование )
ОтветитьУдалить