>>235898879 1) Расскажи про CI/CD от начала до конца, весь процесс разработки для абстрактного софта; 2) Расскажи про способы расширения приложения; 3) В чём смысл TDD; 4) Опиши как бы ты решал вопрос с документацией кода на новом проекте; 5) Какие последние технологии юзал? 6) Какую фичу вернули в последней версии кора? 7) Что можешь сказать по поводу кода Azure SDK, приходилось ли тебе его форкать? 8) Расскажи про проблема с сериализаторами, какие фичи приходилось делать? 9) Расскажи про лайфтайм приложения; 10) Какие фрейморки юзал последний раз для всех видов тестов (юниты, е2е, интеграционные, смоук); 11) Интегрировал ли что-то в CI? 12) Твоё отношение к рефакторингу кода...
>>235899011 >>235899115 Расскажите мне, пожалуйста. Я из другой сферы немного, но писал и на шарпе чуть-чуть, и на джаве. Про темплейты классов (дженерики) знаю, как по мне разницы рили нет. Или есть? Обоссыте, но рассказать не забудьте, прошу.
>>235899990 The following are the key differences between C# Generics and C++ templates:
C# generics do not provide the same amount of flexibility as C++ templates. For example, it is not possible to call arithmetic operators in a C# generic class, although it is possible to call user defined operators.
C# does not allow non-type template parameters, such as template C<int i> {}.
C# does not support explicit specialization; that is, a custom implementation of a template for a specific type.
C# does not support partial specialization: a custom implementation for a subset of the type arguments.
C# does not allow the type parameter to be used as the base class for the generic type.
C# does not allow type parameters to have default types.
In C#, a generic type parameter cannot itself be a generic, although constructed types can be used as generics. C++ does allow template parameters.
C++ allows code that might not be valid for all type parameters in the template, which is then checked for the specific type used as the type parameter. C# requires code in a class to be written in such a way that it will work with any type that satisfies the constraints. For example, in C++ it is possible to write a function that uses the arithmetic operators + and - on objects of the type parameter, which will produce an error at the time of instantiation of the template with a type that does not support these operators. C# disallows this; the only language constructs allowed are those that can be deduced from the constraints.
>>235899625 Классные вопросы у тебя, если ты так и ИРЛ собесы проводишь, было б приятно с тобой подискуссировать, наверное. Вот только на 10 вопросе я бы обосрался и пробекал/мекал. Но опять же, я из другой сферы чуть, ни разу не .нетовец. >>235899990-анон, пишу на .Da
>>235900294 Соррян, я наверное не так вопрос задал. Про дженерики и темплейты классов понял, спасибо (обязательно ещё почитаю это раздел доки, давно уже на плюсах и шарпе ниче не писал). Вот на вопрос > Допустим, есть >protocol P { }
>В чем отличие >func foo(i: P) { } >от >func bar<I: P>(i: I) { } Какой тут правильный ответ? Ещё раз сорри за неправильный вопрос в моем первом посту.
>>235899990 Это про внутреннее устройство свифта, а не шарп, и едва ли будет полезно в других сферах. Если в двух словах, то первый случай толще из-за контейнера, медленнее из-за его динамической диспетчеризации и не оптимизируется компилятором, а второй раздувает бинарник
>>235899625 > 11) Интегрировал ли что-то Это про численные методы интегрирования спрашивают? Ну я про метод Монте-Карло че-то вроде помню. Надо будет подробнее почитать, вспомнить.
>>235899625 1. CI/CD - континиос интегрейшн и деливери.Набор инструментов, правил, в принципе, методология разработки (частично), билда, проверки (частично), сред и доставки в среды. Первое - выбор системы контроля версий. Ну тут в принипе почти 100% гит. Второе - выбор методологии, бранч стратегий, тегирования и т.д работы с гитом. Ну опять же, для большинства случаев пойдет упрощенный (или полный гитфлов). Мастер и релиз ветки засекуюрены для пуша, только после код ревью и всяких автоматических чеков (автотесты, коданализаторы и тд.). Оговоренный контракт именования веток (ну там фича. баг ветки) и возможно кастомные таски. Дальше былд пайплайна. Которая будет при пуше билдить, чекать и т.д. Дальше релиз пайплайна. Желательно несколько енвароментов: дев для девелопмента и всякого непроверенного кода, ТСТ - для куа, стейдж/юат - для демо, ну и прод. Релиз пайплайна в иделае должна делать все сама включая деплой артефактов с билд пайплайны, миграцию баз, опционально хелсчеки. На каждый енв свои секюрити чеки, аппруверы там и тд. ПРи релизе ветка тегается.
2. Немного расплывчасто. Ну есть правило, "проектируй так, чтоб ситстема была закрыта для изменений, но открыта для расщирений", ну это тоже словоблудие. Можно микросервисов напилить. Если без, то около ДДД, разделение на слои (дата там, бизнесс, вью) и внутри каждого слоя разделение по ответвенности, или фичепапки или менеджеры, которые будут отвественны за свой как можно более узкий домен. Опять же, всякие абстракции типа фасадов в помощь. НУ или евент дривен.
3. Пишешь тесты, потом код. Как по мне самый тупой, но правильный принцип - на каждый ИФ - тест (но тут это же не ТДД получается). В целом, юнит тесты для девелопера и есть сорт оф самодокументацией. Я больше интеграционные люблю ибо ленив лол.
4. Натравить код анализатор на процент комментов и ревьюрить. Второе важней ибо засрут все автодоками. Можно потом еще в СИ/СД прикрутить автогенерацию вики по коду.
5. Азуровское говно всякое, функции, космос ДБ там. Ну нет кор.
6. Хм. Не знаю. Вернули? Хм. надо подумать, мож и угадаю, но пока в голову не лезет ничего. Декстоп?
7. Азуровские СДК это кусок кала, которые пилят индусы. Заебали со своими покращеннями особенно с блобами. Недавно обновлял для блобов, космоса. Нет, не форкал.
8. О. ну сейчас самая большая проблема - битва нютонсофта с техт.джсон. Я хотел в новом проекте использовать техт.джсон толлько в итоге обосрался ибо на то время те самые азуровские СДК юзали нютонсофт. Проблемы? техт.джсон голый как шлюха, все те фичи, которые в нютонсофте вопринимались как само собой разумеющиеся, тут - бери сука допиливай сам. Ну их такого хоть более менее интересного - десериалайз в разные типы. Работа Джобжектом типа селект поля.
9. Ну смотря какого. .Net MVC, хм. Ну в зависмости от развертки, ИИС роутит на порт, на порте поднимается кестрел,кестрел разруливает всякое там ХТТПшное говно, хм, поднимает МВС, он роутит и замускает мидлвейр пайплайнц. Мидлвейр там как-то тоже сначала свои вшитые екшены ебает, типа роутинга (вот тут могу обосраться), потом кастомные, потом сам екшн дергается, потом опять пост выполнение мидлвейров. Ну еще тут можно за ДИ рассказать и его скопы, наверное.
10. Для юнит и интеграционных (тут, конечно, можно еще поговрить что считать интеграционными) - хюнит, мок и... забыл как называется либа, которая рандомными данными обьекты создает. В комбинации, можно создавать супер драй тесты, но не всегда взлетает. Е2Е - постман лол, можно сказать, что вообще не создавал. Смок - хуй знает, руками?
11. В каком плане? Код анализаторы интегрировал, генерацию опенджейсон спек, хотел автогенерацию вики по докам.
12. Хорошее, конечно же. Это НОРМАЛЬНО, если код надо выделить несколько недель на рефакторинг после полу года работы на проекте, например. Опять же тут роляет изначальная хайлевел архитектура и вообще выбор технологий. Хороший пример: ДБ дривен девелопмент против код дривен, хуй ты ДБ дривен отрефакторишь в короткие строки. А так, в общем, главное для рефактора знать доменные модели и не боятся аджастить код, если видишь несоответсвие.
Фух. Ну второй раз перечитывать свои писанины не буду ибо будет нечестно
>>235901663 Не, эту хуйню в вузе оставь. Под интеграцией в CI я имею в виду настройку воркфлоу CI и добавление интеграционных тестов/код квалити/создание энвайрментов и прочее.
КАК ВЫ ТУТ БЛЯТЬ МОЖЕТЕ ОБСУЖДАТЬ ХУЙНЮ СВОЮ, ПИДОРЫ, КОГДА У НАВАЛЬНОГО НОВЫЕ ДОКАЗАТЕЛЬСТВА ОТРАВЛЕНИЯ ПУТИНЫМ? Пиздец. Вот из-за таких хуесосов власть и держит нас в рукавицах ежовых. Код свой обсуждаете блять. Он же даже не существует, это всё цифры в компьютере блеять.
>>235903389 Политиков много, а я один. Лучше потратить время на карьеру и съебать, когда станет жарко, чем участвовать в бесцельном бурлении говен, которое ни к чему не приведет
>>235902199 1 - судя по тому, что ты написал у тебя после кодревью код улетит и на QAсреду и на прод сразу. Нет описания фикса багов после нахождения в твоём коде в плане процесса. 2 - Напиши стандартные языковые способы расширения кода. Это правильно, которое ты написал из SOLID`а, так что не совсем словоблудие :) Эвент дривен, окей. У тебя есть приложуха, которая инициализирует событие "продукт изменён", твоё приложение это подхватывает и производит какие-то вызовы. Так случилось, что в твой продукт добавили bulk-операции, твои действия. 3 - не, хуйня, смысл TDD в том, чтобы описать в тестах бизнес-логику, а не все IF`ы, а потом написать само приложение, так ты будешь уверен в том, что твой код выполняет бизнес-требования. Как только находится баг, в приложение корректируется не только приложение (вместе с тестами), но и бизнес-требования. Колесо сансары даёт оборот. 4 - Я про XML-документацию или автогенерацию документацию для API 6 - Я спрашивал про последние фичи в EF; 7 - Как решал вопрос с постоянным шатанием СДК от индусов? 10 - AutoFixture/Fake; расскажи почему в приложениях бывает крайне сложно написать нормальные тесты, какие проблемы бывают? 12 - А теперь расскажи нахуя его делать :) Только представь, что перед тобой сидит менеджер.
>>235904161 >Я про XML-документацию или автогенерацию документацию для API Имхо тут можно ответить одним словом: swagger. ну да, есть такая штука как openAPI, а сваггер лишь её реализация. Тут же не о чем больше демагогию разводить?
>>235904528 > Опиши как бы ты решал вопрос с документацией кода на новом проекте; > Имхо тут можно ответить одним словом: swagger. Этого мало для энтерпрайз решения.
>>235898164 (OP) Я не супер спец, просто на шарпе пишу время от времени на протяжении 8 лет, последние 2 года в шарпе тоже. Зависит от фирмы. То есть на одну и ту же зарплату могут спросить:
Как с базой работаешь? Когда EF недостаточно? А с .net core работал? А с azure? Что делал в azure?
либо
Отличие семафора и мьютекса? Как вообще работает семафор? Какие виды локов бывают?
>>235904161 1. Доплняю, после код ревью улетит сразу на КУА или ДЕВ, да. Дальше не улетит ибо КУА тим добавлены в апруверы. На прод в апруварех еще больше ебл, включая менеджера, девопсов, если есть. Смотря какой фикс, если некритичный баг - то вносим с след спринт и стандартой схемой. Если хотфикс, то создается фикс ветка и ее уже гоняют или по полному кругу, или начиная с КУА или даже Стейджа. После того как прод проверен, мержится в мастер назад. Хм, вообще да, надо будет гитфлов перечитать ибо плаваю, да, обычно работал с упрощенной моделью и сам был инициатором, недожал.
2. Хм. Блин. "языковые способы расширения кода". Перегрузки, опциональные параметры, наследование, композиция и агрегация ты об этом? Мои действия - обосраться и ныть шо долго Хм. Балк операции, в смысле несколько продуктов изменены? Хм. Ну по хорошему - новый ивент... Но тогда говно, ан ераширяемость. Тротлить и батчить? Ок, как бы я сделал: новый ивент. Балк апдейт. Внутри есть методы, которые обрабатывают продукты по одному без сохранения, юнит оф ворк сохраняет все сразу в конце. В итоге у нас ряд методов остались без измненений, но мы добавили новый, который их агрегирует и персистит.
3.Это больше к интеграционным, как по мне. У бизнесса требования "шоб продукт покупался", у тебя в коде это размазано на 20 методов, где там какие бизнесстребования в каком уже слишком размыто становиться. Интеграционным дергается общий метод, мокаются всякие медленные и 3рд пати зависимости и тестится. А ТДД, как по мне, этор больше о юнит тестах... Хм. Мож я и не прав.
4. Хм. Ну я тут в замешательстве. ХМЛ доки так-то и мсбилд генерить умеет, только ценности ноль. Можно заюзать тулу, которая из них сделает конфетку (не моню, какая-то джавовская либа), с диаграмамми отношений классво и т.д. в ХТМЛ формате, например. АПИ - ну да, опенапи генерацию прикрутить и атрибутами как можно подробней обмазывать.
6. Не работал последнее время с ЕФ, фромСкл был. ДБ методы может? Помню не хватало.
7. Никак. Запихнул под коврик фасады, оно там себе маринуется. С функциями там не всегда под фасад получается запихнуть кста, так и живем... Но в целом, вот для космоса я написал свой фасад, потиму ЕФшного контекса, базовый рапозиторий, на сонове него типпизированные репы юзаются уже, неплохо получилось кста.
10. С афтофикстурой, очевидно - рандомные данные и рекурсивные, приходится настраивать и в этоге не так и сухо. Фундаментальные проблемы - клмбинаторный взрыв, невозможно все вариации учесть в интеграционных, а юнит тесты, как я више писал оторваны от реальности (и для девелоперов, как по мне). Опять же проблема сконфигурировать все, в интеграционных сделать свой фейковый композишн рут и тд.д. Проблема оторванности от перзистентных стореджей. Но самая борльшая проблема - их лень писать. Настраивать гейты...
12. "С момента старта продукта мы углубились в понимание предментной области и вектора развития продукта. Изначально сверхгибкая и пластичная архитектура позволила нам выпустить текущую итерацию несмотря на изменения в реквайрментах. Дабы не сбивать темп и даже ускорить разработку предлагаю внести изменения в архитектуру дабы теперь огранить алмаз и быть нацеленным тольок на то, что надо клиенту" лол
>>235905467 Сейчас космос через Азур СДК, через самописный фасад. Вот для космоса его и не достаточно, есть ЕФ космос адаптер, но он говно и не позволяет реализовать все прелести НОСКЛ а их и нет В общем ЕФ не стоит применять для сложных запросов, для репортинга. Не надо боятся хранимок, но и не начинать с них.
>А с .net core работал? А с azure? Что делал в azure? Да, да. СИ/СД, юзал их продукты такие как: блоб сторедж, азур сервис бас, ААД, АПИ менеджмент, азур сервис бас, азур фанкшены и т.д.
>либо Тут я обосрался. Главное с этим всем - не проебать где у тебя может быть конкуртность, а дальше по месту гуглить. Обычно сводиться к юзанию тредсейф коллекций и тупого лока.
>>235906870 > Тротлить и батчить? Если расширяемость рассматривается как бизнес-приемущество твоего продукта, то только так, да :( А правильно -это строить нормальную архитектуру сразу xD
> Это больше к интеграционным, как по мне. Не, типы тестов тут вообще не причём. Почитай про TDD и BDD. Главное понимать какие профиты это даёт бизнесу и продукту, а не знание какие кнопочки жать.
> Никак. Интеграционное тестирование + депенденсибот. Бот видит версию, в зависимости от вашей политики обнавления версий создаёт ПР в дев/пререлиз, а в CI запускаются интеграционные тесты для AzureBlobProvider`а. Попробуй, ещё захочешь.
> Но самая борльшая проблема - их лень писать. То, что тебе их лень писать говорит о том, что в твоей команде построены хуёво процессы разработки, а CI/CD-кал. Держу в курсе :)
> Дабы не сбивать темп и даже ускорить разработку предлагаю внести изменения в архитектуру Хуя ты выдал. Чекай вебемку.
>Интеграционное тестирование + депенденсибот. У нас, судя по всему, разные понимания интеграционного. Для меня - интеграционные не должны физически в базу лезть. А иначе, как ты тут это протестишь? Да, депенденсибот есть, но в майкрософте, особенно в азуре, сидят такие классыне спецы, чт ос выходом .Нет 5 я теперь вообще обновляться не могу ибо ебанные азур функции.
>То, что тебе их лень писать говорит о том, что в твоей команде построены хуёво процессы разработки, а CI/CD-кал. Держу в курсе :) Почему? Просто лень...
>Хуя ты выдал. Чекай вебемку. Лол. Ну хуй знает, ты же написал "менеджеру".
>>235908839 > Вердикт В некоторые конторы синьор-помидором я думаю нормально зайдёшь. Тимлидом я бы не взял, у тебя нулевое понимание бизнес-процессов внутри компании (на мой взгляд). В норм. компанию как мидл+ взял бы, если бы ты мне смог про новую хуйню из .NET 5, про солид и всё, что связано с тестированием ответить. Тебе лучше походить по собесам, пообсираться с долбоёбских вопросов, а так на большинство ответов ты ответил нормально. С другой стороны нужно понимать, что такое "сеньор" вообще. Если считать, что сеньор -это специалист, который сможет спроектировать и создать расширяемое, тестируемое и масштабируемое приложение с 0, которое будет проходить все циклы разработки, то имхо ты бы не потянул. Надеюсь, я тебя не обидел, мои имхо.
>>235910018 Спасибо. Не обидел канеш. тем более мы же на харкаче лол. Подскажи что тогда нужно чтоб "спроектировать и создать..." ну и сам ответ на тот вопрос про расширяемое приложение плиз.
>>235910220 > ну и сам ответ на тот вопрос про расширяемое приложение плиз Там вариантов много. Лучшее, что можно сделать -это заложить в архитектуру ивенты для балк операций. Если не заложено, но есть возможность перекрыть код ивента инпроцесс, то перекрываешь и аккумулируешь данные, если их не дохуя и нет требования на мгновенный отклик, если есть требование на отклик, то придётся тротлить это говно. В худшем случае ты переписываешь код основного приложения. Это я не пишу о всяких мидлварах и использовании быстрых хранилищ для аутпроцесс решений. Факторов, влияющих на принятие конкретного решения много, это скорее вопрос на уровне "поррасуждай, что бы ты сделал".
> Подскажи что тогда нужно чтоб "спроектировать и создать..." Понимать, кто твой "клиент" и что он хочет на каждом шаге разработки ПО. Понимать, что хочет разработчик от кода твоего приложения, что хочет бизнес-аналитик, что хочет QA-инженер, что хочет менеджер, что хочет архитектор, что хочет продукт овнер, что хочет твой конечный клиент на рынке и как все эти буквы в IDE превратить в хотелки всех этих людей. Если конкретно: 1) должен понимать, что будет меняться в коде через час, неделю, месяц, год - думать о расширяемости; 2) должен понимать как тестировать полностью твоё приложение и как покрыть его, чтобы любой член команды и бизнес-аналитик мог сказать "там всё работает"; 3) должен понимать как писать приложение так, чтобы оно не упало под х1000 нагрузкой и закладывать возможность его переписать под изменяющиеся нужды, но не писать это говно заранее - правильно выбрать архитектуру; 4) должен полностью понимать CI/CD; 5) должен знать, что такое Agile-разработка; 6) должен уметь проектировать, лол; 7) должен уметь оправдывать ожидание каждого клиента (клиенту - удовлетворение SLA; менеджеру, продукт овнеру - демо; QA-настроенную среду; команде - тесты и документацию и пр.) и всё это говнище ты должен уметь писать; 8) шарить за DevOps.