Про BinaryFormatter. Что за фигня? Понавтыкали красно-жёлтых плашек - unsecure, obsolete и всё такое:

BinaryFormatter.Serialize Method (System.Runtime.Serialization.Formatters.Binary) | Microsoft Docs

BinaryFormatter security guide | Microsoft Docs

Теперь, чтобы что-то компактно сериализовать, только свою сериализацию через BinaryWriter/Reader писать? Т.е. каждый объкт руками по всем элементарным свойствам в бинарный вид переводить? Ну и, соответственно, вообще весь граф типов в иерархии наследования, если там подобные сериализуемые типы? BinaryFormatter вроде автоматически работал и всё это сам делал? В чём разница тогда - я буду руками в коде всё перебирать, или готовый класс как-то автоматом (через рефлексию?) это сделает?

https://docs.microsoft.com/en-us/dotnet/standard/serializa...

только свою сериализацию через BinaryWriter/Reader писать?

https://docs.microsoft.com/en-us/dotnet/core/compatibility...

Recommended action

• Stop using BinaryFormatter in your code. Instead, consider using JsonSerializer or XmlSerializer.

Это всё не компактно. Если хочешь компактно - только BinaryWriter/Reader остался. Но BinaryWriter/Reader - это руками каждое свойство записывать-считывать. Хочешь на автомате по расставленным атрибутам - пиши свой бинарный сериализатор, или мирись с громоздкостью JSON, XML, YAML и прочих многословных человекочитаемых форматов. Или вности зависимости, добавляя сторонний бинарный сериализатор.

BinaryFormatter делал всё компактно и тоже автоматом, как JsonSerializer or XmlSerializer.

Вот есть у вас граф объектов. Раньше вы либо просто скармливали его BinaryFormatter целиком, либо расставляли атрибуты, чтобы немного кастомизировать - что сериализовать, что нет. BinaryWriter пишет в потоr только элементарные типы и не может пройтись по графу объектов. Либо для всех типов графа пишете свою сериализацию, использую внутри BinaryWriter, либо что-то стороннее.

Это всё не компактно.

ну zip еще есть и другие варианты.

https://developers.google.com/protocol-buffers

Но когда стоит выбор между безопасностью и компактностью, всегда лучше выбрать первое.

Щас глянул один видос на ютубе. Типичная задача для джуниора - добавить поле ввода-сохранения телефона во все слои проекта в информации о пользователе. Там человек рассуждает - сначала идём в хранилище (БД) и смотрим, как хранится информация о пользователе. И нужно при этом посмотреть все триггеры-процедуры, где используется эта информация о пользователе, чтобы ничего не сломалось. А откуда человек, не делавший эту БД, узнает, где и как используется инфа о пользователе? Есть в СУБД функция "найти все места использования этого поля этой таблицы" или что-то подобное, как в IDE?

Далее, нужно добавить где нужно поле с телефоном - в сохранение данных, обновление, чтение, удаления и прочее. Ну и всё то же самое по всем слоям. На фронтэнде идём в джаваскрипт код и тоже всё это правим. На всё - неделя.

Нормальная задача для фуллстек-джуниора?

Мне вообще не понятно, это нормально, что "вот тут надо поле для телефона вбить... вообще, это Петрович за БД отвечает, но он щас занят (уволился, заболел) - давай ты", и то же самое для фронтэнда, хотя тебя брали на бэкэнд?

это нормально,

нет конечно.

Ни один нормальный разработчик, не додумается до решения которое сделал студент/юниор. При этом всё работает совершенно правильно.

А откуда человек, не делавший эту БД, узнает, где и как используется инфа о пользователе? Есть в СУБД функция "найти все места использования этого поля этой таблицы" или что-то подобное, как в IDE?

Вариант первый, самый простой и самый подходящий для джуна - спросить тим лида: "я могу просто добавить поле к таблице CUSTOMER, или мне надо на что-то обратить внимание?" Или ответит или покажет где почитать.

"Что-то подобное как в IDE" у каждой RDBMS своё. Для DB2 есть IBM Data Studio, например. Читать тут: https://www.ibm.com/docs/en/db2-for-zos/12?topic=zos-tools...

