Как разработчики C# видят использование потоков в своих программах

К написанию этой статьи меня подвигло то, что в последнее время часто приходилось слышать о плохом проектировании программного обеспечения при многопоточной обработке данных. При этом отсутствует аргументация о том, что использование потоков носит негативный характер. Самое интересное в этом то, что такие мнения зачастую не зависят от языка, на котором пишется код.

Программистов, работающих с потоками, можно разделить на три группы. К первой группе принадлежат разработчики, которые максимально избегают потоков, даже в тех случаях, где они необходимы. Возникает вопрос: почему так происходит? По моим предположениям, причина избегания потоков кроется в дороговизне операции создания потоков, и использование их в программе сопряжено с рисками. Оказывается, часть моих рассуждений была верна, но на самом деле ситуацию определяет то, что среди таких разработчиков бытует мнение, что использование в программе потоков - плохой стиль. Другие прогаммисты стараются построить всю работу вокруг Asynchronous Programming Model (APM). Такие специалисты избегают использования тасков в своих программах, потому что работа с тасками требует в некоторой мере перестройки мышления: начать думать не объектами потоков, а объектами тасков. Как только таким разработчикам доводится писать код под, например, .NET 4.5, где таски почти всюду, их это угнетает. Когда иссякает терпение насчет моделей тасков, эти разработчики пишут свои врапперы, которые строятся над тасками, чтобы построить все на синхронном режиме. Интересный факт, что возраст таких разработчиков колеблется от 30 до 35 лет, и они уверены в своем превосходстве, и поэтому всячески избегают "новомодных фич" конкретного языка разработки. Они считают, что все нововведения в языке - это ерунда, так как это можно решить старыми добрыми проверенными способами. С такими программистами спорить бессмысленно, они не воспринимают чужого мнения, считая свое мнение единственным правильным.

Вторая категория разработчиков старается использовать потоки и там, где они действительно нужны, и там, где от них будет вред. Обычно это разработчики-джуниоры, которые только что прочитали о потоках, например, у Троелсена, посмотрели возможности библиотеки Task Parallel Library (TPL) и начинают их использовать где попало, зачастую неправильно. У таких разработчиков есть большая проблема: они зачастую попадают в команду разработки с первой и третьей категорией разработчиков. Если их руководитель попадет к разработчикам с первой категории, то у начинающего программиста отобьют все желание использовать потоки, при этом основная аргументация будет в виде: "это плохо". Со временем это приведет к тому, что сформируется очередной программист, который относится к первой группе. Если руководителем такого начинающего разработчика будет опытный наставник, то большая вероятность, что данный разработчик научится правильно и уместно использовать потоки. Есть еще третий путь, который приходится проходить молодым разработчикам: самостоятельный путь проб и ошибок. Обычно это подразумевает получение глубокой теоретической базы и умение применять эту базу хоть изредка на практике. Человек имеет все необходимые навыки для саморазвития. Большинство специалистов проходят путь самоучек, так как в современном мире работать в команде со специалистами, которые умеют формулировать свои мысли и знают много тонкостей языка, - это достаточно редкое явление. Такие специалисты обычно много "просят" за свой труд, так как таких "гуру" зачастую нанимают для самых сложных задач, с которыми не справляются другие разработчики. Если Вы начинающий разработчик, пожалуй, единственный совет, который могу Вам дать, - это читать побольше литературы и смотреть, что пишут о потоках такие профессионалы, как Эрик Липперт, Джон Скит, Джеффри Рихтер и другие. Вы можете положиться только на самых себя. Вам будут очень редко помогать другие разработчики, которые знают больше, потому что чаще всего такие разработчики будут Вас высмеивать и стараться показывать свое превосходство. Этот факт я заметил на многих русскоязычных форумах по разработке ПО, а также в компаниях, которые разрабатывают такое программное обеспечение и штат разработчиков которых состоит из русскоязычных программистов. Вероятнее всего, это связано с менталитетом нашего народа.

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

Итоги

Бывает сложно общаться с такими специалистами, которые при слове "многопоточность" начинают нести ахинею. У таких людей нет понятия золотой середины, они переходят из одной крайности в другую. Посмотрите в интернете посты по убожеству тасков, по сравнению Reactive Extensions, или наоборот. Или когда начинают оптимизировать выполнения потока, которое иногда доходит к крайности. Почему таким разработчикам сложно комбинировать возможности, например Reactive Extensions и тасков, если это позволяет задача, почему не использовать возможности многопроцессорности ПК для решения математической задачи или такой задачи, которая требует множества времени на выполнение на основании тасков. Это сэкономит время и ресурсы системы. Правильная архитектура системы должна обеспечиваться комбинацией возможных технологий и решений, стараясь соблюдать гармонию между крайностями в использовании инструментов и возможностей для разработки многопоточного приложения. Просто перед тем, как принимать решение, стоит подумать: возможно, решение, предложенное коллегой, не является неправильным. Оно зачастую не совпадет с Вашим решением, но это не значит, что оно неверное. Как разработчики и думающие люди, давайте подходить к решению задач коллективными решениями.