Насчёт перезда, и денег жалко было, и переезжать не хотелось. Для детей и так был огромный стресс засыпать на новом месте.
Тег поставил.
Легаси было на шарпах.
Вот самый дикий кейс, что я там встретил выглядел примерно так
Есть методы. которые забирают что-то с апишки. Внутри них зачем-то вызывается универсальный механизм запроса на дженериках, который возвращает нужный инстанс модели ответа.
Типа такого:
class UserResponse
{
string Name {get; set;}
...
}
Так вот, во время запроса что-то могло пойти не так, и в этом случае этот универсальный механизм создавал инстанс модели ответа через РЕФЛЕКСИЮ. Причём не всегда, несколько видов ошибок он умел обрабатывать, и плеваться исключениями.
Это, конечно, создавало массу проблем. В клиентском коде часто невозможно было отличить валидный ответ от невалидного, классы респонсов не могли иметь конструкторы с параметрами, и я не мог использовать ООП, что бы моделировать возможные типы ответов (есть же не просто валидный и не валидный, валидных типов ответов в нескольких запросах могло быть по пять штук).
Вообще лучший способ понять качество кода, это посмотреть, насколько хорошо в этом коде организована работа с исключительными случаями.
Да, и мы отлично знаем ответ. Нисколько, собеседование — это не работа, и всем совершенно плевать на качество этого процесса. Хотя есть ощущение, что те, кто подходит к делу серьёзнее — ещё опасней
Почитал бы про сравнения с другими ЯПами. Мне вот наиболее простыми и лаконичными кажутся F# и TypeScript, но это из тех, у которых для меня минимально достаточно возможностей
Да, я бы правда рекомендовал всё же картинку какую-нибудь к статье добавить. Не очень приятно, когда люди не читают твою статью просто потому, что не зацепились за неё взглядом
Тег поставил.
Легаси было на шарпах.
Вот самый дикий кейс, что я там встретил выглядел примерно так
Есть методы. которые забирают что-то с апишки. Внутри них зачем-то вызывается универсальный механизм запроса на дженериках, который возвращает нужный инстанс модели ответа.
Типа такого:
Так вот, во время запроса что-то могло пойти не так, и в этом случае этот универсальный механизм создавал инстанс модели ответа через РЕФЛЕКСИЮ. Причём не всегда, несколько видов ошибок он умел обрабатывать, и плеваться исключениями.
Это, конечно, создавало массу проблем. В клиентском коде часто невозможно было отличить валидный ответ от невалидного, классы респонсов не могли иметь конструкторы с параметрами, и я не мог использовать ООП, что бы моделировать возможные типы ответов (есть же не просто валидный и не валидный, валидных типов ответов в нескольких запросах могло быть по пять штук).
Вообще лучший способ понять качество кода, это посмотреть, насколько хорошо в этом коде организована работа с исключительными случаями.