По поводу независимого размещения - преимущество в том, что это делает оба модуля А и Б легко переносимыми, при условии что контракт сохраняется и переносится вместе с ними. Просто не всегда это надо и для каждого контракта заводить отдельный модуль может быть абсолютно не рационально, в очень большой зависимости от контекста. Формально поводом для изменения системы станут изменения в бизнес требованиях, и в контексте каких-то задач эта гибкость будет просто не нужна, а только усложнит систему зря
Суть статьи верна, но автор не очень четко разделяет границы понятий, а иногда наоборот смешивает вещи в одно. Добавлю или болеек детально проговорю пару вещей:
- по поводу абстракций - это просто базовый принцип разработки любого ПО, вне зависимости от парадигмы программирования, но часто приписывающийся ООП - сущности должны зависеть от абстракций и не конкретных реализаций. Важен он потому что является основой для параметрического полиморфизма, который является основой большинства паттернов для масштабируемых систем и open-closed principle из SOLID
- интерфейс в программировании подразумевает более широкое понятие чем описано в статье - кратко это контракт взаимодействия с сущностью. Interface в Java и другие аналоги - это просто способ реализации этого контракта, но далеко не единственный. В рамках этого принципа мы не говорим о конкретной реализации, а говорим о том что такой контракт должен быть - как его реализовать в рамках конкретного языка или фреймворка - отдельный вопрос. Таким интерфейсом может стать функция, класс, HTTP запрос, событие, сообщение, RPC и так далее.
- самое главное - требование включать интерфейс как часть модуля выского уровня в корне не верно. Вводя интерфейс мы вводим два условия: МВУ использует контракт взаимодействия (зависит от интерфейса), МНУ реализует контракт взаимодействия (тоже зависит от интерфейса). При этом интерфейс сам по себе может являться отдельным модулем, он не обязательно вообще становится частью одного или второго. Самое главное что у интерфейса нет никакой зависимости ни от А, ни от Б. Почему это важно - при переносе модулей А и Б в другую систему, интерфейс должен быть перенесен вместе с ними так как у них есть от него зависимость, и отсутствие зависимостей делает перенос интерфейса тривиальным. Это позволяет переиспользовать и А, и Б без изменений при условии сохранения контракта, даже в рамках одного проекта - в чем и есть улучшение масштабируемости архитектуры. В то же время интерфейс может стать частью А или Б в зависимости от конкретной системы, это сугубо ситуативное решение.
Более наглядная взаимосвязь между модулями - интерфейс является независимой сущностью
Несколько моментов из моего опыта с кастомными элементами:
к кастомным элементам часто называют веб-компонентами, но они являются только одной составляющей набора API веб-компонентов (другие вещи включают в себя shadow DOM, HTML templates и тд) - подробнее тут
с помощью aria- аттрибутов кастомные элементы можно наделять семантикой, для лучшей SEO и accessibility (если вы уже активно используете их или другие аттрибуты, то кастомные компоненты могут помочь вам еще больше сократить объем кода и улучшить читаемость)
среди важных проблем - server-side rendering. Кастомные элементы требуют исполнения JS кода на стороне клиента для рендера, соответственно их сложнее использовать в контексте SRR-приложений. Аспекты типа локализации, server-side авторизации, использования CMS могут усложняться, и вам придется придумать как это решать. Поэтому предпочтительно может быть использовать web-component библиотеки которые уже это делают, но в ущерб минимализма и нативности API :)
Заметил пару спорных моментов на которых базируется вся статья :)
Объем кода
Суть идеи заключается в том, что когда вы начинаете находить закономерности в своем приложении, вы можете закодировать их при помощи малого языка. Этот язык позволит вам выразить эти закономерности более компактно, чем это возможно с помощью других средств абстракции. Что позволит не только противостоять тенденции к постоянному увеличению размера приложений, но и сократить объём кода в процессе разработки!
Объем кода != когнитивная сложность. При добавлении большего числа инструментов мы усложняем поддержку приложения, поэтому очень не всегда это приведет к позитивным эффектам.
И даже если малый язык позволит реализовать тот же функционал используя более простые абстракции, это все еще может не привести к упрощению поддержки, так как она в большей упирается в количество РАЗНЫХ абстракций, а не количество из переиспользований.
Предел выразительности кода
Я лично убежден, что мы достигли предела выразительности языков общего назначения. Если есть уровень выше, то как он будет выглядеть? Возьмем, к примеру, Python — он настолько высокоуровневый, что практически выглядит как псевдокод.
Не только синтаксис влияет на выразительность языка, а его улучшение не сводится к инкрементальным изменениям. Существуют принципиально различные варианты синтаксиса и написания кода, которые обладают большей выразительностью (LISP vs C-подобные языки, декларативный vs императивный код). И это все может проявляться даже в рамках одного языка.
P.S. Приверы других вещей которые влияют на выразительность помимо синтаксиса: парадигма программирования, фреймворки, набор абстракций используемых в коде, структура файлов проекта, документация (в том числе комментарии), типизация и даже такие вещи как сообщения в коммитах в Git. Все это в совокупности постоянно используется в работе с кодом и у нас впереди еще необъятная возможность к совершенствованию :D
С последним замечанием согласен, спасибо :)
По поводу независимого размещения - преимущество в том, что это делает оба модуля А и Б легко переносимыми, при условии что контракт сохраняется и переносится вместе с ними. Просто не всегда это надо и для каждого контракта заводить отдельный модуль может быть абсолютно не рационально, в очень большой зависимости от контекста. Формально поводом для изменения системы станут изменения в бизнес требованиях, и в контексте каких-то задач эта гибкость будет просто не нужна, а только усложнит систему зря
Суть статьи верна, но автор не очень четко разделяет границы понятий, а иногда наоборот смешивает вещи в одно. Добавлю или болеек детально проговорю пару вещей:
- по поводу абстракций - это просто базовый принцип разработки любого ПО, вне зависимости от парадигмы программирования, но часто приписывающийся ООП - сущности должны зависеть от абстракций и не конкретных реализаций. Важен он потому что является основой для параметрического полиморфизма, который является основой большинства паттернов для масштабируемых систем и open-closed principle из SOLID
- интерфейс в программировании подразумевает более широкое понятие чем описано в статье - кратко это контракт взаимодействия с сущностью. Interface в Java и другие аналоги - это просто способ реализации этого контракта, но далеко не единственный. В рамках этого принципа мы не говорим о конкретной реализации, а говорим о том что такой контракт должен быть - как его реализовать в рамках конкретного языка или фреймворка - отдельный вопрос. Таким интерфейсом может стать функция, класс, HTTP запрос, событие, сообщение, RPC и так далее.
- самое главное - требование включать интерфейс как часть модуля выского уровня в корне не верно. Вводя интерфейс мы вводим два условия: МВУ использует контракт взаимодействия (зависит от интерфейса), МНУ реализует контракт взаимодействия (тоже зависит от интерфейса). При этом интерфейс сам по себе может являться отдельным модулем, он не обязательно вообще становится частью одного или второго. Самое главное что у интерфейса нет никакой зависимости ни от А, ни от Б. Почему это важно - при переносе модулей А и Б в другую систему, интерфейс должен быть перенесен вместе с ними так как у них есть от него зависимость, и отсутствие зависимостей делает перенос интерфейса тривиальным. Это позволяет переиспользовать и А, и Б без изменений при условии сохранения контракта, даже в рамках одного проекта - в чем и есть улучшение масштабируемости архитектуры.
В то же время интерфейс может стать частью А или Б в зависимости от конкретной системы, это сугубо ситуативное решение.
Несколько моментов из моего опыта с кастомными элементами:
к кастомным элементам часто называют веб-компонентами, но они являются только одной составляющей набора API веб-компонентов (другие вещи включают в себя shadow DOM, HTML templates и тд) - подробнее тут
с помощью
aria-аттрибутов кастомные элементы можно наделять семантикой, для лучшей SEO и accessibility (если вы уже активно используете их или другие аттрибуты, то кастомные компоненты могут помочь вам еще больше сократить объем кода и улучшить читаемость)среди важных проблем - server-side rendering. Кастомные элементы требуют исполнения JS кода на стороне клиента для рендера, соответственно их сложнее использовать в контексте SRR-приложений. Аспекты типа локализации, server-side авторизации, использования CMS могут усложняться, и вам придется придумать как это решать. Поэтому предпочтительно может быть использовать web-component библиотеки которые уже это делают, но в ущерб минимализма и нативности API :)
Заметил пару спорных моментов на которых базируется вся статья :)
Объем кода
Объем кода != когнитивная сложность. При добавлении большего числа инструментов мы усложняем поддержку приложения, поэтому очень не всегда это приведет к позитивным эффектам.
И даже если малый язык позволит реализовать тот же функционал используя более простые абстракции, это все еще может не привести к упрощению поддержки, так как она в большей упирается в количество РАЗНЫХ абстракций, а не количество из переиспользований.
Предел выразительности кода
Не только синтаксис влияет на выразительность языка, а его улучшение не сводится к инкрементальным изменениям. Существуют принципиально различные варианты синтаксиса и написания кода, которые обладают большей выразительностью (LISP vs C-подобные языки, декларативный vs императивный код). И это все может проявляться даже в рамках одного языка.
P.S. Приверы других вещей которые влияют на выразительность помимо синтаксиса: парадигма программирования, фреймворки, набор абстракций используемых в коде, структура файлов проекта, документация (в том числе комментарии), типизация и даже такие вещи как сообщения в коммитах в Git. Все это в совокупности постоянно используется в работе с кодом и у нас впереди еще необъятная возможность к совершенствованию :D