Рассказывает Максим Лядов, ведущий разработчик DD Planet
Обзор книг, которые помогли мне иначе взглянуть на привычные в разработке вещи. Рекомендую к прочтению всем, кто хочет не просто писать код, а понимать причины и цели каждого выбранного решения.
Как правило, пользователи форумов пишут о личном опыте: «Вот я делаю так», «Так правильнее». Можно найти ответы и в статьях, вроде «Что использовать: RabbitMQ или Kafka?». Кстати, очень важно читать комментарии, так как они бывают ценнее и информативнее статей.
Но когда дело касается более концептуальных вопросов — как правильно делать? — становится сложнее. Я как-то задумался, как обозначать DTO-объект (Data Transfer Object)? Стоит ли в конце писать UserDto или UserData. Прочитал много противоположных мнений, стал копать дальше и пришёл к логичному объяснению. Окончание в названии класса может показывать цель его существования: Repository, Factory, Command, Event. А Dto/Data может иметь самые разные целевые реализации, поэтому окончание следует добавлять не всегда, а в зависимости от обстоятельств.
Роберт Мартин
"Идеальный программист"
Какие soft skills должны быть у программиста и как их развивать
Программирование — относительно молодая специальность в рамках нашей цивилизации, появилась в XX веке. Когда 15-20 лет назад у людей спрашивали, кто такие программисты, первым на ум приходило клише из анекдотов — гики, которые круглосуточно сидят онлайн и даже отдыхают за компьютером. Тогда программистов считали своего рода фриками, и работодатели относились к этому снисходительно — мол, странный, зато помогает решать наши бизнес-задачи.
Но времена меняются, индустрия стремительно развивается, большую роль сыграла информатизация — и такой образ уже совершенно не соответствует реальности. Требования к разработчикам ровно такие же, как к экономистам, инженерам или менеджерам. Книга «Идеальный программист» позволяет понять, какими качествами должен обладать профессионал и как себя вести. Автор уделяет больше всего внимания ответственности, коммуникабельности, проводит небольшой ликбез по психологии и оценке персонала.
Важный момент, постоянно встречающийся в реальной жизни, — неумение корректно говорить «да» и «нет». Нельзя обещать то, что ты не выполнишь. Наверное, у каждого был такой диалог с менеджером проекта:
Когда программистам предлагают заведомо невыполнимые условия и они соглашаются, начинается, мягко говоря, «некачественный код», который ведет к печальным последствиям. Профессионал в первую очередь отвечает за качество работы и должен объективно оценивать сроки.
Автор приводит и обратный пример: как говорить «да». Например, клиент указал срок — задачу нужно выполнить за неделю. Менеджер оценивает её по часам и озвучивает, что это невозможно, всё, расходимся. В таком случае разработчик должен выделить главное: как решить бизнес-задачу заказчика? Часто бывает, что в задаче много дополнений, не критически важных на текущий момент, а главную бизнес-задачу можно сделать за два дня.
Я встречал разных разработчиков: «Что мне сказали, то я и сделал», «Мне не написали», «Я ничего не знаю», «Менеджер тут не отметил галочкой». Люди стараются снять с себя ответственность, разумеется, так нельзя.
Также некоторые думают: «Компания должна меня научить». Работодатель никому ничего не должен, профессионал сам себя развивает. Тут тоже как со спортом: одни ищут способы, другие — оправдания. Если совсем нет времени, удобно, например, читать в метро. К этому настолько привыкаешь, что в телефоне сидеть уже не интересно.
Что еще полезного в книге? Много моментов по написанию кода и его тестированию, как проводится отладка, что такое творческий кризис, отставание от графика, как «надежда, спешка, сверхурочные», влияют на нашу работу. Как заниматься планированием, проводить оценку проекта, какие есть методологии: широкополосный дельфийский метод, Birt, метод быстрого голосования, Покер планирование.
Роберт Мартин — известный программист со стажем, реализовал огромное число проектов. В книге много примеров из реальной жизни, очень узнаваемых вплоть до конкретных проектов, людей, и, самое интересное, видишь в них себя.
Роберт Мартин
"Чистый код: создание, анализ, рефакторинг"
Матчасть по написанию кода: как сделать его логичным и понятным для дальнейшей поддержки
Книга о низкоуровневом программировании будет интересна опытным специалистам. Автор даёт обоснование многим вещам, до которых я, например, хоть и дошел самостоятельно в профессиональной деятельности, но никогда не задумывался, почему это работает именно так.
Как правильно называть функции, классы, методы, переменные, какие должны быть блоки, отступы.
Какой размер функций, какое количество строк кода в них должно быть, как их разбивать. Всё это также касается и классов. Иной раз я задумываюсь, как расположить методы в классе, в каком порядке. В книге очень хорошо описано, как и, главное, почему. Я начал так делать, и действительно стало удобнее.
Автор уделил много внимания принципам solid. Принципы сформулировали разные программисты в разное время, они, можно сказать, эволюционировали, а потом из них сделали аббревиатуру. Доступно описаны объекты и структуры данных.
Один из принципов solid — это принцип открытости/закрытости. На любом доступном ресурсе на эту тему опубликованы примеры про switch-case и полиморфизм. Но здесь другой подход, ведь полиморфизм — не всегда лучший выбор, и его не везде можно использовать.
Интересно было читать про комментарии: должны ли быть в коде комментарии и какие? Как говорит автор, хороший комментарий — тот, который не нужен. Нужны ли комментарии, которые генерируются нашими IDE?
Автор на практике производит рефакторинг: построчно разбирает программу, объясняет ошибки. На примерах объясняет, когда использовать конструкции try…catch, exception, в чём опасность возвращать null, как формировать архитектуру в общем виде. Большая глава посвящена многопоточности.
В конце книги есть чек-лист по всем изученным правилам. Очень полезно для Code review. Можно взять любой код, пулреквест и проверить по списку. Например, комментарии: неуместная информация, устаревший комментарий, избыточный комментарий, плохо написанный комментарий, закомментированный код.
Книга «Чистый код» формирует ценности, каким должен быть код, программирование, архитектура. Но сквозь всю книгу автор пытается донести идею:
Роберт Мартин
"Чистая Архитектура. Искусство разработки программного обеспечения"
О принципах низкоуровневого программирования с позиции общей архитектуры
Благодаря этой книге я начал по-другому воспринимать принципы программирования. Везде пишут, что класс должен отвечать за что-то конкретное — ни больше ни меньше. На самом деле принцип звучит по-другому: у класса должна быть одна причина для изменения.
То же касается и архитектуры. Автор рассматривает компонентный подход: как архитектуру разбивать на компоненты, что такое независимость, границы, уровни, политики, бизнес-правила. Здесь же разбор парадигм, нюансы и отличия структурного, объектно-ориентированного, функционального программирования. Мы все знаем, что такое инкапсуляция, наследование, полиморфизм. Но вы знали, что эти понятия существовали и до объектно-ориентированного программирования? Автор доказывает это реальными примерами.
Как оценить эффективность архитектуры? Казалось бы, философский вопрос, но в этой книге вы найдете конкретные цифры и формулы. Очень полезно разработчикам, которые создают систему с нуля. Многие моменты о том, как правильно проектировать архитектуру, встают на свои места.
Книга легко читается, автор ведет диалог с читателем, добавляет юмор и наглядные примеры. Интересно читать о развитии сферы: как в 70-е “большие данные” обрабатывали с помощью перфокарт, а профессия считалась женской — треть разработчиков были женщины.
Эрик Эванс
"Предметно-ориентированное проектирование, структуризация сложных программных систем"
Для разработчиков крупных систем о бизнес-логике и важности прямого контакта с клиентом
Эрик Эванс первым формализовал Domain-driven design. Задача ООП — построить упрощенную модель реального мира, его устройства с определенными оговорками. В основе этой методологии лежит единый язык и ограниченные контексты, а уже потом шаблоны, стратегии, тактики и т. д.
Для описания мира существуют разные методы моделирования: математика, графы, системы дифференциальных уравнений. Например, модель «хищник-жертва» отражает, как меняется численность хищников и жертв в природе. Это система дифференциальных уравнений показывает корреляцию двух графиков — когда появляется больше хищников, становится меньше жертв, и наоборот.
Разработать программу, отражающую модель реального мира, только сначала кажется сложно. На самом деле не нужны ни комментарии, ни документация — открываешь код и видишь реальное поведение реальных объектов. Здесь очень важно знать, как действует предметная область программы.
Возвращаемся к тому, что разработчик не должен общаться с внешним миром через тимлида или менеджера, не зная заказчика проекта в лицо. Важно тесно общаться с экспертами предметной области, использовать терминологию заказчика. Чем больше программисты командно погружаются в предметную область, тем лучше.
Например, одно и то же понятие в банковской и в бухгалтерской сферах может обозначать разные вещи. У меня есть хороший пример, на одном из проектов было понятие «офис продаж». С одной стороны — это реальное помещение, где стоят продавцы. В другом контексте — это регион, адрес, элемент регионального дерева, по которому фильтруются документы. А в третьем — это еще и учетная запись, так как учетка есть не только у каждого сотрудника, но и у общего офиса продаж.
Не нужно пытаться соединить эти объекты, это разные сущности. Правильно будет их разграничить и выделить контексты: контекст региональности, контекст управления доступами, контекст географии торговых точек. Эта книга отлично объясняет, как наладить контакт между ограниченными контекстами.
Также в ней собрано много паттернов, что такое factory, репозиторий, агрегаты, какие есть службы, когда использовать службы, объекты значения, сущности — расписано на примерах.
Примечание: советую повторить UML, так как в книге много диаграмм.
Вон Вернон
"Реализация методов предметно-ориентированного проектирования"
Domain-Driven Design на примере вымышленного стартапа
В этой книге больше практики. Через всю книгу проходит история команды вымышленного стартапа, которая с нуля разрабатывает ERP-систему. На пути они встречают разнообразные сложности. В каждой главе есть сноска — как команда решает вопрос, что откладывает на ближайшую перспективу и почему.
Далее рассматривает сущности, вплоть до мелочей. Например, уникальный идентификатор — какой он должен быть и как его правильно делать? Есть много интересных моментов. Какие есть объекты значений, как это связывается с URN. Примеры написаны на Java, но без труда можно интерпретировать на свой язык.
Приводится удобная классификация интеграций ограниченных контекстов. Какие бывают способы интеграции между системами, контекстами «заказчик — поставщик», служба с открытым протоколом, общедоступный язык. Часто бывает, что команды разработки неправильно взаимодействуют. К примеру, первая команда работает по принципу «заказчик-поставщик», а вторая совсем по-другому. У них разные ожидания и сложно договориться. Важно на ранних этапах выяснять все вопросы и выбрать стратегию.
Примечание: в издании «Диалектика» плохой перевод, есть логические ошибки, поэтому лучше читать в оригинале.
habr.com
Обзор книг, которые помогли мне иначе взглянуть на привычные в разработке вещи. Рекомендую к прочтению всем, кто хочет не просто писать код, а понимать причины и цели каждого выбранного решения.
- «Идеальный программист», Роберт Мартин
- «Чистый код: создание, анализ, рефакторинг», Роберт Мартин
- «Чистая Архитектура. Искусство разработки программного обеспечения», Роберт Мартин
- «Предметно-ориентированное проектирование, структуризация сложных программных систем», Эрик Эванс
- «Реализация методов предметно-ориентированного проектирования», Вон Вернон
Книги или интернет?
Я начал знакомиться с профлитературой по программированию ещё в школьные годы. Тогда были популярны учебники по конкретным инструментам, например, по 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, так как в книге много диаграмм.
Вон Вернон
"Реализация методов предметно-ориентированного проектирования"
Domain-Driven Design на примере вымышленного стартапа
В этой книге больше практики. Через всю книгу проходит история команды вымышленного стартапа, которая с нуля разрабатывает ERP-систему. На пути они встречают разнообразные сложности. В каждой главе есть сноска — как команда решает вопрос, что откладывает на ближайшую перспективу и почему.
Далее рассматривает сущности, вплоть до мелочей. Например, уникальный идентификатор — какой он должен быть и как его правильно делать? Есть много интересных моментов. Какие есть объекты значений, как это связывается с URN. Примеры написаны на Java, но без труда можно интерпретировать на свой язык.
Приводится удобная классификация интеграций ограниченных контекстов. Какие бывают способы интеграции между системами, контекстами «заказчик — поставщик», служба с открытым протоколом, общедоступный язык. Часто бывает, что команды разработки неправильно взаимодействуют. К примеру, первая команда работает по принципу «заказчик-поставщик», а вторая совсем по-другому. У них разные ожидания и сложно договориться. Важно на ранних этапах выяснять все вопросы и выбрать стратегию.
Примечание: в издании «Диалектика» плохой перевод, есть логические ошибки, поэтому лучше читать в оригинале.
Вместо заключения
Эти книги – отличный пример “настольных” руководств. Они не расскажут “как”, а объяснят – “почему” и “для чего”. Зная ответ на фундаментальные, пусть и кажущиеся абстрактными, вопросы, вы сможете решать конкретные проблемы разработки самостоятельно и осознанно.Профессиональная литература для разработчиков: Роберт Мартин, Эрик Эванс, Вон Вернон
Наша компания постоянно проводит митапы для сотрудников: на них мы делимся опытом, интересными фишками – и прочитанными нами книгами. Недавно наш ведущий разработчик Максим Лядов рассказал о том,...
habr.com