И вот вам немного интересных мыслей из отпуска, которыми очень хочется поделиться:
Информация – ключ к обобщению 🗝
Я вам люблю рассказывать всякие архитектурные принципы, лучшие практики. GRASP, GOF, чистая архитектура, DDD, и вот с курсом по Redux добавился Flux.
И, знаете, есть стойкое ощущение, что всё это говорит об одном. Как из притчи про слепцов и слона.
Приведу пример)
Есть принцип SRP из SOLID. Он говорит, что один модуль программы должен изменяться только по причине одного актора.
И я слышал размышление, что это правило – есть практический совет, как получить low coupling и high-cochesion. Так как потребности актора затрагивают только определённый набор модулей, и удовлетворение этого актора является задачей этого модуля. Что и определяет high cochesion. А взаимодействие акторов более ограничено, поэтому мы получаем low coupling
Если взять все архитектурные принципы и рядом их поставить, начиная с DRY YAGNY, продолжая SOLIG GRASP, и заканчивая DDD Clean Architecture FSD MVC MVVM
Есть устойчивое ощущение, что они говорят вообще об одном и том же, просто на разном уровне, и с разных сторон
Как будто нам не хватает какой то "Таблицы Менделеева", которая бы соединила все эти практики в единую систему, которая зиждилась бы на более абстрактных понятиях.
И таким абстрактным понятием может быть Информация
При подготовке к курсу по Redux, мне всё казалось. что мои размышление ватные. Как будто они подвешаны в воздухе и не имеют глубины.
Я начал эту глубину искать. В результате потратил часов 25 в копании понятий Состояние, Кэш, Стейт менеджер. И самым базовым понятием, на котором всё строится, стало понятие Информация.
Не просто так наша отрасль называется IT. Единственное, чем мы занимается — представляем, обрабатываем, передаём информацию.
Но почему то при рассуждении о качестве кода, мы вообще не пользуемся этим термином. Хотя если его добавить, всё начинает сиять новыми красками.
Вот несколько интересных тезисов 👇🏻
1. Любой код — информация по работе с информацией
2. DRY — должен быть один источник истины. В сущности мы не должны допускать копий информации. Похожий код может нести разную информацию. Разный код может быть копией информации
3. Копирование информации допустимо, если это кэш (Зависимая информация, которая не меняется отдельно от источника истины)
4. Приложения работают не с объектами, а с представлением информации об объектах (данными)
5. Разделение ответственности — это ограничение с какой частью информации об объекте будет работать модуль программы, и на каком уровне абстракции
6. Архитектура — это стратегия разделение информации по модулям, уровням абстракции. И механизмы обмена информацией
7. Любимая фраза начинающих архитекторов: Модуль А ничего не знает о модуле B — целиком про информацию
И это только лежащие на поверхности тезисы.
Буду продолжать копать, может сформулирую законченную модель на
Информация – ключ к обобщению 🗝
Я вам люблю рассказывать всякие архитектурные принципы, лучшие практики. GRASP, GOF, чистая архитектура, DDD, и вот с курсом по Redux добавился Flux.
И, знаете, есть стойкое ощущение, что всё это говорит об одном. Как из притчи про слепцов и слона.
Приведу пример)
Есть принцип SRP из SOLID. Он говорит, что один модуль программы должен изменяться только по причине одного актора.
И я слышал размышление, что это правило – есть практический совет, как получить low coupling и high-cochesion. Так как потребности актора затрагивают только определённый набор модулей, и удовлетворение этого актора является задачей этого модуля. Что и определяет high cochesion. А взаимодействие акторов более ограничено, поэтому мы получаем low coupling
Если взять все архитектурные принципы и рядом их поставить, начиная с DRY YAGNY, продолжая SOLIG GRASP, и заканчивая DDD Clean Architecture FSD MVC MVVM
Есть устойчивое ощущение, что они говорят вообще об одном и том же, просто на разном уровне, и с разных сторон
Как будто нам не хватает какой то "Таблицы Менделеева", которая бы соединила все эти практики в единую систему, которая зиждилась бы на более абстрактных понятиях.
И таким абстрактным понятием может быть Информация
При подготовке к курсу по Redux, мне всё казалось. что мои размышление ватные. Как будто они подвешаны в воздухе и не имеют глубины.
Я начал эту глубину искать. В результате потратил часов 25 в копании понятий Состояние, Кэш, Стейт менеджер. И самым базовым понятием, на котором всё строится, стало понятие Информация.
Не просто так наша отрасль называется IT. Единственное, чем мы занимается — представляем, обрабатываем, передаём информацию.
Но почему то при рассуждении о качестве кода, мы вообще не пользуемся этим термином. Хотя если его добавить, всё начинает сиять новыми красками.
Вот несколько интересных тезисов 👇🏻
1. Любой код — информация по работе с информацией
2. DRY — должен быть один источник истины. В сущности мы не должны допускать копий информации. Похожий код может нести разную информацию. Разный код может быть копией информации
3. Копирование информации допустимо, если это кэш (Зависимая информация, которая не меняется отдельно от источника истины)
4. Приложения работают не с объектами, а с представлением информации об объектах (данными)
5. Разделение ответственности — это ограничение с какой частью информации об объекте будет работать модуль программы, и на каком уровне абстракции
6. Архитектура — это стратегия разделение информации по модулям, уровням абстракции. И механизмы обмена информацией
7. Любимая фраза начинающих архитекторов: Модуль А ничего не знает о модуле B — целиком про информацию
И это только лежащие на поверхности тезисы.
Буду продолжать копать, может сформулирую законченную модель на