Ответ
Мартин Фаулер — один из ключевых авторов, сформировавших моё понимание проектирования ПО. Его книга «Рефакторинг. Улучшение существующего кода» — это настольная книга, а описанные в ней приёмы (например, «Выделение метода» или «Замена временной переменной запросом») я применяю ежедневно.
Сильное влияние:
- Практичность: Он объясняет сложные архитектурные паттерны (как в «Шаблонах корпоративных приложений») через призму реальных проблем, а не абстрактной теории.
- Акцент на эволюционном дизайне: Идея о том, что архитектура emerges и её можно улучшать последовательными малыми изменениями (рефакторингом), очень близка современным Agile-подходам.
- Чёткий язык: Он дал названия многим практикам (например, Dependency Injection), что позволило сообществу эффективно о них коммуницировать.
Критический взгляд:
- Некоторые предложенные шаблоны, такие как Active Record, в современных высоконагруженных или сложных системах часто заменяются на более гибкие подходы (например, Data Mapper + Repository).
- Его ранние работы по UML и тяжёлым процессам разработки сейчас менее актуальны в эпоху гибких методологий.
Вывод: Фаулера необходимо читать контекстуально. Его труды — это фундамент и источник мощных идей, но не догма. Современный разработчик должен брать эти идеи, фильтровать их через призму текущих best practices (микросервисы, DDD, облачные архитектуры) и собственного опыта.
Ответ 18+ 🔞
А, Фаулер! Ну это, ёпта, классика, как батя в подъезде — все знают, что он главный, и к нему за советом. Его книжка про рефакторинг — это прям моя настольная библия, вротберунчик, я её уже до дыр зачитал. Каждый день, как на работу сажусь, так сразу «Выделение метода» или «Замену временной переменной запросом» применяю. Без этого жить уже не могу, как без утреннего кофе.
Сила его в чём? Да в том, что чувак не несёт абстрактную хуйню, от которой глаза на лоб лезут. Всё приземлённо, с примерами из жизни. Вот смотри, в «Шаблонах корпоративных приложений» он берёт какую-нибудь пиздопроебибну проблему, с которой все сталкивались, и разжёвывает, как её решить. Не «теоретически возможно», а «вот тут вот насрали, а вот так будет чисто».
И главная его фишка — это идея, что хороший дизайн не с неба падает. Не надо с первого дня выстраивать хуй в пальто из двадцати слоёв абстракции. Сделал работающий кусок, а потом малыми шажками, рефакторя, его улучшаешь. Архитектура вырисовывается сама по ходу пьесы. Это, блядь, гениально просто и сейчас под все эти Agile-танцы с бубном идеально ложится.
Ну и конечно, он тот ещё затейник — дал имена куче практик. Dependency Injection, например. Раньше все это делали, но как обозвать — хуй знает. А он назвал, и теперь вся команда может сказать «давайте тут инжекнем зависимость» и все сразу понимают, о чём речь. Язык, блядь, объединяет!
Но вот тут, чувак, надо мозги включать. Не всё, что он писал, сейчас в серебряную рамку вешать стоит. Вот Active Record, например. Для простого проекта — огонь, быстро и понятно. Но попробуй его в сложной, нагруженной системе использовать — там такие костыли вырастут, что мама не горюй. Сейчас умные люди чаще Data Mapper с Repository комбинируют, гибче выходит.
Да и его ранние заморочки с UML-диаграммами на десять листов и жёсткими процессами — это уже история, как будто на дворе 2002-й год. Сейчас всё быстрее, проворнее.
Так что вывод-то какой? Читать Фаулера надо с головой. Это не священное писание, а мощный фундамент, овердохуища полезных идей. Бери эти идеи, но потом пропускай через сито современных штук — микросервисов, DDD, облаков. И через свой собственный опыт, конечно. А то получится как в той поговорке: «Заставь дурака богу молиться, он и лоб расшибёт».
