Дело не в знании технологий, а в том что 30 летний «ребенок» бежит к мамке по любому поводу и без. Вы наверное просто не сталкивались именно с тем, о чем толкует автор.
Выглядит это примерно так:
Скидывает кусок кода - почему у меня тут null ref эксепшн? Ну зайди в отладку посмотри, сам же код писал, мне то в любом случае придется с твоим кодом разбираться
Скидывает кусок кода с вызовом стороннего апи - почему не работает? Ну доку почитай, мне же ведь тоже это придется сделать, этих интеграций миллионы разных
И так каждый час. Причем по хронологии событий - похоже что сам он вообще не пытается докопаться до истины. Или пасует после первого промаха. Он не может отладить и доку почитать, я не могу работать все время отвлекают. Из 10 таких вопросов найдется один реально нормальный. Сам же при этом сениор, проекты вел, командой рулил. Вот как так?
35 летний джун вошедший в айти - себе такого не позволял. Сидел копал, когда совсем уже закапывался, шел ко мне.
Местами сумбурно, но основная мысль понятна. И я тоже с таким столкнулся недавно. До этого я работал с людьми либо старше, либо ровесниками плюс минус. А вот довелось поработать с человеком лет на 5 младше - на каждый чих бежит ко мне с вопросами. Сам не делает и мое время еще тратит, хотя был сениором на своих предыдущих проектах. Но я думал, что это конкретный человек такой, а видимо нет...
Расскажу немного про свой опыт. Но прежде, следует уточнить, что в каждой компании роли тим-лида/тех-лида определяют по своему. И часто бывает — что это человек, который должен заткнуть все оставшиеся дыры.
В целом, на мой взгляд, тим-лид — это больше в сторону развития команды. И сейчас, наконец-то, по прошествии многих лет, стало появляется понимание этого. В последнее время я стал замечать, что в вакансиях тим-лидов все чаще встречаются требования, связанные именно с командной работой, решением межличностных конфликтов, развитием компетенций команды, планирование обучения и так далее и все меньше технических знаний.
А тех-лид — это больше в сторону технического развития. Мне в свое время предложили стать тех-лидом. Но как впрочем и всегда, это была мешанина обязанностей. Хотя именно развитием и обучением команды я не занимался. Конфликты не решал (хотя вроде их и не было).
То, что делал я — я бы назвал "ведущий программист". Я вел проект с технической точки зрения. С одной стороны у меня был Product Manager/Owner и BA, которые олицетворяли стейкхолдеров. Так как это был интегратор в банковской сфере — там было довольно много бумаг, в том числе и технические задания. Я же олицетворял весь технический проект целиком. Мне на входе "что надо сделать", а я думал "как это сделать" и делал вместе с командой. Выбирал технологии, продумывал архитектуру, оформлял и распределял задачи в жире, сам назначал созвоны для обсуждения рабочих вопросов с участниками команды (да это все еще было удаленно), проводил код-ревью и сам писал код и довольно много.
По распределению времени — процентов 60% на архитектуру и написание кода, 10-20% на ревью кода, остальное на остальное.
Собственно чего от меня ожидали:
Мне опишут, что надо сделать, а я найду решение и сделаю.
Оценка и корректировка времени.
В жире был виден прогресс по проекту, но ко мне могли прийти и спросить технических подробностей и текущих проблем, так как PM бывший технарь. Размер проекта позволял мне держать весь его в голове. Я сам погружался немного в каждую задачу, которую выдавал участникам команды, продумывая, что и как там надо сделать и как это состыковать с остальным проектом. Поэтому я мог рассказать обо всем.
Участие в принятии решений — в каком объеме надо сделать очередной этап проекта, чтобы и успеть в обещанный клиенту срок и показать действительно ценный функционал. Так однажды, мы не укладываясь в календарный срок, приняли решение о переработке, чтобы клиенту выдать полностью готовый один из воркфлоу. В противном случае, этот этап не принес бы никакого бизнес-валью конечному клиенту. Был бы бесполезен.
Распределения задач в команде, с учетом опыта (джунам попроще, мидлам посложнее, сеньорам с большей долей неопределенности и исследовательской работы).
Мне никто этого не говорил, но я сам наделил себя обязанностью отвечать за качество проекта. Отсюда следовало еще два пункта:
6.1. Ревью кода. Я успевал просмотреть код за каждым участником
6.2. Ближе к концу я с BA прошлись по коду и тех заданию. Сопоставили и каждый себе пометил то, что надо еще доработать. В итоге синхронизировали документацию и код. И я стал уверен в том, что проект делает именно то, что требовалось
Чего я не делал:
Не общался напрямую с клиентом
Не обучал команду (но как-то старался давать задачи по силам)
Не решал конфликты (вроде их не было, но сейчас уже понимаю — мне повезло с командой, все работали плотно и слаженно).
Я столкнулся с аналогичной проблемой во фронтенде, так как сам был (и остаюсь больше) бэкендером. Но, из-за того, что я мог сам выбирать технологии и UI был довольно простым — остановился на том, что я довольно хорошо знал (в те времена это был ASP.NET, даже еще не MVC) + взял подходящую демку из набора готовых компонентов. Сейчас, на крупных проектах, я бы ставил перед руководством вопрос разделения фронт-енда и бэк-енда и у каждого свой "ведущий программист". Фронт-енд довольно обширная и крайне зыбкая тема.
Сейчас уже, я замечаю, что замкнул на себе довольно много всего. Это было ручное управление. Но тогда мне нравилось так работать. Команда была продолжением моих рук. Я успевал делать проект (на это конечно влияет размер команды и проекта). Но мои те подходы нельзя было масштабировать. И сейчас бы я думал в сторону настройки процессов и показателей. Например чтобы ревью-кода проводилось между участниками команды, а не лично мной. И так далее.
А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.
Вообще по-разному. Но лично я имел ввиду при полной равномерной загрузке. Я с 2015 года как раз на такой удаленке. Сначала на upwork, а потом напрямую. И те, кто работал со мной — аналогично 6-8 часов в день. 35-40 часов в неделю на протяжении нескольких лет.
Единственное, к чему приведет борьба за равноправие — снижение зп вообще для всех
Глобального снижения не будет, я вообще не уверен что будет хоть какое-то. Только если границы закроют и от свифта отключат. Но тогда плохо будет всем.
Программисты просто будут продолжать выходить на зарубежную удаленку и внутренние процессы в РФ заморским компаниям не указ. У них свой планетарный баланс спроса и предложения с учетом индусов.
Собственно многие так и сделали, когда у нас рубль рухнул в 2014. Думаю именно поэтому в стране постепенно возросли зарплаты до 350 тр — это как раз те же 5000$, что были до падения рубля.
Да, да, да, совок и есть совок. Насчет доступа к данным. Однажды (и это лет 10 назад, когда вакансий на удаленке можно было пересчитать на пальцах рук), лично я получал хардварный ключ на флешке с two factor для доступа в отдельный контур банковской системы для работы на проекте удаленно.
Я тоже не согласен, что жизнь дороже. В Москве дороже купить квартиру и больше соблазнов куда деньги потратить.
Съем в мск 40, в городе миллионнике 15-20. Разница в 20 тр.
В отпуск через Москву — это условно +10тыр за билет туда обратно на каждого члена семьи
Еда так же. Одежда так же. Хотя вру, в своем городе я не смог найти нормальную теплую куртку на зиму. В Москве нашел. Т.е. еще и за нормальной одеждой надо в Москву гонять. А это опять +10тыр за билет туда обратно.
Рано или поздно будет найден баланс спроса и предложения. Это уже давно наблюдается на рынке международной удаленки на фрилансерских биржах (с учетом индусов, филиппинцев и так далее). Основная суть — чем восточнее, тем меньше ставка (за исключением Австралии и Японии) в среднем примерно так:
* США/Австралия — >= 50$/час
* Западная Европа — 40$/час
* Восточная Европа (+ Россия и + пожалуй Израиль) — 30$/час
* Ближний Восток (Египет, Афганистан и так далее) — 20$/час
* Дальний Восток (Индия) — до 10-20$/час
* Островные государства (Филиппины, Индонезия и так далее) — 5-10$/час
Но это средние, в каждом случае есть отклонения. Я например работал:
* С египтянином, который начал с 20$, потом 30$, а потом он устроился в Майкрософт.
* С человеком из Австралии — 75$
* Со славянином, проживающим в Израиле 80-100$
* С инудсом (куда уж без них) 30$ в час.
И видел ребят из России 35-45$.
И на самом деле тут три фактора:
1. Да, первый это дороговизна жизни в стране проживания.
2. Второй — местонахождение «компании-нанимателя». Для компаний из США вложения в хорошего программиста из восточной Европы — в целом выгодные вложения. Но для компании из Пакистана — нет.
3. Третий — это знания, опыт и навыки и знание конкретного бизнеса (внутренней кухни самой компании-нанимателя). Подтянув их — компании будут платить больше. Но нужен минимальный уровень этих знаний, навыков и опыта. Грубо говоря, если Вася Иванов умеет тоже самое за 30$, что и Джон Смит за 50$ — возьмут Васю. Но если у Васи английский вообще никакой — то и за 30 не возьмут.
Аналогичный баланс настанет и внутри России, когда удаленщиков станет больше.
Но на этот баланс будет давить потенциальная возможность работать на рынке зарубежной удаленки, где для россиян — это давно устоявшаяся ставка в 30$ в час (или порядка 5000$ в месяц). Это ставка такого хорошего сениора с опытом плюс минус 10 лет или выше + с хорошими софт скилами + английский intermediate. Английский кстати дает больше бонусов. Fluent- это уже 35-40 для россиянина.
Отдельных удаленных сотрудников не рассматривали — с ними сложно поддерживать коммуникации, и у них пониженная вовлеченность в проект, т.к. они не видят того, что происходит внутри команды, работающей в офисе. И живут только от таска до таска.
Да, есть компании, для которых удаленщики (да и в целом сотрудники) расходный материал, а есть такие, где удаленщики — самостоятельно ведут проекты и команду. Вряд ли в таком случае можно говорить о пониженной вовлеченности. Вы сами в своей голове делите людей на касты — вот это офисник, он красавчик, а вот удаленщик, ему таску, не возвращайся пока не сделаешь.
Но это решение быстро отмерло, потому что ваш разговор слышали все члены команды и приходилось кому-нибудь, да покинуть наш виртуальный офис — мы просто мешали друг другу.
Т.е. до вас только так дошло, что в офисе вы тоже все друг другу мешаете? Но там нельзя «просто уйти».
Первое время было сложно без разговоров с коллегами у кофепоинта и без совместных походов на обед.
Так вы на работу ходили чтоб кофе/чай гонять?
хотя сначала нам было особенно сложно контролировать рабочее время — день начинался рано, заканчивался поздно, мы всегда были на связи
Даже до пандемии в офисе было такое понятие как гибкий график. Кто-то приходит в 8 утра, кто-то к обеду. Но обязательно гарантировалось например 4 часовое пересечение для всех сотрудников днем. Это легко переносится и на удаленку. У вас там в компании совсем совок что ли? Давайте сломаю вам шаблон — можно продуктивно работать, когда часть команды на той стороне планеты, и разница во времени порядка 7-10 часов.
Приятным бонусом для меня стало то, что у нас повысилась производительность.
А ещё ты не можешь подойти к коллеге и быстро обсудить все рабочие вопросы вживую — обязательно нужно сначала написать, договориться о встрече, скинуть ссылку на видеоконференцию.
Неужели? Вы не знали, что лучше не дергать людей умственного труда каждые 5 минут? И планировать задачи на несколько дней/спринт вперед?
Итого — пандемия и удаленка, походу, научила вас работать. Это плюс.
Не совсем, основной тезис — куда складывать переиспользуемый код, который может быть как инфраструктурным, так и бизнес-кодом.
Базовые классы не очень удобны порой, поэтому лучше их не использовать. Кейс — когда в одной стори надо поведение из двух базовых, а множественного наследования в C# нет. Композиция в данном случае будет лучше.
С сервисами — я уже говорил, что они начнут пухнуть. А потом внутри сервисов захочется обратиться к хранилищу за дополнительными данными (см выше в статье пример с EntityService). Но обращение к хранилищу — это ведь тоже есть запрос или команда. Да и с domain сервисами — вы кажется начинаете затрагивать DDD. В случае с DDD команда будет дергать модель предметной области, а та в свою очередь начнет молотить бизнес-логику внутри себя.
С infrastructure и persistence — да, все так, но вот там такой бизнес кейс, а не инфраструктурный:
1. Покупатель делает заказ в интернет магазине на несколько товаров.
2. Возвращает один из товаров — под этим скрывается некий бизнес-процесс для единицы товара. Это возврат товара на склад и возврат части денег.
3. Но покупатель может так же вернуть все товары полностью. Но ведь внутри этого бизнес-процесса будет повторяется бизнес-процесс для единицы товара в цикле + некоторые оптимизации (иначе например будет N+1 запрос к БД).
доселе невиданные методы появились у стандартных библиотечных классов
Посмотрит исходники или документацию.
расширения своих собственных классов
Зачем их расширять, если и так есть доступ к исходникам и можно написать по обычному, внутри самих классов? Вот с интерфейсами проблема, хотя в последней версии появилась дефолтная реализация.
Насколько я понял идею методов расширения, они используются для:
1. Добавления новых (более удобных) методов для уже закрытых для изменения классов.
2. Для массовой реализации нового поведения для заданного интерфейса. Т.е. чтобы не прописывать в каждом классе реализацию, можно сделать метод расширения на интерфейс и все классы наследники получат это поведение. Мне это напоминает реализацию интерфейса по умолчанию, которое появилось в C# 8.0.
Не очень понятно — он что бизнес-аналитик? Или ему спускают готовое ТЗ (описание) и он анализирует именно это описание, чтобы разбросать по технической части?
Отдельно скажу о саппорте: его флоу управляют менеджеры, которые взаимодействуют со складом, а выполняют дежурные разработчики.
А можно тут подробней рассказать? В саппорт прилетают различные вещи и для начала их надо идентифицировать (это бага, это надо инструкцию обновить, это мелкая доработка, это похоже на эпик, это пользователь тупой). И ведь кто-то этим должен заниматься. Таким образом, разработчикам будет уходить только часть этих тикетов. Мало того, порой непонятно бага это или фича и требуется время разработчика, чтобы глубже копнуть. А такие задачи кому уходят? Дежурным? Да и еще — бывают такие тикеты, что без поллитра не обойдешься, нужно еще привлечь бизнес-аналитиков и созвониться с пользователем.
И еще не понятен жизненный цикл feature команды в рамках проектов. Они что сделали проект и свалили (распались)? А кто поддерживать будет?
Дело не в знании технологий, а в том что 30 летний «ребенок» бежит к мамке по любому поводу и без. Вы наверное просто не сталкивались именно с тем, о чем толкует автор.
Выглядит это примерно так:
Скидывает кусок кода - почему у меня тут null ref эксепшн? Ну зайди в отладку посмотри, сам же код писал, мне то в любом случае придется с твоим кодом разбираться
Скидывает кусок кода с вызовом стороннего апи - почему не работает? Ну доку почитай, мне же ведь тоже это придется сделать, этих интеграций миллионы разных
И так каждый час. Причем по хронологии событий - похоже что сам он вообще не пытается докопаться до истины. Или пасует после первого промаха. Он не может отладить и доку почитать, я не могу работать все время отвлекают. Из 10 таких вопросов найдется один реально нормальный. Сам же при этом сениор, проекты вел, командой рулил. Вот как так?
35 летний джун вошедший в айти - себе такого не позволял. Сидел копал, когда совсем уже закапывался, шел ко мне.
Местами сумбурно, но основная мысль понятна. И я тоже с таким столкнулся недавно. До этого я работал с людьми либо старше, либо ровесниками плюс минус. А вот довелось поработать с человеком лет на 5 младше - на каждый чих бежит ко мне с вопросами. Сам не делает и мое время еще тратит, хотя был сениором на своих предыдущих проектах. Но я думал, что это конкретный человек такой, а видимо нет...
Раньше делали лучше
Вот, сел сегодня в машину — замените элемент питания. Я менял его в августе 2020, 8 месяцев продержалась.
Расскажу немного про свой опыт. Но прежде, следует уточнить, что в каждой компании роли тим-лида/тех-лида определяют по своему. И часто бывает — что это человек, который должен заткнуть все оставшиеся дыры.
В целом, на мой взгляд, тим-лид — это больше в сторону развития команды. И сейчас, наконец-то, по прошествии многих лет, стало появляется понимание этого. В последнее время я стал замечать, что в вакансиях тим-лидов все чаще встречаются требования, связанные именно с командной работой, решением межличностных конфликтов, развитием компетенций команды, планирование обучения и так далее и все меньше технических знаний.
А тех-лид — это больше в сторону технического развития. Мне в свое время предложили стать тех-лидом. Но как впрочем и всегда, это была мешанина обязанностей. Хотя именно развитием и обучением команды я не занимался. Конфликты не решал (хотя вроде их и не было).
То, что делал я — я бы назвал "ведущий программист". Я вел проект с технической точки зрения. С одной стороны у меня был Product Manager/Owner и BA, которые олицетворяли стейкхолдеров. Так как это был интегратор в банковской сфере — там было довольно много бумаг, в том числе и технические задания. Я же олицетворял весь технический проект целиком. Мне на входе "что надо сделать", а я думал "как это сделать" и делал вместе с командой. Выбирал технологии, продумывал архитектуру, оформлял и распределял задачи в жире, сам назначал созвоны для обсуждения рабочих вопросов с участниками команды (да это все еще было удаленно), проводил код-ревью и сам писал код и довольно много.
По распределению времени — процентов 60% на архитектуру и написание кода, 10-20% на ревью кода, остальное на остальное.
Собственно чего от меня ожидали:
6.1. Ревью кода. Я успевал просмотреть код за каждым участником
6.2. Ближе к концу я с BA прошлись по коду и тех заданию. Сопоставили и каждый себе пометил то, что надо еще доработать. В итоге синхронизировали документацию и код. И я стал уверен в том, что проект делает именно то, что требовалось
Чего я не делал:
Я столкнулся с аналогичной проблемой во фронтенде, так как сам был (и остаюсь больше) бэкендером. Но, из-за того, что я мог сам выбирать технологии и UI был довольно простым — остановился на том, что я довольно хорошо знал (в те времена это был ASP.NET, даже еще не MVC) + взял подходящую демку из набора готовых компонентов. Сейчас, на крупных проектах, я бы ставил перед руководством вопрос разделения фронт-енда и бэк-енда и у каждого свой "ведущий программист". Фронт-енд довольно обширная и крайне зыбкая тема.
Сейчас уже, я замечаю, что замкнул на себе довольно много всего. Это было ручное управление. Но тогда мне нравилось так работать. Команда была продолжением моих рук. Я успевал делать проект (на это конечно влияет размер команды и проекта). Но мои те подходы нельзя было масштабировать. И сейчас бы я думал в сторону настройки процессов и показателей. Например чтобы ревью-кода проводилось между участниками команды, а не лично мной. И так далее.
Фигня этот дюраселл. В автомобильном ключе родная продержалась года два. Поставил дюраселл — сдохла, полгода не прошло.
А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.
Да, с отпуском там напряг.
Глобального снижения не будет, я вообще не уверен что будет хоть какое-то. Только если границы закроют и от свифта отключат. Но тогда плохо будет всем.
Программисты просто будут продолжать выходить на зарубежную удаленку и внутренние процессы в РФ заморским компаниям не указ. У них свой планетарный баланс спроса и предложения с учетом индусов.
Собственно многие так и сделали, когда у нас рубль рухнул в 2014. Думаю именно поэтому в стране постепенно возросли зарплаты до 350 тр — это как раз те же 5000$, что были до падения рубля.
Так что нет ничего не возможного.
Съем в мск 40, в городе миллионнике 15-20. Разница в 20 тр.
В отпуск через Москву — это условно +10тыр за билет туда обратно на каждого члена семьи
Еда так же. Одежда так же. Хотя вру, в своем городе я не смог найти нормальную теплую куртку на зиму. В Москве нашел. Т.е. еще и за нормальной одеждой надо в Москву гонять. А это опять +10тыр за билет туда обратно.
expertvagabond.com/digital-nomad-work-visas
(В статью бы добавить).
* США/Австралия — >= 50$/час
* Западная Европа — 40$/час
* Восточная Европа (+ Россия и + пожалуй Израиль) — 30$/час
* Ближний Восток (Египет, Афганистан и так далее) — 20$/час
* Дальний Восток (Индия) — до 10-20$/час
* Островные государства (Филиппины, Индонезия и так далее) — 5-10$/час
Но это средние, в каждом случае есть отклонения. Я например работал:
* С египтянином, который начал с 20$, потом 30$, а потом он устроился в Майкрософт.
* С человеком из Австралии — 75$
* Со славянином, проживающим в Израиле 80-100$
* С инудсом (куда уж без них) 30$ в час.
И видел ребят из России 35-45$.
И на самом деле тут три фактора:
1. Да, первый это дороговизна жизни в стране проживания.
2. Второй — местонахождение «компании-нанимателя». Для компаний из США вложения в хорошего программиста из восточной Европы — в целом выгодные вложения. Но для компании из Пакистана — нет.
3. Третий — это знания, опыт и навыки и знание конкретного бизнеса (внутренней кухни самой компании-нанимателя). Подтянув их — компании будут платить больше. Но нужен минимальный уровень этих знаний, навыков и опыта. Грубо говоря, если Вася Иванов умеет тоже самое за 30$, что и Джон Смит за 50$ — возьмут Васю. Но если у Васи английский вообще никакой — то и за 30 не возьмут.
Аналогичный баланс настанет и внутри России, когда удаленщиков станет больше.
Но на этот баланс будет давить потенциальная возможность работать на рынке зарубежной удаленки, где для россиян — это давно устоявшаяся ставка в 30$ в час (или порядка 5000$ в месяц). Это ставка такого хорошего сениора с опытом плюс минус 10 лет или выше + с хорошими софт скилами + английский intermediate. Английский кстати дает больше бонусов. Fluent- это уже 35-40 для россиянина.
Да, есть компании, для которых удаленщики (да и в целом сотрудники) расходный материал, а есть такие, где удаленщики — самостоятельно ведут проекты и команду. Вряд ли в таком случае можно говорить о пониженной вовлеченности. Вы сами в своей голове делите людей на касты — вот это офисник, он красавчик, а вот удаленщик, ему таску, не возвращайся пока не сделаешь.
Т.е. до вас только так дошло, что в офисе вы тоже все друг другу мешаете? Но там нельзя «просто уйти».
Так вы на работу ходили чтоб кофе/чай гонять?
Даже до пандемии в офисе было такое понятие как гибкий график. Кто-то приходит в 8 утра, кто-то к обеду. Но обязательно гарантировалось например 4 часовое пересечение для всех сотрудников днем. Это легко переносится и на удаленку. У вас там в компании совсем совок что ли? Давайте сломаю вам шаблон — можно продуктивно работать, когда часть команды на той стороне планеты, и разница во времени порядка 7-10 часов.
Неужели? Вы не знали, что лучше не дергать людей умственного труда каждые 5 минут? И планировать задачи на несколько дней/спринт вперед?
Итого — пандемия и удаленка, походу, научила вас работать. Это плюс.
Базовые классы не очень удобны порой, поэтому лучше их не использовать. Кейс — когда в одной стори надо поведение из двух базовых, а множественного наследования в C# нет. Композиция в данном случае будет лучше.
С сервисами — я уже говорил, что они начнут пухнуть. А потом внутри сервисов захочется обратиться к хранилищу за дополнительными данными (см выше в статье пример с EntityService). Но обращение к хранилищу — это ведь тоже есть запрос или команда. Да и с domain сервисами — вы кажется начинаете затрагивать DDD. В случае с DDD команда будет дергать модель предметной области, а та в свою очередь начнет молотить бизнес-логику внутри себя.
С infrastructure и persistence — да, все так, но вот там такой бизнес кейс, а не инфраструктурный:
1. Покупатель делает заказ в интернет магазине на несколько товаров.
2. Возвращает один из товаров — под этим скрывается некий бизнес-процесс для единицы товара. Это возврат товара на склад и возврат части денег.
3. Но покупатель может так же вернуть все товары полностью. Но ведь внутри этого бизнес-процесса будет повторяется бизнес-процесс для единицы товара в цикле + некоторые оптимизации (иначе например будет N+1 запрос к БД).
Посмотрит исходники или документацию.
Зачем их расширять, если и так есть доступ к исходникам и можно написать по обычному, внутри самих классов? Вот с интерфейсами проблема, хотя в последней версии появилась дефолтная реализация.
Насколько я понял идею методов расширения, они используются для:
1. Добавления новых (более удобных) методов для уже закрытых для изменения классов.
2. Для массовой реализации нового поведения для заданного интерфейса. Т.е. чтобы не прописывать в каждом классе реализацию, можно сделать метод расширения на интерфейс и все классы наследники получат это поведение. Мне это напоминает реализацию интерфейса по умолчанию, которое появилось в C# 8.0.
Не очень понятно — он что бизнес-аналитик? Или ему спускают готовое ТЗ (описание) и он анализирует именно это описание, чтобы разбросать по технической части?
А можно тут подробней рассказать? В саппорт прилетают различные вещи и для начала их надо идентифицировать (это бага, это надо инструкцию обновить, это мелкая доработка, это похоже на эпик, это пользователь тупой). И ведь кто-то этим должен заниматься. Таким образом, разработчикам будет уходить только часть этих тикетов. Мало того, порой непонятно бага это или фича и требуется время разработчика, чтобы глубже копнуть. А такие задачи кому уходят? Дежурным? Да и еще — бывают такие тикеты, что без поллитра не обойдешься, нужно еще привлечь бизнес-аналитиков и созвониться с пользователем.
И еще не понятен жизненный цикл feature команды в рамках проектов. Они что сделали проект и свалили (распались)? А кто поддерживать будет?