Они эффективны, пока ты не начинаешь читать такой код. Разные исключения обрабатываются по-разному и никогда не угадаешь, как очередное исключение будет обработано, пока не прочитаешь код всего стека вызовов методов от контроллера до твоего десятого по счёту метода.
goto тоже по-своему эффективен, пока не начинаешь читать такой код. (Вспомнилось, как последний раз я их использовал как блок, подобный finally. Это было лет 15 назад в Delphi.)
Они и продолжают решать определённые проблемы, например, когда в DI не дописали интерфейс и у нас случился NullReferenceException в методе или ArgumentException в контроллере, если туда это дописали. Это ошибка программиста, которая решается один раз и там больше не должно быть исключения. А пользователь, соответственно, не должен видеть содержимого этого исключения.
Но если нам просто надо провалидировать данные и сообщить пользователю о неверных данных, это подобно использованию топора там, где нужен пинцет.
Я считаю, что исключение - это такое сообщение, текст которого конечный пользователь не должен видеть. Он только для внутреннего использования и в идеале исключение не должно повторяться, если его один раз поправили.
Я о том и говорю, что исключения должны быть только там, где программа даже не должна работать дальше. Если в API вместо положительного числа пришло отрицательное, то это просто ошибка валидации и мы возвращаем BadResult(ModalState). Если же кидать исключение на каждую проверку вместо того, чтобы вернуть сообщение об ошибке и далее тот же BadResult с этим текстом, то ничего хорошего из этого не выйдет.
Это просто примеры, чтобы не перегружать не важными словами и кучей ненужных для этого классов. Каждый волен делать так, как пожелает.
В простых API моно и бросать исключения. Но вложенность до вызова десятка методов один за другим и каждый может выбросить какое-то исключение, часть из которых логируется, часть игнорируется, часть выбрасывается дальше с новым текстом или даже новым типом, код превращается в ад. Читать его очень трудно, понять логику - ещё труднее. А потом пользователи говорят, что нажатие на одну кнопку возвращает осмысленный текст, а на другую похожую - заглушку. Потом оказывается, что одно и то же исключение в одном месте перехватывается и просто логируется где-то на полпути к контроллеру, а в другом - перебрасывается дальше.
Получается, что у каждого такого метода может быть несколько состояний: вернул результат, выбросил ValidationException, выбросил NotFoundException, выбросил FooBarException, и т.д. И каждый надо учесть. У Result зависит от подхода. Можно всегда Ok(result) возвращать, можно разбить на Ok и BadResult, можно сделать больше и вообще на клиенте обрабатывать.
В статье я написал, что try-catch используется, но только там, где это действительно необходимо.
Конечно, middleware на случай непредвиденных ошибок есть. Но всё, что можно предвидеть, уходит в Result. Проблема middleware в том, что он одинаково ловит и "wrong id", которое нужно показать пользователю, и null reference со stack trace, которое не нужно показывать пользователю. В моём коде туда попадает только то, что не должно попадать на глаза пользователю для логирования, отправки уведомления об ошибке и показа пользователю заглушки.
Я искал позиции для Senior .NET developer. Конечно, для разных вакансий всё может сильно отличаться. Я все свои отклики записываю в файл, указывая сайт и статус. Самое забавное, что некоторые компании присылают отказы даже спустя месяцы, хотя могли уже и не заморачиваться.
Без проблем нашёл работу через hh в прошлом году. Что я делал не так? А пару раз в неделю на LinkedIn приходят предложения.
Сначала из-за границы принципиально пробовал искать через LinkedIn, Glassdoor, Indeed и пр. По ощущениям, в среднем было порядка 30-50% ответов, пусть даже с отказом. Было мало интервью или невыполнимые условия. Где-то были задания. Потом задолбался и через 3 недели уже была работа, найденная через hh.
Конечно, обвинить сайты в том, что не получается найти работу, - гораздо проще, чем подойти к поиску работы со всей ответственностью, как к отдельной работе.
Когда занимался автоматизацией, где-то 13 лет назад поступил запрос посчитать возможность автоматизации карьера для автоматического вывоза материала. Т.е. есть водитель и грузовик, который будет загружен конвейером. Всё остальное, от въезда до выезда - без людей. На выезде водитель даже сам забирает распечатанную накладную по грузу. Сделал им коммерческое предложение, но до разработки, к сожалению, не дошло. К сожалению, не знаю, к чему они пришли. Но предложение по автоматизации карьера потом было добавлено в наше КП. Так что удивляет, что сейчас об этом пишут так, будто только сейчас это стало чем-то особенным. Конечно, карьеры разные бывают. Но, тем не менее.
Недавно для себя открыл сценариста Тейлора Шеридана и понял, что можно смотреть не только фильмы определённого режиссёра или платформы, к чему мы уже привыкли, но и сценариста. Это "Йеллоустоун" и все его приквелы, "Король Талсы", "Землевладелец", "Спецназ: Львица" и пр. Он возвращает на экран сильных героев, решающих проблемы, на которых приятно смотреть, за развитием которых интересно наблюдать. У них тоже есть слабости, но не в том виде, в котором показывают последнее время. При том сильные герои - не персонажи комиксов, а живые люди со своими интересными историями. А то, что в "Йеллоустоуне" чуть ли не половина экранного времени уделена красоте природы и обычному ковбойскому быту - особенно радует, позволяя одновременно и расслабиться, и следить за динамичным сюжетом.
Очень зря. "Киностудия" - просто потрясающий, очень смешной сериал о буднях главы студии. Помимо забавного сюжета ещё и очень классно сделан. Особенно порадовал эпизод, в котором пытались снять сцену длинным планом. Сама эта серия была снята длинным планом. Я её даже сразу дважды посмотрел.
Лично я ещё жду продолжения "Основания" и "Укрытия".
Я активно использую Copilot, ChatGPT, Perplexity, ранее использовал Copilot от Bing для обучения. Недавно использовал Claude для создания за 5 минут шаблона веб-страницы, с которым я провозился бы не менее пары дней (идеальный результат с первой попытки). Но я не делаю это бездумно. Я чётко знаю, что мне нужно и для чего, всегда проверяя предложенный результат, обычно ещё что-то дописывая или меняя в решении. Лучше всего ИИ сейчас заменяют поиск, выдавая пример готового решения, и отлично избавляют от рутины: написание тестов, однотипные изменения в коде, json в класс, xml-документация, перевод из одного языка в другой и т.п. В общем, относительно кода, выполняет роль стажёра или совсем начинающего программиста довольно хорошо.
Ничто не мешает сделать с помощью ИИ сайт-визитку, проверить гипотезу, написать небольшую программу для себя. Но если появляется хоть какая-то работа с пользовательскими данными, регистрацией и, тем более, с деньгами, лучше хотя бы консультироваться с опытными программистами, пока не случилось неожиданности, которые знакомы всем не джунам в разработке.
Мне, вот, очень нравится принцип YAGNI (You Aren't Gonna Need It), который я всегда держу в голове, когда выполняю задачи, чтобы не сделать ничего лишнего, что не нужно для решения конкретной задачи (хотя какой-нибудь мелкий рефакторинг всё равно иногда прорывается). Конечно, в код по возможности закладывается что-то на будущее, но не уделяется этому много внимания.
Допустим, я не просто выполнил задачу, а предусмотрел какое-то потенциальное будущее и вместо сдачи задачи вчера сдам её завтра. Но, что если эта функциональность, на которую было потрачено драгоценное время на запуске стартапа, понадобится только через год? А что, если стартап вообще до этого момента не доживёт.
Поэтому стоит выбирать золотую середину между красивой архитектурой с потенциалом и тем, что нужно здесь и сейчас. В общем достаточно писать так, чтобы не было тех. долга и при этом не было написано ничего лишнего.
Сейчас один легаси-проект (.NET Framework 4.8.1) переводим на последнюю версию. Так оттуда столько такого потенциально хорошего архитектурного "добра" уже выпилили, но всё стало только лучше. И это мы только в начале пути.
Max Payne стоит пройти даже в 2025-м. Там множество интересных находок и это была первая игра с прекрасно сделанным bullet-time. А уж какая там подача истории и главная музыкальная тема! Хочу сказать, что в данном случае не нужно смотреть никаких видео. Лучше один раз сыграть.
Много же разных машин уже существует, которые автоматизируют самые разные процессы. Так и здесь сделают подводный дрон, который будет самостоятельно чистить сферы. Уверен. сейчас это уже не проблема. В крайнем случае будет на берегу сидеть клининг-оператор и управлять этим дроном.
Давным-давно где-то нашёл портативный Photoshop на 60МБ, который можно теперь только в режиме совместимости с XP запустить. До сих пор радует, когда раз в несколько месяцев надо какую-нибудь картинку поправить. Прекрасно работает!
Винда же настоятельно просит перейти на 11. Очень не хочется.
В том проекте, где у вас сотни
throw, обязательно будет что-то вродеtry { ...} catch {}, в лучшем случаеtry { ...} catch { logger.Log(); }.Они эффективны, пока ты не начинаешь читать такой код. Разные исключения обрабатываются по-разному и никогда не угадаешь, как очередное исключение будет обработано, пока не прочитаешь код всего стека вызовов методов от контроллера до твоего десятого по счёту метода.
goto тоже по-своему эффективен, пока не начинаешь читать такой код. (Вспомнилось, как последний раз я их использовал как блок, подобный finally. Это было лет 15 назад в Delphi.)
Они и продолжают решать определённые проблемы, например, когда в DI не дописали интерфейс и у нас случился NullReferenceException в методе или ArgumentException в контроллере, если туда это дописали. Это ошибка программиста, которая решается один раз и там больше не должно быть исключения. А пользователь, соответственно, не должен видеть содержимого этого исключения.
Но если нам просто надо провалидировать данные и сообщить пользователю о неверных данных, это подобно использованию топора там, где нужен пинцет.
Я считаю, что исключение - это такое сообщение, текст которого конечный пользователь не должен видеть. Он только для внутреннего использования и в идеале исключение не должно повторяться, если его один раз поправили.
Нет, просто мне лично нравится, когда в один экран влазит больше кода, а пустые строки только там, где я их оставил.
Я о том и говорю, что исключения должны быть только там, где программа даже не должна работать дальше. Если в API вместо положительного числа пришло отрицательное, то это просто ошибка валидации и мы возвращаем BadResult(ModalState). Если же кидать исключение на каждую проверку вместо того, чтобы вернуть сообщение об ошибке и далее тот же BadResult с этим текстом, то ничего хорошего из этого не выйдет.
Это просто примеры, чтобы не перегружать не важными словами и кучей ненужных для этого классов. Каждый волен делать так, как пожелает.
В простых API моно и бросать исключения. Но вложенность до вызова десятка методов один за другим и каждый может выбросить какое-то исключение, часть из которых логируется, часть игнорируется, часть выбрасывается дальше с новым текстом или даже новым типом, код превращается в ад. Читать его очень трудно, понять логику - ещё труднее. А потом пользователи говорят, что нажатие на одну кнопку возвращает осмысленный текст, а на другую похожую - заглушку. Потом оказывается, что одно и то же исключение в одном месте перехватывается и просто логируется где-то на полпути к контроллеру, а в другом - перебрасывается дальше.
Получается, что у каждого такого метода может быть несколько состояний: вернул результат, выбросил ValidationException, выбросил NotFoundException, выбросил FooBarException, и т.д. И каждый надо учесть. У Result зависит от подхода. Можно всегда Ok(result) возвращать, можно разбить на Ok и BadResult, можно сделать больше и вообще на клиенте обрабатывать.
В статье я написал, что try-catch используется, но только там, где это действительно необходимо.
Конечно, middleware на случай непредвиденных ошибок есть. Но всё, что можно предвидеть, уходит в Result. Проблема middleware в том, что он одинаково ловит и "wrong id", которое нужно показать пользователю, и null reference со stack trace, которое не нужно показывать пользователю. В моём коде туда попадает только то, что не должно попадать на глаза пользователю для логирования, отправки уведомления об ошибке и показа пользователю заглушки.
Я искал позиции для Senior .NET developer. Конечно, для разных вакансий всё может сильно отличаться. Я все свои отклики записываю в файл, указывая сайт и статус. Самое забавное, что некоторые компании присылают отказы даже спустя месяцы, хотя могли уже и не заморачиваться.
Без проблем нашёл работу через hh в прошлом году. Что я делал не так? А пару раз в неделю на LinkedIn приходят предложения.
Сначала из-за границы принципиально пробовал искать через LinkedIn, Glassdoor, Indeed и пр. По ощущениям, в среднем было порядка 30-50% ответов, пусть даже с отказом. Было мало интервью или невыполнимые условия. Где-то были задания. Потом задолбался и через 3 недели уже была работа, найденная через hh.
Конечно, обвинить сайты в том, что не получается найти работу, - гораздо проще, чем подойти к поиску работы со всей ответственностью, как к отдельной работе.
Когда занимался автоматизацией, где-то 13 лет назад поступил запрос посчитать возможность автоматизации карьера для автоматического вывоза материала. Т.е. есть водитель и грузовик, который будет загружен конвейером. Всё остальное, от въезда до выезда - без людей. На выезде водитель даже сам забирает распечатанную накладную по грузу. Сделал им коммерческое предложение, но до разработки, к сожалению, не дошло. К сожалению, не знаю, к чему они пришли. Но предложение по автоматизации карьера потом было добавлено в наше КП. Так что удивляет, что сейчас об этом пишут так, будто только сейчас это стало чем-то особенным. Конечно, карьеры разные бывают. Но, тем не менее.
В статье не хватило слов "жирдяи", "дрыщи". Неприятно было читать - не дочитал. Надеюсь, больше не будете писать... используя столь неприятный язык.
Аналогично. Давным-давно добавил RSS (тогда ещё в Google Reader) и с тех пор так и пользуюсь.
Сейчас смотрю обновления в Feedly. Очень удобно в приложении пролистывать всё ненужное, а потом на компе смотреть отфильтрованное.
Недавно для себя открыл сценариста Тейлора Шеридана и понял, что можно смотреть не только фильмы определённого режиссёра или платформы, к чему мы уже привыкли, но и сценариста. Это "Йеллоустоун" и все его приквелы, "Король Талсы", "Землевладелец", "Спецназ: Львица" и пр. Он возвращает на экран сильных героев, решающих проблемы, на которых приятно смотреть, за развитием которых интересно наблюдать. У них тоже есть слабости, но не в том виде, в котором показывают последнее время. При том сильные герои - не персонажи комиксов, а живые люди со своими интересными историями. А то, что в "Йеллоустоуне" чуть ли не половина экранного времени уделена красоте природы и обычному ковбойскому быту - особенно радует, позволяя одновременно и расслабиться, и следить за динамичным сюжетом.
Очень зря. "Киностудия" - просто потрясающий, очень смешной сериал о буднях главы студии. Помимо забавного сюжета ещё и очень классно сделан. Особенно порадовал эпизод, в котором пытались снять сцену длинным планом. Сама эта серия была снята длинным планом. Я её даже сразу дважды посмотрел.
Лично я ещё жду продолжения "Основания" и "Укрытия".
Я активно использую Copilot, ChatGPT, Perplexity, ранее использовал Copilot от Bing для обучения. Недавно использовал Claude для создания за 5 минут шаблона веб-страницы, с которым я провозился бы не менее пары дней (идеальный результат с первой попытки). Но я не делаю это бездумно. Я чётко знаю, что мне нужно и для чего, всегда проверяя предложенный результат, обычно ещё что-то дописывая или меняя в решении. Лучше всего ИИ сейчас заменяют поиск, выдавая пример готового решения, и отлично избавляют от рутины: написание тестов, однотипные изменения в коде, json в класс, xml-документация, перевод из одного языка в другой и т.п. В общем, относительно кода, выполняет роль стажёра или совсем начинающего программиста довольно хорошо.
Ничто не мешает сделать с помощью ИИ сайт-визитку, проверить гипотезу, написать небольшую программу для себя. Но если появляется хоть какая-то работа с пользовательскими данными, регистрацией и, тем более, с деньгами, лучше хотя бы консультироваться с опытными программистами, пока не случилось неожиданности, которые знакомы всем не джунам в разработке.
Мне, вот, очень нравится принцип YAGNI (You Aren't Gonna Need It), который я всегда держу в голове, когда выполняю задачи, чтобы не сделать ничего лишнего, что не нужно для решения конкретной задачи (хотя какой-нибудь мелкий рефакторинг всё равно иногда прорывается). Конечно, в код по возможности закладывается что-то на будущее, но не уделяется этому много внимания.
Допустим, я не просто выполнил задачу, а предусмотрел какое-то потенциальное будущее и вместо сдачи задачи вчера сдам её завтра. Но, что если эта функциональность, на которую было потрачено драгоценное время на запуске стартапа, понадобится только через год? А что, если стартап вообще до этого момента не доживёт.
Поэтому стоит выбирать золотую середину между красивой архитектурой с потенциалом и тем, что нужно здесь и сейчас. В общем достаточно писать так, чтобы не было тех. долга и при этом не было написано ничего лишнего.
Сейчас один легаси-проект (.NET Framework 4.8.1) переводим на последнюю версию. Так оттуда столько такого потенциально хорошего архитектурного "добра" уже выпилили, но всё стало только лучше. И это мы только в начале пути.
Max Payne стоит пройти даже в 2025-м. Там множество интересных находок и это была первая игра с прекрасно сделанным bullet-time. А уж какая там подача истории и главная музыкальная тема!
Хочу сказать, что в данном случае не нужно смотреть никаких видео. Лучше один раз сыграть.
Много же разных машин уже существует, которые автоматизируют самые разные процессы. Так и здесь сделают подводный дрон, который будет самостоятельно чистить сферы. Уверен. сейчас это уже не проблема. В крайнем случае будет на берегу сидеть клининг-оператор и управлять этим дроном.
Давным-давно где-то нашёл портативный Photoshop на 60МБ, который можно теперь только в режиме совместимости с XP запустить. До сих пор радует, когда раз в несколько месяцев надо какую-нибудь картинку поправить. Прекрасно работает!
Винда же настоятельно просит перейти на 11. Очень не хочется.