Пишем переиспользуемые компоненты, соблюдая SOLID

[Nikulio]

Отличная статья! Большое спасибо!

[noodles]

в проекте 20 кнопок и все выглядят немного по-разному из-за того, что стили каждой кнопки задаются в месте применения.

У дизайнеров есть дизайн-система.

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

Корень проблемы в том, что компонент, который мы планировали переиспользовать, был написан неправильно.

вполне может быть, что на момент создания компонент был написан правильно, в соответствии с уровнем энтропии требований на тот момент..))
Т.е. чем больше неопределённоть, тем меньше нужно думать о будущем и меньше городить абстракций.

[vanilla-wave]

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

Четкая дизайн система появилась уже после описанной проблемы) Тут как раз про синхронизацию одного и второго. Вроде как была дизайн система, но не очень четкая + в организации компонентов не все гладко. Поэтому периодически появляются новые кнопки(редизайн, неправильно скопировали, не было нужной и создали новую и тп) и все выглядит по разному. Плюс при отсутствии синхронизации, любой редизайн повышает количество энтропии.

вполне может быть, что на момент создания компонент был написан правильно, в соответствии с уровнем энтропии требований на тот момент..))
Т.е. чем больше неопределённоть, тем меньше нужно думать о будущем и меньше городить абстракций.

В общем случае верно! Идеально — задуматься о переиспользуемости в момент написания и валидировать это решение при внесении изменений в компонент.
Про написания простого решения в условиях неопределенности — тоже верно. Делаем так, чтобы максимизировать количество не принятых решений и сделать выбор, когда у нас будет больше информации.
Но в случае с базовыми компонентами типа селекта/кнопки (наверно)можно было догадаться, что от невозможности переиспользования и бардака будет больно. Ну зато теперь знаем)