вадяskyANAПробовали оглядываться назад раз месяц, раз в квартал и оценивать плюсы и минусы выбранного подхода?
я при написании кода оцениваю плюсы и минусы варианты реализации.
счетом накопленной практики этопозволяет выбирать более правильный вариант.
я повторюсь.
у меня есть вариант поиска с выпадающим списком, сформированным почти как один этемент fw...
и я хотел бы использовать его как унивесальный ....
но при стремлении к универсальности получается монстр, трудновоспринимаемый для понятия логики его работы.
и он не может охватить всех ньюансов каждой новой реализации его применения.
мне выгоднее изменять его внутри, чтоб получать оптимальный вариант по сумме всех показатлей - от читаемости кода до скорости работы. остается только сама идея , сам принцип. таких элементов у меня уже несколько.
если это можно назвать моим fw.... но я не уверен, что это носит такое название.
но всё основано на чистом js и поэтому любому , знающему js не составит трудности разобраться.
влияние на скорость разработки - правильное соствление тз, постановки задачи -вот основные критерии скорости разработки.
у каждого прогера есть свои шаблоны, наработки, свой подход и если прогер ценит не только свой подход , но и уважает мнение остальных в команде, и готов перенимать лучшее из опыта каждого, то тогда он впишется в команду.
Да, компоненты писать не просто :)
С тем, что правильно составленное тз - это основной критерий скорости разработки, мне сложно согласиться.
Хотя думаю Вы смотрите с высоты своих задач, для решения которых инструменты уже давно выбраны, архитектура определена.
А вот насчёт того, что если код написан на js, то в нем без труда можно будет любому человеку, знающему его, заблудиться не стоит.
Вы тут показывали куски своего кода. Не назвал бы его хорошо читательным. Одни названия фунций чего стоят :)
А от прогера в команде хочется не только, чтобы он не только чужое мнение уважал, но и свое умел обосновать, в том числе и через техничешские исследования и эксперименты.

Простите за опечатки. Пишу с планшета.