У них senior - это в первую очередь менеджер и тим-лид, во вторую экспертные знания самого продукта, и только в третью чувак, который способен эффективно решить неоднозначную проблему
I own and deliver semi-annual/annual goals for my team
I define technical solutions or efficient operational processes that level up my team
I am a strong leader for my team with my impact beginning to extend outside my team
А чтобы управлять командой - нужны рычаги влияния. Но там нигде не написано, что senior может увольнять.
И еще не понятно - когда все это успевать. Пока ты бухаешь с начальством за понимание стратегических целей компании, составляешь и контролируешь планы для команды, собеседуешь людей, оптимизируешь процессы - теряешь техническую экспертизу для соответствия разделу Craft.
Пожалуй есть один выход - это когда работаешь лет 10 в компании, успел много чего поделать и на полугодовом ассасменте говоришь такой "ну я вон 5 лет назад делал вот эту хрень из уровня IC4-5-6, так что я достоин". Не уверен правда - сработает это или нет. Ведь один раз за 5 лет - это далеко от экспертизы.
По warehouse_id да, если заранее был выбран конкретный склад (например по сроку или стоимости доставки до конечного клиента и в том числе по остаткам). По category_id не думаю. Можно закодить машрутизатор на уровне приложения - который будет работать в несколько потоков, но класть заказы с пересекающимися товарами в один поток. Но зачем, если это сложнее, а пессимистичная или оптимистичная блокировка по сути делают то же самое. Можно просто вывести кол-во потоков в конфигурацию и экспериментальным образом подобрать нужное значение.
И есть как минимум три категории систем - на стороне продаж, на стороне склада (WMS) и OMS (order management system), которые скачивают заказы из первых, выбирают оптимальный склад и отправляют в WMS. И у всех трех есть свои особенности. Сложнее всего, пожалуй с OMS - когда они делают резерв, это еще не значит, что этот резерв реально создан для конкретного склада в WMS.
Чуть измененный вариант - построить на пессимистичной блокировке - добавить версию строки и обновлять. Если не совпадает - откат транзакции и retry.
Второй концептуальный способ - зная, что там в один поток, это сделать очередь (не важно на чем - кафка, раббит, таблица в бд, редис) и разбирать ее в один поток. С этого момента основной целью станет - выжать максимум из железа и субд. Так как мы уже знаем, что будет один поток, то блокировки не нужны, и можно что-нибудь придумать, например снизить уровень изоляции или даже вообще отказаться от транзакций. Из минусов - ордера с разными товарами, которые могли бы обработаться параллельно - не будут.
Резерв товара это по сути и есть конкуренция за товар. Все равно где-то в конце будет в один поток.
Один из способов - это построчная блокировка каждого товара. В my sql например есть select for update. Тогда заказы с разным набором товаров не будут друг другу мешать. Там будет всякие deadlock, они будут по тайм-ауту отваливаться. И в итоге окажется, что два заказа отвалились, но один из них смог бы обработаться, если повторно запустить. Поэтому просто сверху полируем retry policy и в целом все начинает работать. И чем больше линий в заказе тем он проблемней.
Общее впечатление - все это не стабильно. Например добавляешь новое поле и надо поправить дто, маппинги и тесты. И либо сам удивляешься «ой точно, тут тоже надо поправить, красаффчик», либо «ты че такой тупой, про тесты забыл».
Хотя с другой стороны режим «написал промт и потом сидишь и жмешь Apply» - впечатляет.
ИИ оказался относительно хорош в подсказке возможных вариантов. Но все же пообщавшись с людьми тут в коментах на хабре по теме - у людей есть еще интересные варианты как сделать. Вот хотелось бы, чтобы ИИ выдавал реально все варианты, а я бы выбирал подходящий.
ИИ оказался хорош в генерации авто тестов.
Еще из минусов - через раз генерит немного разный код, это бесит.
Моментально стало очевидно, что нельзя самому терять контекст и понимание своей же программы. Нужно четко осознавать что делает встраиваемый код, почему он именно такой и почему этот кусок надо вставить именно сюда.
Еще лично мне ИИ помогает в какой то мере преодолеть долину отчаяния на кривой Даннинга-Крюгера - когда на неизведанной территории сталкиваешься с проблемой, нет ориентира как лучше сделать и начинаешь сомневаться в своих решениях.
Короче, если поводить итоги - в данный момент ИИ это как больше конвертер мыслей в код, но мысли должны быть свои. С авто тестами получше. И хотелось бы, чтобы ИИ в своей базе содержал все возможные варианты, когда либо придуманные людьми, по заданной теме.
public class CreateOrderDTO
{
[Required] [MaxLength(255)]
public string OrderNumber { get; set; }
}
А атрибуты для UI - это отдельная наша сборка, там у нас UI-движок, который генерит экраны на основе классов и атрибутов. В имени сборки есть слово "UI". И вот сидишь такой пилишь домен, и там в зависимостях UI показывает, что увеличивает кол-во WTF-ов при чтении кода на +1 😅
Нет, у вас был бы один или два DTO, с которыми работают контроллеры. В слое контроллеров в этом случае нет своих DTO.
Сейчас там в этих DTO для контроллеров есть дополнительные атрибуты (для документации API, для UI). И если я сложу их на уровень Domain - это все протечет в домен. И меня это смущает.
В реальном проекте, на основе которого я пилю этот пет проект - есть два контроллера с немного разными DTO - когда заказ создается через API и когда через UI. И в реальном проекте с анемичной моделью и публичными сеттерами - используется автомаппер (из этих двух DTO прям в анемичную сущность).
Если бы я переходил на DDD и добавил бы еще один DTO на уровне Domain (вот который мы обсуждаем и который у меня как интерфейс) - у меня стало бы три штуки DTO. Если я добавляю интерфейс - я просто те два DTO для котроллеров наследую от интерфейса.
Я хочу попробовать интерфейс по двум причинам - чтобы не делать маппинги и, когда добавляется новое поле, компилятор скажет в каких DTO я забыл его добавить.
Dropboх тоже лукавит.
У них senior - это в первую очередь менеджер и тим-лид, во вторую экспертные знания самого продукта, и только в третью чувак, который способен эффективно решить неоднозначную проблему
А чтобы управлять командой - нужны рычаги влияния. Но там нигде не написано, что senior может увольнять.
И еще не понятно - когда все это успевать. Пока ты бухаешь с начальством за понимание стратегических целей компании, составляешь и контролируешь планы для команды, собеседуешь людей, оптимизируешь процессы - теряешь техническую экспертизу для соответствия разделу Craft.
Пожалуй есть один выход - это когда работаешь лет 10 в компании, успел много чего поделать и на полугодовом ассасменте говоришь такой "ну я вон 5 лет назад делал вот эту хрень из уровня IC4-5-6, так что я достоин". Не уверен правда - сработает это или нет. Ведь один раз за 5 лет - это далеко от экспертизы.
Побольше бы примеров кода и структуры солюшена.
Например что такое QueryHandlers в Application слое и чем они отличаются от DbQueryHandlers в инфраструктуре?
А что за Application Services и чем отличаются от domain сервисов? Что скажите насчет UseCase и UserStory?
А чем это отличается от спецификации? От перекладывания кода из одно места в другое - суть же не меняется.
Как вы создаете сущность из DTO, которое пришло из контроллера? Вот тут мой коммент где я уже собрал несколько вариантов https://habr.com/ru/articles/931866/comments/#comment_28640604
O_O, ништяк, оказывается есть шрифты, которые лучше показывают разницу между ! и i - а то я привык уже писать, чтоб глаз на замыливался
вместо
По warehouse_id да, если заранее был выбран конкретный склад (например по сроку или стоимости доставки до конечного клиента и в том числе по остаткам). По category_id не думаю. Можно закодить машрутизатор на уровне приложения - который будет работать в несколько потоков, но класть заказы с пересекающимися товарами в один поток. Но зачем, если это сложнее, а пессимистичная или оптимистичная блокировка по сути делают то же самое. Можно просто вывести кол-во потоков в конфигурацию и экспериментальным образом подобрать нужное значение.
И есть как минимум три категории систем - на стороне продаж, на стороне склада (WMS) и OMS (order management system), которые скачивают заказы из первых, выбирают оптимальный склад и отправляют в WMS. И у всех трех есть свои особенности. Сложнее всего, пожалуй с OMS - когда они делают резерв, это еще не значит, что этот резерв реально создан для конкретного склада в WMS.
Попутал немного - вариант 1а это пессимистичная блокировка, вариант 1б оптимистичная
$4-5k это для удаленки. Это уже лет 10 как минимум.
Прикольный сайт, на злобу дня и противопоставление levels.fyi 😅
Подскажите какие промты вы добавили в чат гпт, чтобы он стал более адекватным?
А они еще не спрашивают почему иконка сохранения - дискета?))
Чуть измененный вариант - построить на пессимистичной блокировке - добавить версию строки и обновлять. Если не совпадает - откат транзакции и retry.
Второй концептуальный способ - зная, что там в один поток, это сделать очередь (не важно на чем - кафка, раббит, таблица в бд, редис) и разбирать ее в один поток. С этого момента основной целью станет - выжать максимум из железа и субд. Так как мы уже знаем, что будет один поток, то блокировки не нужны, и можно что-нибудь придумать, например снизить уровень изоляции или даже вообще отказаться от транзакций. Из минусов - ордера с разными товарами, которые могли бы обработаться параллельно - не будут.
Резерв товара это по сути и есть конкуренция за товар. Все равно где-то в конце будет в один поток.
Один из способов - это построчная блокировка каждого товара. В my sql например есть select for update. Тогда заказы с разным набором товаров не будут друг другу мешать. Там будет всякие deadlock, они будут по тайм-ауту отваливаться. И в итоге окажется, что два заказа отвалились, но один из них смог бы обработаться, если повторно запустить. Поэтому просто сверху полируем retry policy и в целом все начинает работать. И чем больше линий в заказе тем он проблемней.
Потрясно! Да и сама идея закодить что-нибудь пиксельартовое под дос в современно мире!
Тоже пилю пет проект сейчас, с использованием ИИ.
Общее впечатление - все это не стабильно. Например добавляешь новое поле и надо поправить дто, маппинги и тесты. И либо сам удивляешься «ой точно, тут тоже надо поправить, красаффчик», либо «ты че такой тупой, про тесты забыл».
Хотя с другой стороны режим «написал промт и потом сидишь и жмешь Apply» - впечатляет.
ИИ оказался относительно хорош в подсказке возможных вариантов. Но все же пообщавшись с людьми тут в коментах на хабре по теме - у людей есть еще интересные варианты как сделать. Вот хотелось бы, чтобы ИИ выдавал реально все варианты, а я бы выбирал подходящий.
ИИ оказался хорош в генерации авто тестов.
Еще из минусов - через раз генерит немного разный код, это бесит.
Моментально стало очевидно, что нельзя самому терять контекст и понимание своей же программы. Нужно четко осознавать что делает встраиваемый код, почему он именно такой и почему этот кусок надо вставить именно сюда.
Еще лично мне ИИ помогает в какой то мере преодолеть долину отчаяния на кривой Даннинга-Крюгера - когда на неизведанной территории сталкиваешься с проблемой, нет ориентира как лучше сделать и начинаешь сомневаться в своих решениях.
Короче, если поводить итоги - в данный момент ИИ это как больше конвертер мыслей в код, но мысли должны быть свои. С авто тестами получше. И хотелось бы, чтобы ИИ в своей базе содержал все возможные варианты, когда либо придуманные людьми, по заданной теме.
В смысле не справляются? А в чем подвох задачи?
Ну да, аннотации / атрибуты над полями в классе
А атрибуты для UI - это отдельная наша сборка, там у нас UI-движок, который генерит экраны на основе классов и атрибутов. В имени сборки есть слово "UI". И вот сидишь такой пилишь домен, и там в зависимостях UI показывает, что увеличивает кол-во WTF-ов при чтении кода на +1 😅
Сейчас там в этих DTO для контроллеров есть дополнительные атрибуты (для документации API, для UI). И если я сложу их на уровень Domain - это все протечет в домен. И меня это смущает.
Альтернативы, которые я вижу
Третий DTO как класс + маппинги
Третий DTO как класс + наследование
DTO как абстрактный класс + наследование
Если кому будет интересно - резюме вариантов, как пропихнуть DTO в сущность
Через 100 500 параметров в конструкторе и 100 500 методов UpdateXXX https://habr.com/ru/articles/931866/comments/#comment_28633638 и https://habr.com/ru/articles/931866/comments/#comment_28640456
Сущность имеет публичные сеттеры, но с признаком IsSealed, который запрещает устанавливать значение из вне (такие сущности конструируются, когда достаются из БД) https://habr.com/ru/articles/931866/comments/#comment_28634360
Сущности имеют приватные сеттеры + DTO на уровне Domain (лежат рядом с сущностями). Тут мой вариант с интерфейсами, но можно и с классами https://habr.com/ru/articles/931866/comments/#comment_28636082 (дискуссия еще продолжается)
Мда, даже в коментах под этой статьей я собрал три разных варианта как делать DDD. 😅 И это лишь малая толика всего, с чем реально придется столкнутся.
А вы как-то облегчаете кодинг всех этих параметров для конструкторов и методов для обновления? Кодогенерация?
В реальном проекте, на основе которого я пилю этот пет проект - есть два контроллера с немного разными DTO - когда заказ создается через API и когда через UI. И в реальном проекте с анемичной моделью и публичными сеттерами - используется автомаппер (из этих двух DTO прям в анемичную сущность).
Если бы я переходил на DDD и добавил бы еще один DTO на уровне Domain (вот который мы обсуждаем и который у меня как интерфейс) - у меня стало бы три штуки DTO. Если я добавляю интерфейс - я просто те два DTO для котроллеров наследую от интерфейса.
Я хочу попробовать интерфейс по двум причинам - чтобы не делать маппинги и, когда добавляется новое поле, компилятор скажет в каких DTO я забыл его добавить.