Ещё не должны писать production-код те, кто вчера ещё не был программистом и не умеет даже читать код. Сейчас таких пруд пруди. И соответствующего качества поделок.
Новое жильё строится и не распродаётся, а цены при этом не падают почему-то. Вот тут говорят о 30%. Ранее льготная ипотека подняла цены на жильё так, что даже она стала не выгодна. Это мы ещё не берём во внимании проблемы у "Самолёта". Ещё можно учесть самые экономически активные слои населения и куда они "внезапно" делись за последние 4 года. И нам тут же пытаются доказать, что всё хорошо и пузыря нет.
Телемост, который также будет анализировать трафик, как и другие крупные российские приложения? Ну, нафиг. Я сейчас уже плавно перехожу на все иностранные. Благо, их мало осталось и для всех есть аналоги.
2,6 млн лет назад - люди научились использовать огонь.
10 тыс лет назад - люди занялись земледелием.
55 лет назад - первый человек в космосе.
Кажется, цифры говорят сами за себя, но научные исследования всегда лучше, конечно. Ну, и развитие по экспоненте мне нравится. С нетерпением жду технологической сингулярности.
Вновь полюбил писать тексты. Сначала делаю необходимый рефакторинг, затем руками пишу часть текстов, потом прошу LLM написать мне тесты для сервиса (пишу на C#), используя написанные, как шаблон, потом запускаю, вношу косметические правки, обязательно проверяю, что они проверяют все случаи и как надо. Никогда не доверяю слепо LLM.
Стало значительно быстрее и проще. При этом нет такого, что я не понимаю, что там написано. В особо сложных случаях есть другие подходы, также значительно упрощающие жизнь.
Со мной подобное пытались провернуть в феврале 2025. Дали ссылку на GitHub, чтобы я посмотрел код какой-то программы для шахмат, которая типа перспективная, дав доступ на закрытый репозиторий (одно это уже насторожило). Потом попросили скинуть скриншот. Я спросил, какого рода скриншот, на что ответили, что работающей программы. Я сказал, что код посмотрел, но не запускаю незнакомый код у себя на компе. Чувак сразу слился, а потом и вовсе оказался заблокированным.
Радует, что всё это лишь на первых порах так. Со временем, как и в остальных случаях, народ придёт к какому-то решению, правилам и т.д. Примут новую реальность и всё снова будет хорошо, пока не появится что-то новое, популярное.
Купил в этом году себе механические часы с 11-ю бриллиантами. Искусственными - потому они недорогие. Хотя не прочь иметь возможность купить и с 11-ю натуральными.
Мне один коллега уже подсказывал и мне это решение показалось слишком сложным для того, что нам нужно. И не факт, что подошло бы. У нас там целый pipeline в параметрах: несколько команд со своими уникальными параметрами, которые могут повторяться, вызываться в (почти) любом порядке и должны выполняться в итоге по порядку. В общем, ручное решение оказалось очень гибким и легко читаемым. Также чётко указывает на конкретное место ошибки с объяснением.
Можно что угодно использовать в итоге. Главное - парсить параметры сразу и потом уже работать с полученными настройками, а не парсить по ходу дела.
2 Можно создавать объекты руками и передавать их параметрами, но зачем?
3. Новый логер легко использовать в тестах, универсальный, в случае необходимости можно легко поменять библиотеку для логов или добавить дру. Логи стали структурированными.
4. Они все содержат осознанное число строк в зависимости от внутренней логики. Часть из них действительно передаёт ответственность дальше, но это укладывается в логику и помогает лучше понять логику работы сервиса.
12. Да, и я описал, почему и что использую.
14. Конечно, я знаю про JOIN, но не всегда есть возможность это сделать. Например, данные берутся из разных баз. Я хотел показать, что запросы в цикле - это плохо.
16. Сколько записей обработает запрос по неиндексированному полю, чтобы посчитать количество? И сколько для получения первого попавшегося?
До рефакторинга был большой взрыв. Я создал галактики. Чтобы писать сначала тесты, надо хотя бы представлять, как оно всё должно работать. Понимание пришло только после того, как я нарисовал схему взаимодействия всех сервисов.
Если бы там были чистые функции. Там от функционального подхода было лишь использование статических методов повсеместно. Ну, и хотелось предсказуемые для C# тесты написать, а не что-то на стыке. И, всё-таки, не правильно в рамках одной компании делать разные сервисы с очень разными подходами.
Если я пишу какой-то сервис. для API, то я уже знаю о работе DI и что он мне вернёт. Нет смысла придумывать, что там что-то внезапно поменяется и из-за этого засорять конструкторы и тесты кодом, который никогда не будет выполнен и тестирует бесполезные вещи. Это может подойти для библиотеки, но не для класса внутри сервиса с известными параметрами работы. Иначе "на всякий случай" можно и код для .NET Core 3 версии написать, имея сервис на 10-й. Вдруг чего изменится.
Я бы добавил 4-ю: на каждый чих выкидывать исключение вместо возвращения значения.
Например, если DI настроен нормально, то строки типа _imageService = imageService ?? throw new ArgumentNullException(nameof(imageService)); не имеют смысла. Там всегда не null.
А когда исключения лезут в бизнес-логику, то из-за этого обычно код обрастает множеством try-catch на всех уровнях и никогда не знаешь, где именно это исключение будет перехвачено и как обработано. Более того, оно ещё по-разному может обрабатываться в разных местах, что приводит к созданию отдельных исключений и их обработке для какого-то отдельного случая. В одном проекте я со временем удалил с десяток таких одноразовых исключений.
Сейчас один сервис рефакторил. Так там чуть ли не каждый метод обёрнут в исключения, большинство из которых никогда не сработают. Даже вокруг такого кода, который никогда не выбросит исключения.
Если очень надо, а рефакторить такой код дорого, можно сделать PublicException, который будет показывать пользователю ошибку как есть. А всё остальное всё равно должно быть обработано. Желательно в одном месте (ExceptionHandlerMiddleware). Исключение должно сообщать о проблеме в коде/логике, а не быть способом передачи информации.
Тот же необработанный ArgumentException сообщает пользователю название параметра с неверными данными. Зачем это надо? (вопрос риторический)
The Godfather, The Simpsons: Hit & Run.
А вообще, из заголовка ожидал что-то совсем свежее.
Ещё не должны писать production-код те, кто вчера ещё не был программистом и не умеет даже читать код. Сейчас таких пруд пруди. И соответствующего качества поделок.
Новое жильё строится и не распродаётся, а цены при этом не падают почему-то. Вот тут говорят о 30%. Ранее льготная ипотека подняла цены на жильё так, что даже она стала не выгодна. Это мы ещё не берём во внимании проблемы у "Самолёта". Ещё можно учесть самые экономически активные слои населения и куда они "внезапно" делись за последние 4 года. И нам тут же пытаются доказать, что всё хорошо и пузыря нет.
Телемост, который также будет анализировать трафик, как и другие крупные российские приложения? Ну, нафиг. Я сейчас уже плавно перехожу на все иностранные. Благо, их мало осталось и для всех есть аналоги.
5 млн лет назад - появление человека.
2,6 млн лет назад - люди научились использовать огонь.
10 тыс лет назад - люди занялись земледелием.
55 лет назад - первый человек в космосе.
Кажется, цифры говорят сами за себя, но научные исследования всегда лучше, конечно. Ну, и развитие по экспоненте мне нравится. С нетерпением жду технологической сингулярности.
Вновь полюбил писать тексты. Сначала делаю необходимый рефакторинг, затем руками пишу часть текстов, потом прошу LLM написать мне тесты для сервиса (пишу на C#), используя написанные, как шаблон, потом запускаю, вношу косметические правки, обязательно проверяю, что они проверяют все случаи и как надо. Никогда не доверяю слепо LLM.
Стало значительно быстрее и проще. При этом нет такого, что я не понимаю, что там написано. В особо сложных случаях есть другие подходы, также значительно упрощающие жизнь.
Каждый раз, когда слышу про "цвет морской волны", вспоминаю эту статью. Цвет какой именно морской волны?
Со мной подобное пытались провернуть в феврале 2025. Дали ссылку на GitHub, чтобы я посмотрел код какой-то программы для шахмат, которая типа перспективная, дав доступ на закрытый репозиторий (одно это уже насторожило). Потом попросили скинуть скриншот. Я спросил, какого рода скриншот, на что ответили, что работающей программы. Я сказал, что код посмотрел, но не запускаю незнакомый код у себя на компе. Чувак сразу слился, а потом и вовсе оказался заблокированным.
Радует, что всё это лишь на первых порах так. Со временем, как и в остальных случаях, народ придёт к какому-то решению, правилам и т.д. Примут новую реальность и всё снова будет хорошо, пока не появится что-то новое, популярное.
Купил в этом году себе механические часы с 11-ю бриллиантами. Искусственными - потому они недорогие. Хотя не прочь иметь возможность купить и с 11-ю натуральными.
Можно было бы очень быстро избавить все страны от проблемы с незаконными наркотиками. Обжечь все поля, где выращивают - и нет проблемы.
Для этого достаточно выделить ошибку и нажать Ctrl+Enter, чтобы отправить автору личным сообщением.
Мне один коллега уже подсказывал и мне это решение показалось слишком сложным для того, что нам нужно. И не факт, что подошло бы. У нас там целый pipeline в параметрах: несколько команд со своими уникальными параметрами, которые могут повторяться, вызываться в (почти) любом порядке и должны выполняться в итоге по порядку. В общем, ручное решение оказалось очень гибким и легко читаемым. Также чётко указывает на конкретное место ошибки с объяснением.
Можно что угодно использовать в итоге. Главное - парсить параметры сразу и потом уже работать с полученными настройками, а не парсить по ходу дела.
2 Можно создавать объекты руками и передавать их параметрами, но зачем?
3. Новый логер легко использовать в тестах, универсальный, в случае необходимости можно легко поменять библиотеку для логов или добавить дру. Логи стали структурированными.
4. Они все содержат осознанное число строк в зависимости от внутренней логики. Часть из них действительно передаёт ответственность дальше, но это укладывается в логику и помогает лучше понять логику работы сервиса.
12. Да, и я описал, почему и что использую.
14. Конечно, я знаю про JOIN, но не всегда есть возможность это сделать. Например, данные берутся из разных баз. Я хотел показать, что запросы в цикле - это плохо.
16. Сколько записей обработает запрос по неиндексированному полю, чтобы посчитать количество? И сколько для получения первого попавшегося?
До рефакторинга был большой взрыв. Я создал галактики. Чтобы писать сначала тесты, надо хотя бы представлять, как оно всё должно работать. Понимание пришло только после того, как я нарисовал схему взаимодействия всех сервисов.
Если бы там были чистые функции. Там от функционального подхода было лишь использование статических методов повсеместно. Ну, и хотелось предсказуемые для C# тесты написать, а не что-то на стыке. И, всё-таки, не правильно в рамках одной компании делать разные сервисы с очень разными подходами.
Да, верно.
Его не удалить. Он везде. Был, есть и будет.
Если я пишу какой-то сервис. для API, то я уже знаю о работе DI и что он мне вернёт. Нет смысла придумывать, что там что-то внезапно поменяется и из-за этого засорять конструкторы и тесты кодом, который никогда не будет выполнен и тестирует бесполезные вещи. Это может подойти для библиотеки, но не для класса внутри сервиса с известными параметрами работы. Иначе "на всякий случай" можно и код для .NET Core 3 версии написать, имея сервис на 10-й. Вдруг чего изменится.
Я бы добавил 4-ю: на каждый чих выкидывать исключение вместо возвращения значения.
Например, если DI настроен нормально, то строки типа
_imageService = imageService ?? throw new ArgumentNullException(nameof(imageService));не имеют смысла. Там всегда не null.
А когда исключения лезут в бизнес-логику, то из-за этого обычно код обрастает множеством try-catch на всех уровнях и никогда не знаешь, где именно это исключение будет перехвачено и как обработано. Более того, оно ещё по-разному может обрабатываться в разных местах, что приводит к созданию отдельных исключений и их обработке для какого-то отдельного случая. В одном проекте я со временем удалил с десяток таких одноразовых исключений.
Сейчас один сервис рефакторил. Так там чуть ли не каждый метод обёрнут в исключения, большинство из которых никогда не сработают. Даже вокруг такого кода, который никогда не выбросит исключения.
Если очень надо, а рефакторить такой код дорого, можно сделать PublicException, который будет показывать пользователю ошибку как есть. А всё остальное всё равно должно быть обработано. Желательно в одном месте (
ExceptionHandlerMiddleware). Исключение должно сообщать о проблеме в коде/логике, а не быть способом передачи информации.Тот же необработанный ArgumentException сообщает пользователю название параметра с неверными данными. Зачем это надо? (вопрос риторический)