чего-то я не догоняю...
Вступление.
Подключили меня к проекту, который уже несколько лет разрабатывается (правда денег пока не приносит, но дело не в этом). Разрабатывается он на си-шарпе (как замена очень старому си-2хплюсовому проекту, который еще на 16-ти битах начинался, но до сих пор живет, с кучей клиентов). Этот новый проект (точнее солюшин) состоит где-то из 350 проектов (половина из которых - юнит тесты).
Проекты между собой коммуницируют только через интерфейсы. Т.е. обычно это пара: проект, который содержит только интерфейсы, и проект который их реализует.
И того получается - 350/2/2 = 87 проектов с реальным кодом. Ну а интерфейсов, понятно, гораздо больше. Ну а функций в каждом интерфейсе - от парочки, до пары десятков.
А теперь суть.
Дали мне задание все функции каждого интерфейса сделать асинхронными. Т.е. чтоб каждая функция возвращала Task.
Причем на данном этапе моя работа сводится к рефакторингу, т.е. чтоб поведение программы не поменялось. А делается это созданием каждому интерфейсу еще одного статического класса который имплементирует для каждой функции extensios (ну там где this интерфейса первый аргумент), а имплементация вызывает интрерфейсную функцию (уже возвращающую Task) и тут же Wait() или Result.
Это все, как мне об\яснили руководители проекта - для будущего.
А пока получается, что каждый вызов любой функции интерфейса создает Task, и тут же ждет ее завершение. Т.е. по сути работает как и раньше - синхронно.
Вот этого я и не догоняю - нафига?!
По моему опыту, плодить Задачи (Task) нужно только если действительно приспичит (т.к. многозадачность затрудняет поддержку кода), а не "на всякий случай, для будущего". И мой прогноз, что 99% чего я переделаю так и останется навсегда работать синхронно.
(я кстати уже практически все сделал, благодаря разработанному алгоритму действий поисков - замен регулярными выражениями).
Я даже митинг согнал, где высказал своё "фе", но руководители сказали - даже Майкрософт в интерфейсах работы с файлами предоставляет асинхронные методы!
Даже Майкрософт в интерфейсах работы с файлами предоставляет асинхронные методы
Страное высказывание. Асинхронные методы предоставляются там где надо и возни с ними получается прилично.
Был у меня как то коллега - любитель интерфейсов, мозги выносились на раз от их иерархии. А все из-за того что где то вычитал - интерфейсы это здорово.
Судя по описанному концепту, возится вам с проектом долго и нудно. Никогда бы так не делал.
Один раз попробовал сделать "асинхронную стате машину", через какое то время заработала, но работа зависела от дуновения ветра. В итоге плюнул и оставил один единственный треад в котором все и крутилось. Блин, земля и небо.
Сейчас для больших проектов использую следующий концепт: есть набор изолированных модулей выполняющих связанную группу задач. Модули взаимодействуют через асинхронные сообщения, для логики состояний асинхронная модель преобразуется в синхронную.
Все модули построены по одинаковому принципу, сложная иерархия классов практически не нужна. И интерфейсы и потоки используются только тогда когда действительно требуется.
вот был например такой интерфейс:
interface IExample
{
void Fun1();
bool Fun2();
}
после преределки получаем такое:
interface IExample
{
Task Fun1Async();
Task(bool) Fun2Async(); -- треугольные скобки вокруг bool
}
static class IExampleEx
{
public static void Fun1(this IExample p) { p.Fun1Async().Wait(); }
public static bool Fun2(this IExample p) { return p.Fun2Async().Result; }
}
И такое решение позволяет не менять код, который уже использует IExample, что в принципе - изящно.
Но не смотря на красоту решения, меня оно коробит! Теперь сплошь будут создаваться задачи, может даже в обычном цикле for, будет создаваться на каждой итерации несколько Task-ов, если в цикле интерфейс дергается.
Вся эта возня с переводом всех функций интерфейсов на асинхронный манер нужна шефам, чтобы ни дай бог не заблокировать надолго юзерский-интерфейс. Т.е. там где такая блокировка обнаружится, код будет переделан на использование настоящей асинхронности этих интерфейсов.
Мое замечание, что избежать блокировки юзер-интерфейса можно вообще без переделки всех выше упомянутых СОТЕН интефейсов, а создав Task по конкретному, проблемному юзер-событию, шефы не восприняли.
Я им ради смеха, дабы дурь этой затеи стала виднее, предложил, чтоб сделать "еще лучше", не только все функции интерфейсов сделать асинхронными, а вообще ВСЕ функции, ВСЕХ классов сделать таковыми, включая например оператор [] какой либо коллекции. Но с юмором у немцев туго: они вообще не поняли аналогии моего предложения с ихним.
Но с юмором у немцев туго
Так это еще и Задорнов фиг знает когда рассказывал.
Типа на итальянской границе спрашивают - наркотики есть? Ответ - ой, извините дома забыл. Погранцы ответили, что то типа в следующий раз не забудьте, а то мы план не выполняем.
На германской тут же спросили домашний адрес. 
Винформс что ли?да вроде WPF.
Срочно ищите другую работу при таком подходе ничего хорошего не придвидится.Да это меня туда подключили, т.к. я своему непосредственному шефу (с которым я другие программы поддерживаю) стал канючить что скушновато стало - мало лаж, мало новых фич. Вот он для меня задачку и выклянчил. Но есть надежда, что опомнятся таки упомянутые руководители, т.к. делал все это я в отдельной-экспериментальной ветке, и может она так и сгинет не слившись с основным стволом.
да вроде WPF.
ну это надо умудрится, так фигово написать. Ни разу еще не было под WPF
Но есть надежда, что опомнятся таки упомянутые руководители
не а, у меня никакой надежды. Только когда отладка начнется и локализация. Должны появлятся "случайные" вылеты "конфликта потоков"
А делается это созданием каждому интерфейсу еще одного статического класса который имплементирует для каждой функции extensios (ну там где this интерфейса первый аргумент), а имплементация вызывает интрерфейсную функцию (уже возвращающую Task) и тут же Wait() или Result.
[...]
А пока получается, что каждый вызов любой функции интерфейса создает Task, и тут же ждет ее завершение. Т.е. по сути работает как и раньше - синхронно.
Мне кажется, что это выстрел себе в ногу :) И потом ты будешь долго и упорно выискивать баги.
Мультипоточное приложение должно быть разработано как мультипоточное. Твое же решение не делает программу асинхронной. Только видимость. Очевидно, что работать все будет только до тех пор, пока все эти переделки работают синхронно.
Вот этого я и не догоняю - нафига?!
------
Для ответа, вообще-то, надо знать и понимать саму задачу.
У меня вот висит одна несложная часть - на серваке запускается процесс и генерит файлы.
Файлов - много. Процесс - длительный.
По окончании надо перекачать нужное из сгенеренного на клиента.
Пока написано примитивно - запуск и поолинг. Работает, НО! Не нравится.
А мне бы два асинхронных нотификатора - по каждому файлику и по процессу в общем - было бы много по-проще.
Но пока - не могу.
А так - да, буду переводить на асинхронику...
шефы не восприняли.
-----
Правильно не восприняли.
Я бы тоже не понял, если бы мне предложили поддерживать имплементацию половины бизнес-объектов по одним правилам, а вторую половину - по другим.
Сейчас вот надо переделывать кусок проектов - сразу не вынес в отдельные либы - было непонятно что и как, а сейчас - надо переделывать И чистить старый код.
Много пустой работы. Сейчас - много, но потом - окупится.
сделать "еще лучше"
------
Прямо вчера чинил хорошее.
В функции - свитч на десяток позиций и... формула для того что не попало в свитч.
Сначала думал, что свитч надо загнать в словарик, а по отсутствию - считать.
Но вот ночью в голову стукнуло - а зачем Я это буду делать так сложно и так медленно работающее?
Там ведь все что надо - массив на 40 элементов (знание предметки!) и просчитать его ОДИН раз.
Дальше - чисто индексирование.
Заодно - следующая операция - деление на значение полученного элемента - почему бы ее не
заменить умножением, поделив при инициализации массивa единицу на коэффициент?
Пустяки? Да! Но там это будет считаться по 50 тыс раз на цикл - есть смысл сделать правильно.
вое же решение не делает программу асинхронной. Только видимость.ну да. Именно такая задача передо мной и была поставлена. Это нужно, по словам руководства, чтобы в будущем кому-то (уже не мне) было легче огранизовать асинхронность, если приспичит.
Я сам никакой пользы от моей работы не вижу, а только убытки:
- при многопоточности труднее чего нибудь отлаживать
- старт/завершение/ожидание потока - требует дополнительной производительности
- требования руководства (если приспичит) легко решаются без моей этой работы.
Т.е. ни одного плюса я не узрел. Ну разве что для себя - поучился решать такие глобальные переделки.
Я сам никакой пользы от моей работы не вижу, а только убытки:
- при многопоточности труднее чего нибудь отлаживать
Смотря что ты понимаешь под "трудностью отлаживать". Логику потока отлаживать в многопоточной среде не сильно труднее, чем в однопоточной.
А вот синхронизацию потоков и взаимодействие между потоками - это да, тут все сложно. Впрочем, твое решение ломает как раз синхронизацию и именно с этим придется возиться тому, кто будет разгребать твое "решение".
- старт/завершение/ожидание потока - требует дополнительной производительности
Ничего драматичного.
- требования руководства (если приспичит) легко решаются без моей этой работы.
:) ну твоя работа не делает приложение многопоточным. Это уже выяснили :) Более того, твое решение только портит работающий код (пусть и с блокировкой UI). Мне кажется, что тут в разговоре с
начальством нужно упирать на то, что если уж делать программу многопоточной, то делать надо сразу правильно, а это будет очень долго и дорого.
понимаешь под "трудностью отлаживать". Логику потока отлаживать в многопоточной среде не сильно труднее, чем в однопоточной.понимаю что написал: многопоточность. А не дебагить в одном потоке.
Ничего драматичного.ну в приведенном случае как раз драмматично. Ибо наверняка какой либо интерфейс дергается где нибудь в цикле, при этом каждый раз создается/ждется/убивается поток.
Более того, твое решение только портит работающий код (пусть и с блокировкой UI).дык об этом с самого начала и речь! Причем решение не моё, мне сразу подсказали как делать.
Мне кажется, что тут в разговоре с начальством нужно упирать на то, что если уж делать программу многопоточной, то делать надо сразу правильно.так об этом я на митинге и говорил, на что один из начальников сказал, что не для этого меня временно привлекли к проекту, а если я этим займусь, то мне хватит работы до пенсии.
И я совершенно согласен - хватит, если конечно делать то что они говорят.
А если решать только проблемные места, на чем я настаивал, то это - дни, максимум - недели.
там еще была идея (слава те господи отменили!) не только функции интерфейсов делать асинхронными, но и все проперти - сперва переделать в функции, ну а потом понятно: раз это функции, значит асинхронны.
Ну представьте себе, что например все функции класса string возвращают Task. Вот на подобии такого я и сделал.
Пункт уже закрыт, начальство довольно. Я уже другими делами занят.
Но совесть моя спокойна: если вся эта хрень что пока в отдельной ветке, всё же вольется в транк, - люди знают я был против.
Но совесть моя спокойна: если вся эта хрень что пока в отдельной ветке, всё же вольется в транк, - люди знают я был против.
А не переживайте, по другому здесь низзя.
Я уже давно нигде ни на чем не настаиваю. Сказал, и жду. Через какое то время сами прибегут. Хотя бывает, что и "дурное решение" работает. Клиенту то на внутренности плевать, главное чтобы работало.
Решение то для ПМ очень вкусное, просто тонна автоматической работы, а проект "остается такой какой был". Ну а другому, поручим найти эту долбанную задержку и все - проблема решена.
Что можно еще попробовать сделать - найти того Гуру, который это придумал и поговорить с ним о проблемах. Только если команда новая, будет сложновато, нужно хоть немного знать человека, как с ним разговаривать. Во всяком случае, не говорить, что решение полное Г. А типа, вот я вижу проблемы 1,2,3 как вы планировали их решить?
Сделайте небольшой тест проект. Вначале как было, потом только с требуемыми изменениями, а после чтобы работало как надо. Хотя может в небольшом тесте ничего и не будет видно.