Моспан.txt

Те же самые ООП, генерики, синхронные методы, в целом что нужно знать, чтобы начать что-то делать уже, скажем так, осознанно.
То есть в целом, после курсов уже пришло понимание, чем я занимаюсь и к какому результату я должен стремиться.
То есть чему должны соответствовать программные обеспечения, которые я разрабатываю.
В университете такого понимания не дал?
В университете у меня специальность немножко другая была, там больше как инженерия прикладная что-ли.
То есть там больше как по специальности, по первой то, что я в университете выучился, это именно инженер оптической связи и мобильной связи.
То есть там к разработке вообще не было никакого отношения.
Хорошо, и после курсов вы уже открыли себе неткор, правильно я понимаю?
После курсов, ну получается да, в целом дотнет, то есть на неткоре я ничего не писал.
На дотнете пятом был как раз проект, на который я успел заскочить для республики Мордовии, для агропромышленного комплекса.
Это то, чем я занимался последние 2-3 месяца.
Как бы там разработчика на другой проект кинули, а мне досталось его уже доводить до ума.
Какой там был полный стек?
Ну смотрите, у нас мы писали конкретно на бэке, я писал, дописывал на шарпе на дотнете пятом.
Просто фреймер или дотнет?
Нет, просто дотнет.
Что значит просто? Дотнеткор же получается.
Насколько я знаю, дотнет это уже как бы объединение фреймворка и коров в целом.
То есть после фреймворка был дотнеткор, это попытка в кроссплатформенности.
А после уже всего этого просто дотнет4, там нет никаких слов кор, дотнет5, там нет никаких коров.
В чем его разница между кором тогда и фреймворком?
Фреймворк он нацелен на разработку по Windows, дотнетфреймворк.
Дотнеткор собственно был разработан для того, чтобы осуществлять кроссплатформенную разработку,
чтобы можно было писать в одной и той же среде и использовать ее и на линуксах условно, и на винде.
А дотнет это в целом, я бы сказал, проапгрейженная версия кора.
Я конечно всех плюшек еще не успел познать, но мое понимание как бы вот в этом.
Хорошо, что с базами данных было на проекте, с чем работали?
На проекте у нас Postgres был, собственно.
В качестве ORM?
В качестве ORM, с datagrid.
Ходил здесь иммигратор?
Нет, нет.
Да, Entity Framework приходилось использовать, как и на учебном проекте до Мордовии.
На самой Мордовии довольно полезная вещь, то есть раньше двое.
До того, как я узнал о ней, я думал, что все это ручками создается, условно, модели иммиграции.
Когда узнал, для меня жизнь стала совершенно по-другому.
В общем, да, с Entity Framework работал.
То есть есть знание, понимание того, как это работает.
Делал, пользовался и Fluent API, и атрибутами сразу в моделях.
То есть и тот, и тот подход мне знаком, более-менее им пользовался.
Даже, в принципе, пользовался навигацией.
Это еще, скажем так, не скажу, что это прямо по щелчку, но, в принципе, я пользовался этим.
Уже более-менее знаю, что это.
Как же со скриптами?
Со скриптами?
Эскюэрными.
Иммиграционные скрипты приходилось когда-нибудь?
Нет, нет.
Этого не приходилось.
В целом, написать какой-то объемный запрос, и чтобы он встретился по расписанию,
это был не один опыт, но это еще в моменте до.
Что такое джойны, знаете?
Какие они бывают?
Да, джойны знаю, но использовал их на Мордовии только единожды.
Left, right джойны и inner join.
На кругах проще будет описать, но в целом, да, знаком, но не скажу, что я часто пользовался.
Если будет поставленная задача, просто мне нужно будет минут на пять больше,
разложить себе говню непонятно, здесь он мне нужен, здесь не нужен,
либо здесь мне такой тип нужен, и так далее.
С индексами были связаны, знаете, для чего они нужны, какие они бывают?
С индексами теоретическую часть я в принципе владею, для чего они нужны,
какие они бывают, их там на самом деле огромное количество,
не все вам расскажу, если спросите, но основные, допустим, да.
Опять же такие, когда создавались модели, то ручками указывал,
по каким полям нужно будет индексировать ту или иную таблицу.
То есть это при помощи атрибутов.
Ну вот на этом пока что работа заканчивалась.
В остальном мне достался проект, который, как я уже говорил, был сделан, процентов на 80.
Хорошо, что еще почерпнуть для себя из этого, как с тестами?
Получается, по большей части приходилось работать сильно с интеграционными тестами,
потому что я писал методы, которые должны были взаимодействовать с базой данных,
просчитывать метеоотклонения, обратно их вложить, сформировать push уведомления,
если вдруг случилось какое-то отклонение и пользователю нужно об этом уведомить,
ну владельцу поля.
Поэтому как бы юнит тестирования тоже.
И пользовался библиотекой Fluent, сейчас забыл, Fluent Assertion.
То есть довольно-таки удобная библиотека, накатывал при необходимости,
ну допустим, в качестве тестов HTTP-вопросы тоже можно было тестировать.
Это дополнительная библиотека, я в качестве саморазвития тестировал,
чтобы проверять там коды ответа, какие мне приходят, ответ какой-то это или нет.
То есть, насколько я помню, Fluent Assertion из коробки вот самой дефолтной не умеет с этим работать.
Там еще дополнительная библиотека.
С вот этим вот набором, да, я знаком, применял.
Так, хорошо.
Что с Докером, что?
Приходилось ли заставка?
Да, да, с Докером приходилось сталкиваться, но вот на таком базовом уровне,
который, то есть сам Докер установить, развернуть контейнеры в нем,
там установить, ну тот же самый, развернуть Postgres, Redis,
то есть вот на таком уровне, то есть скормить образ, он развернулся,
все, то есть через командную строку и по, пока что не более.
Понятно.
И по работе в команде, как она у вас складывалась, где она у вас?
Проверял ли кто-то наш код вообще?
Так, по поводу работы с командой, у нас, ну вообще, менеджер,
мы отчитывались перед ним, у нас каждый день был дели,
мы все на этом деле рассказывали о том, что мы проделали,
что у нас в планах, в рамках этого же дели, если было какое-то взаимодействие,
ну условно, вот с Майосом, мобильщиками и так далее,
для этого я написал фронт, то мы обсуждали, кто чем займется,
что кому нужно, задачи мы, собственно говоря, ввели в джири,
то есть опыт с этим есть, как взаимодействие в джири.
Так, я еще какой-то вопрос выпустил, не ответил.
Код ревью?
А, код ревью, вот. По поводу код ревью здесь немножечко сложнее,
то есть на момент, когда я пришел, был всего лишь один беконтрразработчик,
который ушел на другой проект.
Поэтому зачастую код ревью не было, то есть я был предоставлен там себе
и это своего рода подтягивало писать правильно и вдумываться не один, а раз пять,
а точно ли это должно работать так, как есть.
Но, тем не менее, на какие-то сложные сегменты код ревью был,
то есть специалист, опять же, тот, кто был в контексте,
он выделял сложный час и проверял, да, так, либо можно что-то активизировать.
В частности, вот, запросы в базу данных, они очень сложные были для меня.
И вот через линкию, всю вот эту вот группировку, как раз-таки джойны, выборки,
это нужно было очень, скажем так, правильно и оптимизированно написать.
То есть, поэтому вот эту часть, да, это она и явилась.
Давайте возьмем такую ситуацию, когда нужно получить все нужные объекты.
Ну, объект и чтобы у него была вложенность, чтобы мы могли не просто поидишки его получать на фронт,
на шрам АКПИ, но и получать всю вложенную структуру.
А это мы говорим сейчас про явные ревнивые загрузки, жадные загрузки.
Тут, опять же-таки, зависит все от ситуации.
То есть, мы можем при помощи слова include вытащить все вложенные объекты, которые нам нужны.
Единственное, нам нужно понимать, когда они нам нужны, нужны ли они полностью,
либо в их конкретной части.
Вот, из этого.
К такому использованию я прибегал только один раз, на той же Мордовии.
То есть, когда мне нужен был объект целиком, именно в момент запроса ВД и вот прямо здесь и сейчас.
Ну, а также вопрос у меня по классическому построению реставра и архитектуры приложения.
Как вы строите приложения? С чего они состоят?
Вот, по архитектуре, к сожалению, я могу вам описать, как было на Мордовии.
Самого опыта в архитектуре еще нет.
Я не говорю об архитектуре построения системы, а именно рабочих репетиториях.
Как это происходило у вас?
Ну, например, отдельный проект под сервисы, под контроллеры.
Так, кажется, я вас понял.
Ну, у нас было несколько слоев, допустим, бизнес лоджик леер, бизнес лоджик леер абстракции,
где у нас лежали все условные интерфейсы, дата аксесс леер.
Все это было раскидано по разным.
Это внутри одного проекта, получается, было.
Но по разным слоям.
На какие слои вы можете выделить любой проект, арестованный?
Ну, получается, у нас...
Я вскользь коснулся пока что только...
Ну вот, мы выявили, что есть бизнес лоджик леер.
Что в него войдет?
В него войдет как раз таки, условно, сервисы, к которым обратятся контроллеры.
Контроллеры можно представить, условно, луково.
В архитектуру лука контроллеры – это у нас самая внешняя часть.
Чуть глубже это у нас будут сервисы, где будет именно логика обработки.
Ну, если это банковская система, то там будут какие-то формулы просчета и все, и не более.
Еще глубже это будет у нас свой репозиторий, в который должен уже дата аксесс леер.
Тот, который будет ходить только в базу данных и все.
Он больше ничего не знает.
Его задача – вот сходить в базу данных и отдать то, что попросили.
Как бы, ну, вот это такая самая...
Самое базовое понимание моего, что ли.
Все?
Ну вот, пока что да.
В архитектурных вопросах я пока что больше не могу сказать.
Какое число работает с базой данных?
Еще раз.
С базой данных каком число будет работать?
Ну, с базой данных дата аксесс леер.
Должен быть только данный.
Будете ли выделять для этого отдельный сервис?
Ну, проект.
Сложно сказать.
Не могу вам сказать.
Скорее всего, да.
Если мы говорим о идеальной модели, так называемом,
сферическом корневакууме, то да.
А тут уже все упирается в есть ли смысл.
Есть ли смысл в этом.
Если у меня, условно, это будет раз в неделю один запрос,
получить пять сотрудников, не вижу смысла в этом.
То есть тут опять же все упирается в задачу,
в объем данных, который будет использоваться,
и в количестве клиентов, которые будут обращаться к этому.
В репозиторию, назовем его так.
Хорошо.
Это чисто мои мысли.
Я, в принципе, с ними согласен.
В принципе, Алексей, у меня больше вопросов нет.
У меня все понятно, по большому счету.
И я готов ответить на ваши вопросы и немного вам рассказать о проекте.
У нас проект разрабатывается на пятом дотнете.
На фронте у нас ангуляр.
База данных у нас Postgres.
Мы пишем винит-тесты под каждый наш сервис.
И так как мы живем, так как наша система уже разрабатывается
и выключена в Prod, и мы разрабатываем новый функционал,
фиксируем баги на старом функционале,
у нас есть четкая система построения миграций,
когда мы в каждой измене в базе данных фиксируем SQL скриптом
или вытаскиваем данные с помощью даппера,
и там тоже приходится писать SQL скрипты.
И, в принципе, весь смысл нашего проекта – это ведение стройки.
Приходилось ли вам сталкиваться когда-нибудь с проектом?
От Microsoft тоже, если нет?
Нет.
Честно скажу, что нет.
Довольно простая иерархия древовидная.
Из работ, которые необходимо выполнить на скважине для бурения.
И справа наименование этих работ отображается диаграмма Ганта.
Знаете, что такое диаграмма Ганта?
Тоже нет.
Обязательно посмотрите.
Вот, и диаграмма Ганта демонстрирует собой продолжительность работ по каждой операции
относительно дней в календаре.
То есть, к примеру, наша операция длится 10 дней,
это значит, что на календаре мы увидим колбасу в 10 дней, которая будет занимать.
И наша задача – это ввести такую древовидную структуру
и давать дополнительную функциональную пользу для удобства заполнения этих работ
и коммуникации между заказчиком и подрядчиком.
Абстрактно понятно, как бы, суть.
У нас есть, на всякий случай, все необходимые документации,
и я всегда на связи, поэтому я не думаю, что у вас есть проблемы.
Да, да, будет полезно.
Не осталось вопросов?
Ну, в целом, я могу только разве что спросить,
как у вас устроены рабочие процессы и взаимодействия команды.
Бэк, фронт, кто как, через что передаются задачи.
В целом, вот, взаимодействие.
Первоначальным постановщиком для разработчиков всегда являюсь я,
и я являюсь же коммуникатором между ними.
Для того, чтобы обсуждать, что именно потребуется, какие поинты,
как все будет проходить через меня.
Мы все ведем в жире, вся наша работа устроена на ней.
В целом, понятно.
А вот, как я говорил, аналог ежедневной, 10-15 минут,
что-то подобное есть?
Оно есть, но на данный момент не проводится.
Пока что нет необходимости.
Ну, в принципе, в целом, мне, как я сказал, абстрактно понятна задача,
то есть чем вы занимаетесь.
Документацию почитать станет более подробно.
Понятно.
Процесс работы в команде тоже понятно.
Никаких впечатлений я тут не вижу.
И сложностей тоже.
Все, коллеги, предлагаю заканчивать.
Все, больше нет никого, вопросов.