Мы уже обсудили высокоуровневое разделение проекта на модули и микросервисы, чтобы у нас было меньше связей между отдельными подсистемами. И сделали это на примере сложной растущей программной системы для большого завода жэлезобетонных изделий с линейкой бетона с ароматом клубники для VIP-клиентов.
Там мы вскользь упомянули принципы и паттерны SOLID и GRASP в применении к модулям. Эта тема интересна сама по себе и по ней всегда много вопросов от зрителей. Так что будет полезно рассмотреть эту тему отдельно на примерах не только высокоуровневых модулей, но и на более низкоуровневом разделении программного кода на процедуры, функции или классы.
Проекты обычно только растут, становясь всё сложнее и сложнее. Со временем программисту всё труднее вносить изменения и работа делается всё дольше и дольше. И всё актуальнее становится вопрос, как облегчить жизнь программиста и заказчика при постоянном росте проекта. Это нам и надо решить.
Делаете ли вы свой проект или развиваете чужой – такие вещи нужно осознать как можно раньше, чтобы со временем не превратить код проекта в кашу.
И даже если вам сейчас не хочется это применять в проекте у себя на работе, то вы можете потренироваться с этим в своих личных проектах, чтобы потом с этим опытом пройти собеседование в более интересную компанию.
В статьях и книгах порой просто перечисляют буквы из SOLID, но забывают упомянуть, зачем это нужно. И часто приводят примеры кода, забыв раскрыть полные причины, которые автора к этому варианту кода привели. В итоге по коду не очень понятно, что там происходит.
Прочитав или посмотрев такие материалы, многие бросаются что-то из этого применить у себя. Но из-за непонимания изначальной идеи программист либо делает криво, либо не там, где это актуально. В итоге возникает ощущение, что всё это бесполезно и только мешает в работе.
Зубрить какие-нибудь принципы или паттерны вроде SOLID или GRASP ради собеседований бесполезно. Это образ мышления, которым нужно жить. А мы с вами в скринкастах и стримех привыкли не зубрить, а докапываться до смысла всего того, что делаем. Пытаемся найти исходные причины и пережить всё то, о чём думал автор когда что-то изобретал. Что не нравилось автору изначально и к какому решению он пришёл в итоге. Так мы с вами можем поступить и здесь. И поняв основную идею подобных архитектурных принципов нам сразу станет очевидно, какие паттерны GoF в коде смогут нам для этого пригодиться.
Если пускать код проекта на самотёк, не прилагая усилий к его улучшению, то работать обычно становится всё сложнее. Чем больше лишних зависимостей, тем больше риска что-то сломать. А без понимания ключевых идей сложно что-то применять.
Мы часто опираемся на эти принципы во многих скринкастах, когда программируем новый код и когда рефакторим старый. Этого матерала много, но он пока разрозненный. Так что будет полезно собрать всё это и составить общую картину.
Скрытый текст. Доступен только зарегистрированным пользователям.Нажмите, чтобы раскрыть...
Новые складчины | страница 8
Категории
Страница 8 из 34

Самые простые автотесты вы сможете создать уже через пару дней.
![[IMG]](proxy14p.php?image=https%3A%2F%2Fi123.fastpic.org%2Fbig%2F2024%2F0713%2Fa1%2Fea511b1455bb1df70b087b1f6608e1a1.jpg&hash=5b1a375012a900f6d7cfe54846f2a16b&v=4)
![[IMG]](proxy14p.php?image=https%3A%2F%2Fi.imgur.com%2FdxKBKRz.png&hash=da4669c468f55d713a996c599e2a09ac&v=4)