Профессиональная литература для разработчиков: Роберт Мартин, Эрик Эванс, Вон Вернон

• Содержание
• Книги или интернет?
• Роберт Мартин, «Идеальный программист»
• Роберт Мартин, "Чистый код: создание, анализ, рефакторинг"
• Роберт Мартин, "Чистая Архитектура. Искусство разработки программного обеспечения"
• Эрик Эванс, "Предметно-ориентированное проектирование, структуризация сложных программных систем"

Обзор книг, которые помогли мне иначе взглянуть на привычные в разработке вещи. Рекомендую к прочтению всем, кто хочет не просто писать код, а понимать причины и цели каждого выбранного решения.

Книги или интернет?

Я начал знакомиться с профлитературой по программированию ещё в школьные годы. Тогда были популярны учебники по конкретным инструментам, например, по C++, PHP или IDE. Такие мануалы были полезны junior-разработчикам, так как в любой сложной ситуации на страницах можно найти решение и ответ на вопрос: как реализовать запрос, нотацию, найти функцию, метод. Но в современном мире потребности в таких книгах практически нет, так как их заменили тематические интернет-сообщества.

Как правило, пользователи форумов пишут о личном опыте: «Вот я делаю так», «Так правильнее». Можно найти ответы и в статьях, вроде «Что использовать: RabbitMQ или Kafka?». Кстати, очень важно читать комментарии, так как они бывают ценнее и информативнее статей.  

Но когда дело касается более концептуальных вопросов — как правильно делать? — становится сложнее. Я как-то задумался, как обозначать DTO-объект (Data Transfer Object)? Стоит ли в конце писать UserDto или UserData. Прочитал много противоположных мнений, стал копать дальше и пришёл к логичному объяснению. Окончание в названии класса может показывать цель его существования: Repository, Factory, Command, Event. А Dto/Data может иметь самые разные целевые реализации, поэтому окончание следует добавлять не всегда, а в зависимости от обстоятельств. 

На фундаментальные вопросы невозможно ответить готовым решением, нужно понимать, почему выбран тот или иной подход. 

Как правильно проектировать, какая структура программы должна быть, где разделяется на компоненты, на какие уровни, как называть классы, как их лучше сопоставлять, как организовать… В интернете по теме можно найти только обрывочную информацию, которую придется собирать как мозаику. А профессиональная литература как раз позволяет получить и структурировать важные вопросы по архитектуре, делопроизводству, разработке ПО. Книги помогают прояснить картину и расставить точки над i — как все-таки правильно и почему.

Роберт Мартин, «Идеальный программист» Какие soft skills должны быть у программиста и как их развивать

Программирование — относительно молодая специальность в рамках нашей цивилизации, появилась в XX веке. Когда 15-20 лет назад у людей спрашивали, кто такие программисты, первым на ум приходило клише из анекдотов — гики, которые круглосуточно сидят онлайн и даже отдыхают за компьютером. Тогда программистов считали своего рода фриками, и работодатели относились к этому снисходительно — мол, странный, зато помогает решать наши бизнес-задачи. 

Но времена меняются, индустрия стремительно развивается, большую роль сыграла информатизация — и такой образ уже совершенно не соответствует реальности. Требования к разработчикам ровно такие же, как к экономистам, инженерам или менеджерам. Книга «Идеальный программист» позволяет понять, какими качествами должен обладать профессионал и как себя вести. Автор уделяет больше всего внимания ответственности, коммуникабельности, проводит небольшой ликбез по психологии и оценке персонала. 

Важный момент, постоянно встречающийся в реальной жизни, — неумение корректно говорить «да» и «нет». Нельзя обещать то, что ты не выполнишь. Наверное, у каждого был такой диалог с менеджером проекта:

- Сколько займёт эта задача? 

- Неделю. 

- Надо успеть за два дня.

В таком случае важно сказать «нет». Представьте, вы приходите к врачу и говорите «У меня мало времени, давайте не будем делать подготовку к операции, а сразу разрежем и зашьем». Если он согласится, то придётся привлечь его к ответственности, это не вызывает вопросов. 

Когда программистам предлагают заведомо невыполнимые условия и они соглашаются, начинается, мягко говоря, «некачественный код», который ведет к печальным последствиям. Профессионал в первую очередь отвечает за качество работы и должен объективно оценивать сроки.  

Автор приводит и обратный пример: как говорить «да». Например, клиент указал срок — задачу нужно выполнить за неделю. Менеджер оценивает её по часам и озвучивает, что это невозможно, всё, расходимся. В таком случае разработчик должен выделить главное: как решить бизнес-задачу заказчика? Часто бывает, что в задаче много дополнений, не критически важных на текущий момент, а главную бизнес-задачу можно сделать за два дня.

Я встречал разных разработчиков: «Что мне сказали, то я и сделал», «Мне не написали», «Я ничего не знаю», «Менеджер тут не отметил галочкой». Люди стараются снять с себя ответственность, разумеется, так нельзя. 

Обязанность любого профессионала — всё выяснить и решить конкретную бизнес-задачу.

В книге правильный взгляд, как должен учиться и развиваться разработчик. Способность учиться важно тренировать, как мышцы. Иногда встречаю закостенелых разработчиков, которые 10 лет делают одно и то же. 

Также некоторые думают: «Компания должна меня научить». Работодатель никому ничего не должен, профессионал сам себя развивает. Тут тоже как со спортом: одни ищут способы, другие — оправдания. Если совсем нет времени, удобно, например, читать в метро. К этому настолько привыкаешь, что в телефоне сидеть уже не интересно. 

Что еще полезного в книге? Много моментов по написанию кода и его тестированию, как проводится отладка, что такое творческий кризис, отставание от графика, как «надежда, спешка, сверхурочные», влияют на нашу работу. Как заниматься планированием, проводить оценку проекта, какие есть методологии: широкополосный дельфийский метод, Birt, метод быстрого голосования, Покер планирование. 

Роберт Мартин — известный программист со стажем, реализовал огромное число проектов. В книге много примеров из реальной жизни, очень узнаваемых вплоть до конкретных проектов, людей, и, самое интересное, видишь в них себя.

Роберт Мартин, "Чистый код: создание, анализ, рефакторинг"   Матчасть по написанию кода: как сделать его логичным и понятным для дальнейшей поддержки

Книга о низкоуровневом программировании будет интересна опытным специалистам. Автор даёт обоснование многим вещам, до которых я, например, хоть и дошел самостоятельно в профессиональной деятельности, но никогда не задумывался, почему это работает именно так. 

Как правильно называть функции, классы, методы, переменные, какие должны быть блоки, отступы. Какой размер функций, какое количество строк кода в них должно быть, как их разбивать. Всё это также касается и классов. Иной раз я задумываюсь, как расположить методы в классе, в каком порядке. В книге очень хорошо описано, как и, главное, почему. Я начал так делать, и действительно стало удобнее. 

Автор уделил много внимания принципам solid. Принципы сформулировали разные программисты в разное время, они, можно сказать, эволюционировали, а потом из них сделали аббревиатуру. Доступно описаны объекты и структуры данных. 

Один из принципов solid — это принцип открытости/закрытости. На любом доступном ресурсе на эту тему опубликованы примеры про switch-case и полиморфизм. Но здесь другой подход, ведь полиморфизм — не всегда лучший выбор, и его не везде можно использовать.    

Интересно было читать про комментарии: должны ли быть в коде комментарии и какие? Как говорит автор, хороший комментарий — тот, который не нужен. Нужны ли комментарии, которые генерируются нашими IDE?

Автор на практике производит рефакторинг: построчно разбирает программу, объясняет ошибки. На примерах объясняет, когда использовать конструкции try…catch, exception, в чём опасность возвращать null, как формировать архитектуру в общем виде. Большая глава посвящена многопоточности. 

В конце книги есть чек-лист по всем изученным правилам. Очень полезно для Code review. Можно взять любой код, пулреквест и проверить по списку. Например, комментарии: неуместная информация, устаревший комментарий, избыточный комментарий, плохо написанный комментарий, закомментированный код.  

Книга «Чистый код» формирует ценности, каким должен быть код, программирование, архитектура. Но сквозь всю книгу автор пытается донести идею:  

В программировании нет золотых правил и универсальных формул, не существует идеальной архитектуры. Всё всегда зависит от обстоятельств — человек должен думать и подбирать решение в зависимости от ситуации.

Примечание: все примеры в книге — на Java, но это не играет роли. Если вы, например, PHP-разработчик, то небольшая разница в синтаксисе не помешает понять суть.

