Разработка программного обеспечения сегодня — обычная профессия. В программировании нет ничего сложного, — разве что, как говорит один из моих коллег, именование переменных и проблемы с кешированием, всё остальное — устоявшийся процесс с чётко определёнными ролями и рутинными операциями. Даже ввод целых блоков кода с клавиатуры и некоторые виды рефакторинга автоматизируются в современных IDE. И чтобы хоть как-то поддерживать себя в форме (всё-таки сидячая работа, отсутствие физической активности), приходится поднимать, носить, перелистывать и даже иногда читать много объёмных книг. Чем тяжелее, тем лучше, — особенно ценятся экземпляры, содержащие около или более тысячи страниц.

Для себя я разделил полезную IT-литературу на три категории: ремесленная, научная и агитационная. Первая помогает улучшить процесс разработки, разобраться в каком-то языке программирования или технологии, вторая — глубоко погрузиться в какую-то задачу, понять основные принципы решения различных проблем, сформировать целостный взгляд на вещи. Эти два типа отличает сдержанный эмоциональный фон текста, богатый ссылками на другие источники контекст и основательно подкреплённые фактами из реальных успешных (или не очень) проектов описания подходов и методик. Книги третьего типа пишут евангелисты. Недавно мне довелось прочитать «Elegant Objects» Егора Бугаенко. Многие устоявшиеся вещи, которые мы привыкли считать лучшими практиками, просто и понятно названы в книге злом: геттеры, сеттеры, ORM, DI контейнеры и прочие, казалось бы, облегчающие работу программиста техники.

Впрочем, такие эмоционально насыщенные тексты, если в них есть последовательный подход (в «Elegant Objects» это пуристский взгляд на ООП), а не только шаманизм и истерия, обычно заставляют задуматься. Например, те же геттеры и сеттеры всегда выглядели для меня подозрительно. С одной стороны, что-то они всё-таки инкапсулируют. С другой — все частные свойства как будто бы и перестают быть частными. Вообще, когда я с помощью IDE автоматически создаю набор этих методов для свойств какого-нибудь DTO, меня начинают мучить сомнения в необходимости программистской человеческой прослойки между идеей продукта и её реализацией.

Если приехать в незнакомый город, то некоторые детали замечаешь лучше местных жителей, которые ходят по этим улицам каждый день. С привычным процедурно-имеративным подходом мы, возможно, не совсем правильно воспринимаем объекты. Автор «Elegant Objects» очень уважительно относится к ним, соблюдая границы их частных владений. Основной принцип — инкапсуляция, последовательно упоминается на протяжении всего текста. Все эти сверкающие чистотой стеклянные здания чистого ООП кажутся чужими в стране промышленной разработки программного обеспечения. И в этом смысле книга позволяет посмотреть на привычные вещи незамутнённым взглядом иностранца в незнакомом городе.

В то же время мне трудно стать религиозным фанатиком. Если в работе используется инструмент, позволяющий сократить рутинные операции в целом ускорить процесс, я буду его использовать. Особенно когда такая практика уже показала свои преимущества при разработке большого числа промышленных проектов. Тот же IoC контейнер хотя и побуждает нас «неуважительно» относиться к объектам, отбирая у них право рождения, в то же время позволяет нам меньше думать о том, как нам создавать каждый объект в системе. Задача поставлена на конвейер.

Евангелисты намеренно, неистово отказываются от исторического контекста, в котором варятся их идеи, бурей и натиском разгоняя замшелых филистеров, сторонников геттеров, сеттеров, DTO, IoC и прочих устоявшихся формул и заклинаний. В то же время мы понимаем, что это, скорее всего, ловкий трюк, призванный захватить наше внимание, попытка взглянуть на, казалось бы, решённые проблемы с другой стороны. Может быть, даже самые яростные поборники устоявшихся процессов, отвлёкшись от баталий в комментариях и конвейерного программирования, будут пытаться на своём домашнем проекте решать предложенные новаторами задачи. Для меня подобная литература интересна именно с этой стороны. При первом прочтении очередного блока кода в тексте я могу сначала оценить его элегантность. Потом я подумаю, где бы это можно было применить в тех проектах, над которыми я сейчас работаю, как это может улучшить процесс. Если второе не очевидно, то вера автора в свою правоту побуждает меня искать решение проблемы, пытаться понять, почему код написан так, а не иначе. Благодаря евангелистам программирование перестаёт быть рутиной.

https://habrahabr.ru/post/334766/