using System;
public static class Logger
{
public static int Log(Func<int> expression)
{
try
{
int result = expression();
Console.WriteLine($"Result: {result}");
return result;
}
catch (Exception ex)
{
Console.WriteLine($"Error: {ex.Message}");
throw;
}
}
}
public static class Program
{
public static int loggedWorkflow()
{
return Logger.Log(() =>
{
int x = 42;
int y = 43;
int z = x + y;
return z;
});
}
public static void Main(string[] args)
{
int result = loggedWorkflow();
Console.WriteLine($"Final result: {result}");
}
}
Извиняюсь, какой тут чистый код, если вы аннотации типов написать поленились?
А без аннотаций любой динамически типизированный язык убог. Вот и ваши ООП примеры убоги. Это не классы, а скорее словари, которые по имени вернут вам ссылку на переменную неизвестного типа или на функцию, которая вернёт результатом неизвестно что, а может даже и побочных эффектов натворить - по сигнатуре не поймёшь пока не прочитаешь код.
А без микросервисов проблем было бы гораздо меньше
Всё что выходит в сеть умрёт много раз. Я разрабатывал и сопровождал геораспределенную инфо систему, так в логах было 10.000 сетевых сбоев за год типа отказ сети при SQL запросе или web api. Ошибок бизнес логики было гораздо меньше. Очень трудно достичь надёжности в такой системе. А требования к надёжности были высокие.
Интересней прочитать его оригинальный пост из которого и родилась книга. Там хорошо видны корневые причины, а в этой статье за деревьями леса не видно.
Задумаешься прежде чем рефакторить - а надо ли это в данном случае...
Улучшение 1: Разделение ответственности (Separation of Concerns) Стоимость улучшения 1: 20 строк кода Описание: Вынесение логики создания заказа из контроллера в отдельный сервис OrderService позволяет разделить ответственность между классами. Контроллер теперь отвечает только за обработку HTTP-запросов и возврат ответов, а сервис - за бизнес-логику создания заказа. Это делает код более модульным, облегчает тестирование и упрощает внесение изменений в будущем.
Улучшение 2: Внедрение зависимостей (Dependency Injection) Стоимость улучшения 2: 10 строк кода Описание: Зависимости (OrderService, ItemRepository, OrderRepository, NotificationService) теперь внедряются через конструктор, что позволяет легко заменять их на другие реализации и упрощает тестирование. Это делает код более гибким и облегчает внесение изменений в будущем.
Улучшение 3: Обработка ошибок Стоимость улучшения 3: 15 строк кода Описание: Добавлена обработка исключений и логирование ошибок. В случае недостаточного количества товара на складе выбрасывается исключение InsufficientStockException, которое обрабатывается и возвращается соответствующий ответ клиенту. Это делает код более устойчивым к ошибкам и облегчает отладку.
Улучшение 4: Использование распределенных транзакций Стоимость улучшения 4: 10 строк кода Описание: Создание заказа теперь происходит в рамках распределенной транзакции с использованием пакета netsells/laravel-distributed-transactions. Это гарантирует согласованность данных между базами данных товаров и заказов. Если в процессе создания заказа возникнет ошибка, все изменения будут отменены, что предотвратит несогласованность данных.
Улучшение 5: Валидация запроса Стоимость улучшения 5: 5 строк кода Описание: Добавлен класс CreateOrderRequest для валидации входных данных запроса на создание заказа. Это позволяет проверять корректность данных перед их обработкой и возвращать информативные сообщения об ошибках в случае некорректных данных.
Улучшение 6: Логирование Стоимость улучшения 6: 7 строк кода Описание: Добавлено логирование ошибок и предупреждений с помощью фасада Log. Это позволяет отслеживать возникающие проблемы и упрощает отладку и мониторинг приложения.
Итого: Общая стоимость улучшений составляет 67 строк кода. Несмотря на увеличение количества строк кода, эти улучшения делают код более модульным, поддерживаемым, расширяемым и устойчивым к ошибкам. В долгосрочной перспективе это окупится за счет упрощения поддержки и расширения функциональности приложения.
Когда всё это появится в c#?
А то можно и так, наверное
Дуров, верни стену! )))
Пришёл джун и всем по шапке насовал
Зачем это?
Если не скрипт, не прототип и не фронт энд то зачем?
Многоязычность в большой компании на большом проекте это возможно неплохо. Но количество экспертов должно быть больше количества языков )
А экспертов много меньше чем просто программистов
Найдите Россию на сайте Макиты
Сколько будет длиться твой созвон?
Час? Два? Три? Пять?
это sql/linq? )))
1С лидер по запросам с указанной ЗП выше 400.000
как не язык? нужно знать бухучет и проч бизнес?
ну тогда питон тоже в корзинку - там платят явно не за язык, а за знания нейросетей и т.п. а программирование слегка сбоку
Не было вопроса про цвет глаз.
Значит нарисовать мой портрет вы не сможете
Извиняюсь, какой тут чистый код, если вы аннотации типов написать поленились?
А без аннотаций любой динамически типизированный язык убог. Вот и ваши ООП примеры убоги. Это не классы, а скорее словари, которые по имени вернут вам ссылку на переменную неизвестного типа или на функцию, которая вернёт результатом неизвестно что, а может даже и побочных эффектов натворить - по сигнатуре не поймёшь пока не прочитаешь код.
А без микросервисов проблем было бы гораздо меньше
Всё что выходит в сеть умрёт много раз. Я разрабатывал и сопровождал геораспределенную инфо систему, так в логах было 10.000 сетевых сбоев за год типа отказ сети при SQL запросе или web api. Ошибок бизнес логики было гораздо меньше. Очень трудно достичь надёжности в такой системе. А требования к надёжности были высокие.
Да, развитой системы типов и проверки при компиляции не хватает. В тайпскрипт это не очень удобно и писать и отлаживать.
Я за раст и c# , но как-то медленно всё идёт
Вместо макроса try! можно использовать оператор ? для автоматического возврата ошибок
Или даже так
Для лиги душноты:
Это не новинки языка, а библиотеки std
Менеджерам всегда хочется оптимизировать фот
Интересней прочитать его оригинальный пост из которого и родилась книга. Там хорошо видны корневые причины, а в этой статье за деревьями леса не видно.
https://martin.kleppmann.com/2012/10/01/rethinking-caching-in-web-apps.html
Зачем так нервничать?
Кукушка никуда не денется
Это всё интегрировано в ide, в частности visual studio.
Командная строка git нужна очень редко
Ну разве что скриптов писать вроде поиска наиболее много менявшихся файлов
После прочтения статьи я уже не уверен что утром проинициализируется солнце
Вот так код и раздувается в 5-7 раз
Задумаешься прежде чем рефакторить - а надо ли это в данном случае...
Улучшение 1: Разделение ответственности (Separation of Concerns)
Стоимость улучшения 1: 20 строк кода
Описание: Вынесение логики создания заказа из контроллера в отдельный сервис
OrderService
позволяет разделить ответственность между классами. Контроллер теперь отвечает только за обработку HTTP-запросов и возврат ответов, а сервис - за бизнес-логику создания заказа. Это делает код более модульным, облегчает тестирование и упрощает внесение изменений в будущем.Улучшение 2: Внедрение зависимостей (Dependency Injection)
Стоимость улучшения 2: 10 строк кода
Описание: Зависимости (
OrderService
,ItemRepository
,OrderRepository
,NotificationService
) теперь внедряются через конструктор, что позволяет легко заменять их на другие реализации и упрощает тестирование. Это делает код более гибким и облегчает внесение изменений в будущем.Улучшение 3: Обработка ошибок
Стоимость улучшения 3: 15 строк кода
Описание: Добавлена обработка исключений и логирование ошибок. В случае недостаточного количества товара на складе выбрасывается исключение
InsufficientStockException
, которое обрабатывается и возвращается соответствующий ответ клиенту. Это делает код более устойчивым к ошибкам и облегчает отладку.Улучшение 4: Использование распределенных транзакций
Стоимость улучшения 4: 10 строк кода
Описание: Создание заказа теперь происходит в рамках распределенной транзакции с использованием пакета
netsells/laravel-distributed-transactions
. Это гарантирует согласованность данных между базами данных товаров и заказов. Если в процессе создания заказа возникнет ошибка, все изменения будут отменены, что предотвратит несогласованность данных.Улучшение 5: Валидация запроса
Стоимость улучшения 5: 5 строк кода
Описание: Добавлен класс
CreateOrderRequest
для валидации входных данных запроса на создание заказа. Это позволяет проверять корректность данных перед их обработкой и возвращать информативные сообщения об ошибках в случае некорректных данных.Улучшение 6: Логирование
Стоимость улучшения 6: 7 строк кода
Описание: Добавлено логирование ошибок и предупреждений с помощью фасада
Log
. Это позволяет отслеживать возникающие проблемы и упрощает отладку и мониторинг приложения.Итого: Общая стоимость улучшений составляет 67 строк кода. Несмотря на увеличение количества строк кода, эти улучшения делают код более модульным, поддерживаемым, расширяемым и устойчивым к ошибкам. В долгосрочной перспективе это окупится за счет упрощения поддержки и расширения функциональности приложения.