Pull to refresh
0
0.1

.NET программист

Send message

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

Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.

Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.

Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.

Плюсов много, да, но не соглашусь, что решение идеально.

Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового ?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).

Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.

Не возвращайте null! Это источник NullReferenceException ... используйте Nullable для значимых типов, применяйте паттерн Null Object.

Скорее всего подразумевалось противопоставление: "НЕ используйте Nullable, а применяйте паттерн Null Object".

Так же в контексте C# хотелось бы оговорки про nullability.

Используйте исключения, а не коды ошибок.

Все чаще встречаю проекты, где тем или иным образом пытаются делать свои решения в стиле растового Result<TResult, TErr> для обработки возможных/ожидаемых ошибок, а исключения - оставлять лишь фатальным, которые ловить сильно выше с целью только залоггировать. Как ни крути, но исключения - это дорогое удовольствие, подход Errors are values идет в массы.

В Rust есть делегирование ошибок (оператор ? и трейт From<T> к нему), что позволяет держать happy path таким же чистым, как с исключениями.

Не нравится - не используйте

Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.

Но тут интересно другое:

грязью облить

почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉

Используя программу Putty и предоставленные IP адрес и пароль, нужно войти на сервер

Как насчет перевода SSH логина на ключи? Вроде и само собой разумеющееся действие, но инструкция претендует на подробность, а о такой важной штуке ни слова.

"есть csv с такими-то столбцами, надо ее загрузить, отфильтровать, перевернуть и выгрузить в json"

Функционал вряд ли будет висеть в воздухе - его надо будет интегрировать в существующую кодовую базу, что резко поднимает сложность задачи для нейронки.

сейчас проще не поручать

Даже в стирильных условиях кому-то придется проверять выхлоп и допиливать при необходимости.

Поэтому как раз проще рассматривать нейронку - как инструмент в руках человека, а не как автономный заменитель человека.

Зачем с ними совмещаться? Добровольно-принудительно мигрировать в сторону ODF.

И огребите неочевидных проблем от чего-то вроде файлов с пробелами в именах.

перед этим обязательно выполним очистку кэша докера через команду:
docker system prune -a

Чтобы наверняка - можно еще винды переустановить Должно быть достаточно:

docker compose build --no-cache

перед стартом, чтобы гарантировано получить полностью новые latest-образы сервисов (или сервиса, передав его имя последним аргументом), которые подтянутся при создании новых контейнеров.

А это уже не проблема или ограничение C#. Если надо - кладите структуру в другую структуру и в Span/stackalloc, язык это позволяет.

нет никакой надобности делать класс "Договор" с методом "Подписать" и другими методами, которые пытаются имитировать действия над договором в реальном мире

Такая необходимость - это работа с требованиями. Гораздо проще жить имея бизнес-слой, который со стороны вызовов будет читаться по буквам требований, а под капотом - осуществлять привязку к технической реальности, вроде схемы БД.

std.stdio.write - шаблонная функция, полагаю, вам намекают на статический полиморфизм. Кстати, в том же C# компилятор умеет делать мономорфизацию для аргументов-типов в дженериках с where T: struct, что позволяет обходиться без боксинга для значимых типов.

Silverlight тут стоит вспомнить тогда уже, как продолжение идеи WPF c XAML-версткой.

1
23 ...

Information

Rating
3,504-th
Registered
Activity

Specialization

Software Developer, Fullstack Developer
Senior
C#
Rust