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