Комментарии 8
Я не поленился и решил поперфтестить данные примеры на JS
Понимаю что статья не об этом, но это крайне спорное утверждение (особенно без цифр и кода). К тому же оригинал написан на другом языке, и не ясно как исходный пример был адаптирован
Да, я понимаю вас. В исходном примере во многом используются конструкции, которые есть и на JS, я старался переносить всё максимально точно, учитывая при этом особенности перф тестирования на js.
Тем не менее, это всего лишь слова, поэтому, если этот коммент наберет 10к лайков, я попробую написать отдельную статью об этом
Вообще SOLID часто относят именно к принципам ООП. На самом деле, эти правила хорошо ложатся на прочие парадигмы и на компонентный подход.
Это по той причине, что это не принципы ООП, а скорее принципы программирования. В частности ангуляр/тайпсрипт - вроде как к ООП приведён со всеми вытекающими. А, вообще, как я заметил ещё давно, не могу сказать как сейчас, но на фронт всё ещё пытаются много всего из ООП / DDD / MicroservicesArchitechture заимствовать/переносить.
Да, я согласен, что SOLID это принципы программирования, но многие так не думают, и, если загуглить ООП, то во многих источниках, даже в банальной wiki, будет указано, что это принципы именно ООП
но на фронт всё ещё пытаются много всего из ООП / DDD / MicroservicesArchitechture заимствовать/переносить.
Хм. Фронт это в большинстве своём React. А React уходит от ООП. Вывод: Фронт уходит от ООП.
Иногда провожу рефакторинг во время обычных задач, если замечаю проблему, которая быстро решается — поправляю. Рады ли этому тестировщики? Не думаю. Поэтому главное не забыть их предупредить
А как к этому относятся остальные члены команды? А те, кто проводит ревью? А те, кто делает в другой ветке другую фичу основанную на коде который рефакторится?
Отличные вопросы.
С негативным мнением тех, кто проводит ревью, я никогда не сталкивался, видимо потому что правки незначительные. Даже, если такое существовало бы, то качество проекта > мнение ревьюера.
Разработчики в другой ветке не страдают от этого, потому что я способен при рефакторинге сохранять обратную совместимость. Если это невозможно, то я вношу подобные правки, лишь зная, что никто с этим кодом не работает и не собирается. В крайнем случае выношу в отдельную задачу и дальше по флоу.
Я понимаю, что хочется всё сделать правильно, с задачками на борде и т.п., но мой субъективный опыт показывает, что тех. долг на проектах только растет, а согласование таких доработок занимает столько же времени, сколько и сама доработка, включая ревью и тесты. Поэтому я начал их проводить таким образом. Может быть я не прав, но качество проекта повышается, не теряя скорости разработки, это главное.
Публикации
Истории и боли frontend-разработчика