Нормальная задача для фуллстек-джуниора?

Абсолютно. Если он это делает в первый раз я ему дам больше времени и буду держать руку на пульсе. Каждый день после дейли спрашивать что успел сделать, что не ясно, какие проблемы.

Мне вообще не понятно, это нормально, что "вот тут надо поле для телефона вбить... вообще, это Петрович за БД отвечает, но он щас занят (уволился, заболел) - давай ты", и то же самое для фронтэнда, хотя тебя брали на бэкэнд

В скраме нет петровичей. Все отвечают за всё, что делает команда. Если команда сама отвечает (меняет) ДБ, то это должен уметь каждый. Кто-то лучше, кто-то хуже. На code review более подкованный в ДБ проверит что наваял джун и поправит/объяснит.

проверит что наваял джун и поправит

никто у нас еще ничего ни за кем не правил, это тогда проще самому всё сделать.

Объяснить почему не проходит ревью можно, но не всегда это помогает.

никто у нас еще ничего ни за кем не правил, это тогда проще самому всё сделать.

Это исключительно ваши проблемы. Проще самому сделать, совершенно верно. Но если ты потратишь время и научишь джуна, то потом он освободит тебя от кучи рутины. Через полгода-год инвестиции времени на объяснения окупятся. Ну и ревью даже после лида стоит делать. Иногда такую фигню забываешь...

Ну и ревью даже после лида стоит делать

совершенно верно, как впрочем и "но если ты потратишь время и научишь джуна".

Речь шла исключительно о правке кода за кем то.

и научишь джуна

-----

Ошибка, однако... в базовой формулировке...

Джуна, до уровня когда он начнет экономить твое время, обучить за полгода нельзя. Его вообще обучить нельзя.

За полгода джун может чему-то обучится... но это весьма затратный процесс и со стороны джуна, и со стотороны лида... обычно со стороны лида достаточно других забот, а джун без руководства и прогресса забрасывает все нафиг уже к концу квартала если не раньше...

Речь шла исключительно о правке кода за кем то.

А как у вас проходит ревью? Просмотрел, увидел ошибку/корявость. Я или просто говорю об этом человеку, если знаю что он просто ошибся. Или правлю и объясняю ему что и почему я исправил если я знаю/думаю что он не понимает что он сделал не так. Ну или правлю в процессе беседы, неважно. Так что правка кода - составная часть ревью

Джуна, до уровня когда он начнет экономить твое время, обучить за полгода нельзя. Его вообще обучить нельзя.

Легко. Просто надо самому уметь думать и учить и думать чему учить. А не кривить лицо "раньше-то солнце теплее, а трава зеленее была".

А как у вас проходит ревью?

Берешь тикет из нужной коробки и смотришь чего там наваяли.

В зависимости от результата или ОК или "звонишь" или пишешь. ОК означает только то, что решение не навредит проекту.

Но вот исправлять - никогда, даже если в комменте буква пропущена. Пока тикет не закрыт - это ветка разработчика и туда никто не лезет.

Легко.

-----

Нее, нельзя.

Было бы можно - не было бы дефицита в ИТ специалистах всех направлений.

Просто берем баласт из желтых домов и лепим ИТ-специалистов - нагрузка бюджет снижается, ВВП растет, занятость повышается и т.п. Ляпота.

Но этого нет - так что - нельзя...

Что можно - можно отслеживать текущий уровень знаний и навыков и направлять внимание и трудозатраты туда, где джун сможет в чем-то продвинуться. Но! Он либо сделает это сам, либо его никто не сможет обучить...

и думать чему учить.

-----

Ну так Я учить - умею. И быстро, и эффективно.

Кто у меня научился - вполне себе работают по специальности.

Вот только смогли научится далеко не все - многие ожидали что Я их научу... и ничему толковому - а именно - самостоятельно учится - не научились.

Как там говорилось:

"Зайца можно научить зажигать спички! Но даже научившись, он не будет знать зачем он это делает..."

Вот так и в любой другой учебе...