Комментарии 9
Насчёт IEntity. Мысль понятна, я сам сталкивался с тем, что при дальнейшем развитии системы новые сущности не укладываются в казавшуюся изначально универсальной схему.
Но. Наступает момент, когда приходится сравнивать объекты по ключу, апдейтить их и делать другие нехорошие вещи, которые без primary key делать невозможно. И тут просходит пришествие IEntity 2.0. Точнее, IEntity<TKey> или что-то похитрее в случае композитных PK.
Для себя я отказался от интерфейса в общем случае, но те части системы, которым требуется доступ к PK сущности, требуют наличия у этой сущности генерик-наследования IEntity<TKey>
по этому поводу есть хорошая статья
https://blog.ploeh.dk/2024/06/03/youll-regret-using-natural-keys/
Эта статья о другом. Кстати, у этой статьи есть перевод на хабре. Эта статья о том, что не надо использовать данные внешних ИС для ключа. Даже если внешняя система объявляет их уникальными.
В моём случае не все сущности имеют интовые ключи, для некоторых сущностей были использованы композитные ключи. Да, это другое.
Действительно, есть такой вариант решения проблемы. На мой взгляд, в небольших проектах это будет выглядеть избыточно (нужно будет описывать еще и TKey), а на больших вполне может сократить какую-то рутину.
Если воспринимать это не как "мои правила", а "как мне удобно кодить", то нормально, но не интересно. Иначе, эти "правила" должны кишеть ифэлсами - если просто так грохать базу, интеграционные тесты и метрики, плодить мелкие релизы, приводящие к релизному спагетти с миллионом мерджей (но "стараться" как-то при этом спрямлять историю - это не мерджить чужие изменения что ли?), то можно от смежных команд получить больно по голове.
Любую идею можно довести до абсурда, если нужно показать её несостоятельность. Но было бы странно придумать для себя какие-то правила, а потом старательно доказывать, что они бесполезны. Я таким решил не заниматься.
Не понял ваш посыл про смежную команду. В пункте про релизы явно написал, что лучше сделать несколько релизов, чтобы клиенты (в том числе это могут быть и другие команды) этого не заметили, а какая-то миграция произошла в комфортном режиме.
Спасибо за статью! Она мне близка во всем кроме пункта с бюрократией) Подскажите, ваши коллеги тоже следуют принципу "Постоянно улучшай" или это так и живет на уровне вашей собственной инициативы?
Я стараюсь продвигать концепцию постоянного улучшения в каждой команде. Но не получится сказать "теперь давайте постоянно улучшать код вокруг себя и делать рефакторинг". Это всё же больше относится к какому-то культурному аспекту, поэтому требует времени на внедрение. Особенно, в командах, где никогда о таком не задумывались и/или заводили тикеты на рефакторинг. Что я делаю, чтобы распространить эту практику:
Личный пример. Действительно, нужно показать, как это может быть. И есть подтвержденные факты, что коллеги это отмечают и им нравится такой подход.
Ревью. На ревью всегда можно обратить внимание на код вокруг, предложить что-то к улучшению. Но предварительно нужно договориться о том, что не все такие предложения обязательны к исправлению, чтобы бесконечно не раздувать задачу. Но даже озвучивание каких-то идей - хороший вклад в будущее. Когда-то потом можно будет вернуться к этому месту и исправить.
На планировании задач искать те самые задачи на рефакторинг в бэклоге и "прицеплять" к бизнесовым задачам. Даже если они не заведены в явном виде, то всегда можно посмотреть, что можно сделать полезного до самой задачи.
Немного бюрократии :) Для новеньких людей явно ставим цель "использует рефакторинг в своей работе". Таким образом сразу фокусируем человека на то, что у нас так принято и для него это не будет сюрпризом.
Таким образом эта культура постепенно будет взращиваться и станет нормой для команды. В большинстве команд такой подход разделяли и я отмечал, что коллеги так же начинали следовать этому "правилу".
Мои правила