Роберт Мартин, "Чистая Архитектура. Искусство разработки программного обеспечения"   О принципах низкоуровневого программирования с позиции общей архитектуры

Благодаря этой книге я начал по-другому воспринимать принципы программирования. Везде пишут, что класс должен отвечать за что-то конкретное — ни больше ни меньше. На самом деле принцип звучит по-другому: у класса должна быть одна причина для изменения. 

То же касается и архитектуры. Автор рассматривает компонентный подход: как архитектуру разбивать на компоненты, что такое независимость, границы, уровни, политики, бизнес-правила. Здесь же разбор парадигм, нюансы и отличия структурного, объектно-ориентированного, функционального программирования. Мы все знаем, что такое инкапсуляция, наследование, полиморфизм. Но вы знали, что эти понятия существовали и до объектно-ориентированного программирования? Автор доказывает это реальными примерами. 

Как оценить эффективность архитектуры? Казалось бы, философский вопрос, но в этой книге вы найдете конкретные цифры и формулы. Очень полезно разработчикам, которые создают систему с нуля. Многие моменты о том, как правильно проектировать архитектуру, встают на свои места.

Архитектура — это не количество серверов и схема их расположения (это топология). Монолит, микросервис или сервис — это тоже не архитектура. Архитектура — это разделение слоев, уровней и вариантов их использования таким образом, чтобы их оставалось как можно больше. Чтобы мы в любой момент могли поменять базу данных, добавить мобильное приложение к веб-сайту без особых усилий.  

Предметная область, бизнес-правила — это верхнеуровневые абстракции. Следом идут варианты использования — само приложение. А база данных, фреймворк, веб- или натив, это все детали. Правильно спроектированная программная система не зависит от того, будет ли это веб-приложение или мобильное, нативное, консольное и т. д. Это всего лишь средства ввода и вывода, это низкоуровневое. И чем ниже этот уровень, чем ближе к средствам ввода и вывода, тем менее значимая это деталь. 

Книга легко читается, автор ведет диалог с читателем, добавляет юмор и наглядные примеры. Интересно читать о развитии сферы: как в 70-е “большие данные” обрабатывали с помощью перфокарт, а профессия считалась женской — треть разработчиков были женщины. 

Эрик Эванс, "Предметно-ориентированное проектирование, структуризация сложных программных систем" Для разработчиков крупных систем о бизнес-логике и важности прямого контакта с клиентом

Эрик Эванс первым формализовал Domain-driven design. Задача ООП — построить упрощенную модель реального мира, его устройства с определенными оговорками. В основе этой методологии лежит единый язык и ограниченные контексты, а уже потом шаблоны, стратегии, тактики и т. д.

Для описания мира существуют разные методы моделирования: математика, графы, системы дифференциальных уравнений. Например, модель «хищник-жертва» отражает, как меняется численность хищников и жертв в природе. Это система дифференциальных уравнений показывает корреляцию двух графиков — когда появляется больше хищников, становится меньше жертв, и наоборот. 

Разработать программу, отражающую модель реального мира, только сначала кажется сложно. На самом деле не нужны ни комментарии, ни документация — открываешь код и видишь реальное поведение реальных объектов. Здесь очень важно знать, как действует предметная область программы. 

Возвращаемся к тому, что разработчик не должен общаться с внешним миром через тимлида или менеджера, не зная заказчика проекта в лицо. Важно тесно общаться с экспертами предметной области, использовать терминологию заказчика. Чем больше программисты командно погружаются в предметную область, тем лучше.

Например, одно и то же понятие в банковской и в бухгалтерской сферах может обозначать разные вещи. У меня есть хороший пример, на одном из проектов было понятие «офис продаж». С одной стороны — это реальное помещение, где стоят продавцы. В другом контексте — это регион, адрес, элемент регионального дерева, по которому фильтруются документы. А в третьем — это еще и учетная запись, так как учетка есть не только у каждого сотрудника, но и у общего офиса продаж. 

Не нужно пытаться соединить эти объекты, это разные сущности. Правильно будет их разграничить и выделить контексты: контекст региональности, контекст управления доступами, контекст географии торговых точек. Эта книга отлично объясняет, как наладить контакт между ограниченными контекстами. 

Также в ней собрано много паттернов, что такое factory, репозиторий, агрегаты, какие есть службы, когда использовать службы, объекты значения, сущности — расписано на примерах. 

Примечание: советую повторить UML, так как в книге много диаграмм.