acces969
@acces969
Разработчик корпоративных приложений

Как повысить свои навыки в построении архитектуры сложных приложений?

Стаж работы программистом 6 лет, но отсутствие профильного образования дает о себе знать.
Начать клепать программу процедурно - легко. Начать построение простой архитектуры - легко. Проблемы начинаются, когда есть уже массивная, частично работающая программа, и оказывается, что некоторые части несостыковываются между собой или внешними источниками, или вовсе часть архитектуры нужно переделывать. Это неприятно - порой проще начать писать с нуля, чем копаться в тысячах строк.
Конечно, описанная ситуация уже редкость, меры приняты, но все же я понимаю, что нужно поднимать свои навыки в построении архитектуры. Понимаю, что сейчас я скорее низкоуровневый кодер, чем архитектор.
Сейчас читаю "Паттерны проектирования" от head first, чтобы хорошо знать базовые шаблоны программирования. Что еще посоветуете? Не слишком заумные, но и не для новичков.
Язык программирования, думаю, тут не важен, так как тут скорее теория
  • Вопрос задан
  • 3838 просмотров
Решения вопроса 1
bingo347
@bingo347
Crazy on performance...
Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

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

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

Ну и недавно решил освежить память и перечитать еще раз. И на этот раз уже были мысли вроде "так если делать по другому, потом проблемы вылезут тут и тут".
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
@Arlekcangp
Разработчик, Лид, Архитектор ПО
1. Хорошо помогает начать изучение с простых паттернов проектирования. Прежде всего это простые и понятные паттерны типа "стратегия", "команда", "итератор", "шаблонный метод", "посредник", "цепочка обязанностей". Изучив и поняв эти паттерны вы посмотрите на ООП по новому: не как просто структурированный код плюс данные в одном объекте, а именно как задумывалось его создателем - объект самостоятельная единица взаимодействующая с другими такими же посредством сообщений. Причём она является first class также как в функциональном программировании функция. К тому же на указанных паттернах строятся и остальные. Например, фабричный метод - это частный случай шаблонного метода. Так постепенно придет понимание куда и зачем применять различные паттерны.
2. Когда решаете какую-либо задачу, думайте о нескольких вариантах архитектуры для её решения. Далее старайтесь выбирать
вариант не на основе личных предпочтений или предыдущего опыта (не важно, положительного или отрицательного), а на основе анализа, какой из вариантов здесь реально потребуется с точки зрения дальнейшего развития проекта. Предыдущий опыт также надо учитывать, но все проекты разные, требования разные, и каждая ситуация может отличаться. Надо смотреть как могут изменяться или расшириться системные и функциональные требования (разумеется, для этого надо быть в контексте этих требований - т е знать их самих, манеру работы с проектом заказчика и т д) Во многих случаях, когда вы не сможете выбрать из-за недостатка информации, это логически подведёт вас задавать заказчику дополнительные вопросы. И через этот итеративный процесс приходит понимание, где и как применять паттерны.
3. Обратите внимание на паттерны ERP систем (для примера книга "Шаблоны корпоративных приложений" Мартин Фаулер) Особенное внимание надо уделить такому шаблону как инверсия зависимостей. Данный шаблон лично мне помог совершенно по другому взглянуть на ООП (во второй раз, уже после того как я стал применять другие паттерны ООП) Вот здесь https://blog.byndyu.ru/2009/12/blog-post.html очень понятно на мой взгляд описано (язык C# но всё тоже самое будет для любого ОО языка) Кроме того в этом блоге много всего по проектированию и рефакторингу.
4. Обратите внимание на книгу "Growing Object-Oriented Software, Guided by Tests" Стив Фриман Перевод на русский не гуглится, возможно его и нету. Но книга полезна тем, что в отличие от многих других книг по TDD в ней разбирается не только методика тестирования и написания тестов, но и принцип тест -> код -> рефакторинг. И разбирается на достаточно длинном примере. Из неё вы можете подчерпнуть привычку рефакторить, а не переписывать заново. Причём даже если у вас на проекте цикл другой - например тесты пишутся после функционала, всё равно образ мысли изменится и масштабный рефакторинг не будет вызывать непреодолимого желания выбросить и переписать с нуля.
5. По рефакторингу могу порекомендовать книгу "Работа с унаследованным кодом" Майкл Физерс. Кроме того об этом много статей в уже упомянутом блоге Александра Бындю. Грубо говоря я бы назвал ту подборку статей "как не переписывать и начать жить"
6. Ещё один блог где собрано большое количество полезных материалов по ООП, рефакторингу, проектированию, это блог Сергея Теплякова Вот ссылка на его подборку книг по теме: sergeyteplyakov.blogspot.com/2013/08/blog-post.html
7. Изучайте материалы постепенно. Не стоит сразу пытаться воткнуть только что полученные знания в первый попавшийся проект. Обсуждайте возможные решения с коллегами. Со временем они также станут поддерживать эту практику. Если есть возможность, попрактикуйте парное программирование. Причём не обязательно с более опытным коллегой. Иногда вопросы задаваемые наивным человеком заставляют задуматься гораздо крепче, чем ответы получаемые от мудрецов.
Ответ написан
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Читать книги на эту тему, работать на проектах, где более опытные коллеги строят сложные архитектуры, участвовать в этом посильно.
Ответ написан
Комментировать
heman
@heman
бэкенд разработчик на php
Идеально конечно попасть в большой проект с опытными коллегами.

Чистая архитектура полезная книга.

Мне помогла серия видео по запросу "модульный монолит".

ArchDays 2020 • Модульный монолит вместо микросервисов • Денис Цветцих (Epam)

Модульный PHP монолит как альтернатива микросервисной архитектуре - Юлия Николаева, iSpring

И самое главное серия статей Herberto Graça The Software Architecture Chronicles
https://habr.com/ru/post/427739/
https://herbertograca.com/2017/07/03/the-software-...

В голову заходит тяжело. Выше коллега писал про свой подход: постоянно пробовать то что узнал на практике и пересмотр решений.
Ответ написан
Комментировать
c3gdlk
@c3gdlk
Ментор в http://rubyboost.ru/
Старайтесь работать в компаниях и на проектах, на которых уделяют время написанию текстов. С тестами код легко рефакторить и можно пробовать довольно быстро разные варианты, сам быстро учишься.

Но с книгой намного лучше. Вы выбрали отличную книгу, пробуйте внедрять паттерны из нее. Хотя бы в мысленных экспериментах
Ответ написан
Комментировать
MDiMaI666
@MDiMaI666
Талантливый программист
Делать много много и расширять зону ответственности. И сам додумаешься. Главное будешь знать не как а зачем так делать. Только практика.
Ответ написан
Комментировать
@AlexSku
не буду отвечать из-за модератора
А всё-таки если немного заумную, то Functional Design and Architecture (Александр Гранин).
Ролик с пояснениями по FreeMonad.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы