С какой книги начать изучение проектирования по?

Question

[netrox]

У меня есть опыт разработки на Laravel ,а также на Java(Swing, JDBC, Hibernate). Какую книгу лучше выбрать для изучения проетирования ПО:
1) Паттерны проектирования(Эрик Фримен)
2) Введение в объектно-ориентированный анализ, проектирование и итеративную разработку(Крэг Ларман)

Comments

[sim3x]

Для кого начать?
Опишите свой уровень, хоть примерно

[DevMan]

netrox, лучше начинать с приведения названий книг и их авторов в вопросе, а не левыми ссылками.

[sim3x]

netrox, Какой у вас опыт, 0, 1, 5, 10 лет разработки?
На каких позициях: лид, синьйор,..?

[netrox]

sim3x, реальный опыт чуть больше года , но до этого тоже кодил так , что база есть.

[sim3x]

netrox,
0. Избегайте переводной литературы. Даже если ваш уровень английского ужасный
1. Такого типа литературу стоит читать после определенного колличества написанного кода. Те смотря на код в книге у вас будут всплывать моменты, когда вы писали подобный код и просто не знали, как называется данный паттерн
2. Если прочитать слишком рано, то может появится соблан писать паттернами, вместо решения задач
3. Если потребовали на собеседовании, то стоит сразу уточнить у собеседующего, какую именно книгу он посоветует и только ее прочитать

Для джуна (и далее) достаточно использовать подход
Keep It Simple Stupid

[netrox]

sim3x,
1)когда наступает это определённое количество написаного кода?
2)если я хочу правильно проектировать проект, что мне следует делать, чтобы не допускать ошибки?

[sim3x]

netrox,
1. Уровень мифического мидла. Вы сами узнаете, когда.
2. Допустить как можно больше ошибок, решить их, потом решить те ошибки, к которым привели ваши правки.
Не бояться совершать ошибки.
Запомнить на своем опыте, что нельзя правильно один раз что-то спроектировать и донести проект до пользователя без изменения проекта

Answer 1

[nexus478]

Проектирование приложений можно условно разбить на 2 уровня:
1. Уровень проекта.
Сюда входит понимание того, как приложение должно выглядеть в целом и из каких компонентов состоять, а также по каким принципам оно собирается взаимодействовать с внешним миром (если есть такая необходимость). Компоненты зависят от выбранной архитектуры - в случае монолитного приложения вам требуется понимать, как разбивать его на слои и в чем ответственность каждого слоя; в случае микросервисов вы также должны понимать, как очерчивать зоны ответственности и определять протоколы взаимодействия между ними.
Книги о том, как проектировать приложения на общем уровне:
1. Роберт Мартин. Чистая архитектура - очень короткая и простая книга, рекомендую начать с неё.
2. Эрик Эванс. Предметно-ориентированное проектирование (принципы + стратегические шаблоны).
3. Мартин Фаулер. Архитектура корпоративных приложений (часть 1).

Уровень 2. Уровень модулей (классов).
Когда вы спроектировали компоненты, из которых состоит ваше приложение, теперь надо спроектировать их внутренности - то есть разбить на более мелкие и конкретные модули. Тут вам пригодятся принципы объектно-ориентированное проектирования, принципы SOLID, паттерны.
Книги по уровню 2.
1. Банда четырех. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Тут важно не только сами паттерны, но принципы, по которым они строятся. Концентрируйтесь на принципах.
2. Роберт Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. Тут более подробно рассматривается объектно-ориентированный дизайн и принципы SOLID в сравнении с его "Чистой архитектурой".
3. Эрик Эванс. Предметно-ориентированное проектирование (тактические шаблоны).
4. Мартин Фаулер. Архитектура корпоративных приложений (часть 2).
5. Стивен Макконел. Совершенный код (сконцентрируйтесь на понимании Главного Технического Императива!).

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

Answer 2

[Evgeny Maltsev]

Привет! Обе книги из топика отличные и хорошо переведены. Что касается паттернов - их проблема в том, что многие примеры высосаны из пальца (а иначе никак). Изучая паттерны, у новичков возникает обычно две проблемы: 1) о, я понял как это работает, надо запихнуть этот паттерн тут, здесь, там 2) я не понимаю где вообще это можно использовать. Обе проблемы возникают из-за нехватки реального опыта. Лично я эту книгу изучал раза три с промежутками в год. И с каждым разом вышеописанных проблем становилось меньше и меньше. По поводу Крэга Лармана: я считаю эту книгу надо читать если Вы решили шагнуть на следующий уровень, уже имея как минимум 3+ года опыта. На Вашем месте я бы в фоне конечно изучал всякие абстрактные приёмы, паттерны, но основной упор сделал бы на изучение лучших практик именно в вашей области разработки, ведь именно они в будущем и будут рассеивать непонимание тех же самых паттернов.

Answer 3

[Максим Федоров]

Не стоит путать паттерны и проектирование. Да паттерны используются в проектировании систем, но они сами по себе не есть проектирование. Очень часто люди прочитают пару книжек по паттернам и начинают их использовать где нужно и где не нужно и считают что все их система имеет хорошую архитектуру - но в результате от такой "архитектура" возникает больше проблем чем пользы. Поэтому мой Вам совет отложите паттерны на потом: почитайте что-нибудь именно о проектировании, и его принципах. Хотя бы того же Роберта Мартина. Бесспорно обе книги стоит прочитать, но как по мне их нужно читать имея уже определенные навыки

Comments

[netrox]

1) Вы имеете в виду книгу "чистая архитектура" ? 2) Книга Крега Лармана по вашему не подойдёт ?

[Максим Федоров]

netrox,
1. И чистую архитектуру и Agile Software Development, Principles, Patterns and Practices.
2. У Лармана книга хорошая, и читать ее нужно 100%. Но вот именно с нее начинать как по мне не стоит