[ARCHIVED] Адаптивность нейминга

[azinit]

Дискуссия закрыта, см. выводы по #77

---

---

---

• У кого-то слово shared подразумевает что-то переиспользуемое (не обязательно связанное с низко уровневым)
• Кто то предпочитает класть туда либы / ui - всякие инфраструктурные моменты, отвлеченные от БЛ
• Кому-то заходит больше название не shared а common
• и т.д.

Таких примеров много.

В том числе вместо app многие пишут core

Но возникает вопрос

А насколько мы хотим закрепить эти слова в методологии, и насколько хотим давать пользователю адаптировать нейминг?

Понятно что некоторые сущности опциональный
Но если разработчик на проекте увидит сущность, которую переназвали из методологии - это будет тож не очень (он просто мало что сможет найти из спецификации)

[sergeysova]

Я предлагаю в нашем тулинге установить конфиг, который будет читать CLI, eslint и генератор.
Чтобы каждой сущности/директории можно было сменить нейминг, но не менять назначение сущности.

[azinit]

Ну да, т.е. я примерно представлял это как решение:

{ 
  shared: "common",
  entities: "shared",
  app: "core",
}

И т.д.

Но уже даже в базовом приближении видно - как много бед это может принести, касаемо разночтений)

[azinit]

Тип линтеры еще мб и справятся, но вот люди, которые например уже юзают этот подход по-другому...

Вопрос наверное даже - хотим ли мы добиться настолько хороших названий абстракций, чтоб не возникало такой необходимости изменять их нейминг?

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

[sergeysova]

Тоже есть такое ощущение

[azinit]

Кто-то, в том числе, может вместо shared взять название core, который будет у некоторых интерпретироваться как вообще app

И тут на самом деле важный вопрос - насколько мы хотим давать пользователям методологии это изменять?

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

Т.е. даже если мы поменяем названия, но оставим связи - это уже усложнит нахождение параллелей, как по мне, с нашей #ПрекраснойМетодологиейБудущего

[carina-akaia]

Я за строгий нэйминг, как в Atomic. Нужен конвеншн, в котором можно доступно объяснить суть каждой абстракции единожды и кто угодно мог сориентироваться в любом проекте, который следует методологии.

[azinit]

Вот да

Тип понятно, что многим все также будет хотеться переназвать "shared" в "common" (условно) , но зато все проекты с нашей методологией будут похожи друг на друга (что мы и хотим перенять у Ангуляра)

[carina-akaia]

Вот да

Тип понятно, что многим все также будет хотеться переназвать "shared" в "common" (условно) , но зато все проекты с нашей методологией будут похожи друг на друга (что мы и хотим перенять у Ангуляра)

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

[ilyaagarkov]

у нас на одном проекте был атомик, и мы использовали в том числе templates.
А потом пришел бизнес и сказал, что теперь у нас есть такая сущность как templates. Проект после этого прожил не долго, но если бы он развивался дальше, то подобная коллизия имен могла не плохо подпортить читаемость кода

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

[azinit]

Некоторые примеры нейминга приведены в #31