Доступно [deworker.pro] Большой стрим про SOLID и GRASP (Дмитрий Елисеев)

​

Мы уже обсудили высокоуровневое разделение проекта на модули и микросервисы, чтобы у нас было меньше связей между отдельными подсистемами. И сделали это на примере сложной растущей программной системы для большого завода жэлезобетонных изделий с линейкой бетона с ароматом клубники для VIP-клиентов.

Там мы вскользь упомянули принципы и паттерны SOLID и GRASP в применении к модулям. Эта тема интересна сама по себе и по ней всегда много вопросов от зрителей. Так что будет полезно рассмотреть эту тему отдельно на примерах не только высокоуровневых модулей, но и на более низкоуровневом разделении программного кода на процедуры, функции или классы.

Проекты обычно только растут, становясь всё сложнее и сложнее. Со временем программисту всё труднее вносить изменения и работа делается всё дольше и дольше. И всё актуальнее становится вопрос, как облегчить жизнь программиста и заказчика при постоянном росте проекта. Это нам и надо решить.

Делаете ли вы свой проект или развиваете чужой – такие вещи нужно осознать как можно раньше, чтобы со временем не превратить код проекта в кашу.

И даже если вам сейчас не хочется это применять в проекте у себя на работе, то вы можете потренироваться с этим в своих личных проектах, чтобы потом с этим опытом пройти собеседование в более интересную компанию.

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

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

Зубрить какие-нибудь принципы или паттерны вроде SOLID или GRASP ради собеседований бесполезно. Это образ мышления, которым нужно жить. А мы с вами в скринкастах и стримех привыкли не зубрить, а докапываться до смысла всего того, что делаем. Пытаемся найти исходные причины и пережить всё то, о чём думал автор когда что-то изобретал. Что не нравилось автору изначально и к какому решению он пришёл в итоге. Так мы с вами можем поступить и здесь. И поняв основную идею подобных архитектурных принципов нам сразу станет очевидно, какие паттерны GoF в коде смогут нам для этого пригодиться.

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

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