Pull to refresh
0

Самообман простоты

Reading time 7 min
Views 25K

В статье рассматривается проблема превышения сроков создания программ как результат самообмана: будто бы программирование — это просто, и даже еще проще. Создатели новых технологий в области разработки программного обеспечения уверяют, что их технология поможет решить огромное количество проблем и что теперь разработка программного обеспечения становится как никогда простым и быстрым процессом. Но практика неумолима. Вновь и вновь срываются сроки завершения очередного программного проекта.


Введение


Срыв сроков разработки программного обеспечения является привычным явлением в практике создания программных продуктов. Это явление вредно для всех участников процесса, начиная от рядовых разработчиков, вынужденных работать в состоянии аврала, и кончая руководством и заказчиками, вынужденных мириться с отставаниями и дополнительными затратами.

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

Почему я задумался над этими вопросами


Я буду исходить не из общих рассуждений, а из личного опыта. Я занимаюсь созданием инструмента для программистов PVS-Studio. Это статический анализатор Си/Си++ кода для проверки программ, написанных для 64-битых систем или созданных с использованием технологии OpenMP. В таких программах возникает ряд паттернов ошибок, которые, тем не менее, достаточно просто диагностировать анализом исходного кода. Но суть не в этом. Дело в том, что, участвуя в продвижении этих инструментов, я столкнулся с большим сопротивлением, вызванным тем, что использование 64-битных технологий и OpenMP преподносится как крайне простая вещь. В результате этой уверенности возникает необходимость преодолевать огромное сопротивление людей, считающих, что никаких проблем нет и быть не может. Я как бы оказался врагом их спокойному миру. Аналогичная картина, конечно же, наблюдается и с другими технологиями, но в статье я буду говорить о технологии OpenMP и 64-битных программах как о наиболее знакомой мне области.

Убеждение, что все просто, не удивительно. Кругом описывают, как легко вы можете сделать свою программу 64-битной и сразу получить прирост производительности и огромный объем доступной памяти. Описывается, как, используя OpenMP, вы легко превратите свой код в параллельный. Кругом статьи, содержащие тезисы в духе «достаточно перекомпилировать приложение», «простой расстановкой директив OpenMP». И на этом прекрасном празднике жизни я хожу с плакатом, с крупными заголовками статей «20 ловушек переноса Си++ — кода на 64-битную платформу», «32 подводных камня OpenMP при программировании на Си++». При этом я чувствую себя вредным противным старикашкой, который всем недоволен и постоянно на все ворчит. Именно это странное ощущение и сопротивление «евангелистам простоты» и заставило меня задуматься и написать этот текст.

Был момент, когда я обдумывал мысль, что, возможно, на самом деле не прав как раз я. Нужно вместе со всеми говорить как все просто. И что с нашими-то инструментами все просто совсем. Но что-то не так. Возникает противоречие. Я хорошо представляю положение дел, и уверен в существовании трудностей, ожидающих программистов при осваивании параллельных технологий и 64-битных систем с большим объемом памяти. Нет этой простоты. Это обман. А обман вреден. Он вреден мне, как лицу, заинтересованному в продвижении своих инструментов. Он вреден руководителю, который не может корректно спрогнозировать сроки. И, конечно, он вреден программисту, которого ждет разочарование в новых технологиях и сверхурочное время работы. Поэтому я решил остаться на своих позициях и попробую также изменить вашу точку зрения.

Откуда берется сложность


Меня еще можно попробовать убедить, что создание 64-битных программ не так сложно, что ряд программ может быть пересобран для 64-битных систем без исправлений. А ошибки могут быть автоматически найдены и исправлены с использованием разных методик. Хотя и это будет непросто, так как я имею опыт, говорящий о сложности этих процессов и о том, как легко ошибиться в оценке сроков в несколько раз.

Но когда так же преподносится и параллельное программирование, это уже полное несоответствие действительности. Параллельное программирование — комплексная и слишком сложная задача, которая не может быть решена путем простой расстановки директив OpenMP вокруг циклов или использования какой-то библиотеки. Но именно так это и преподносится. Массе разработчиков, которые еще не изучали вопросы создания параллельных алгоритмов, внушают, что задумываться об этом не нужно и положение исправит OpenMP или какая-то другая технология. Из таких статей кажется простым и понятным, как распараллелить любую программу. Но популяризация того, что не под силу читателю самому заранее проделать и проверить, создает только иллюзию понимания. Быть может, она обогащает его словарь и как-то расширяет круг его мышления, но при этом она же создает ненужную иллюзию понимания там, где настоящего понимания и знания нет.

Это не значит, что технология OpenMP или любая другая плоха. Они замечательны. Но нужно понять, что они могут, а чего нет. Не надейтесь легко распараллелить свои существующие программы. Скорее всего, для этого потребуется создание новых алгоритмов и преобразование структур данных и механизмов работы с ними. Простоту внедрения OpenMP в существующий код, следует понимать так, что эта интеграция повлечет меньшее количество изменений, чем использование других технологий. Так технология MPI облегчает построение распределенной системы, по сравнению с реализацией той же функциональности посредством прямой работы с API и сетевыми протоколами. В свою очередь MPI излишне сложна для многоядерных систем с общей памятью и требует существенных изменений в коде. По сравнению с ней, OpenMP действительно крайне легка в интеграции. Но только в сравнении и только в определенном классе задач!

Говорить о простоте параллельного программирования нельзя, несмотря на то, какие технологии используются. Эта область сложна сама по себе. Если хотите убедиться, то попробуйте сами быстро сесть и распараллелить алгоритм сортировки массива, который все писали в школе и институте. Если не получится, то посмотрите параллельную сортировку Бэтчера. Сразу не придумаешь? Не придумаешь. Этот пример сделан для того чтобы показать, какого рода трудности вам следует ожидать даже с привычными алгоритмами, используемыми в ваших программах. Но есть масса других аспектов.

Вы, наверное, используете в своих программах на языке Си++ итераторы в циклах? А вы знаете, что в популярных статьях об OpenMP, когда показывают примеры с распараллеливанием for, вас забывают предупредить, что итераторы в нем использовать нельзя? Индексами должны быть простые типы данных (например, int). То есть, планируя время на переделку алгоритмов, учтите, что вам может потребоваться еще и изменить структуры данных, и методы работы с ними. А все это дополнительное время и усилия. Да, в OpenMP 3.0 появилась возможность работы с итераторами. Статьи до появления OpenMP 3.0 обходили тему их использования. Новые статьи написаны в стиле «стало легче писать программы на OpenMP 3.0, за счет возможности использования итераторов». Да, хорошо, что теперь есть такая возможность. Но теперь представьте, количество нюансов и сложностей, которые существуют, но при этом практически нигде не описаны и с которыми вам придется столкнутся самостоятельно.

Если все сложно, то почему говорят, что просто?


Нет злодеев, которые хотят обмануть вас и внушить вам, что все просто. Но есть различные интересы, которые приводят к взаимному обману. Тот, кто продвигает 64-битные аппаратные платформы и операционные системы, естественно, заинтересован убеждать, что перенести на них ваши приложения крайне просто. Это понятно. Переход на 64-битные системы и так затянулся и если сказать, что есть сложности, это может продлить переход еще на несколько лет.

Производители параллельных систем рекламируют различные программные технологии и библиотеки, убеждая, что все станет параллельным почти само. Те, кто создают эти библиотеки/технологии, стараются убедить программистов, что их библиотека/технология — самая лучшая, так как является самой простой. И тут происходит печальная путаница. Тот факт, что библиотека проста и удобна (например, по моему мнению, OpenMP проста и удобна), вовсе не означает, что и создание параллельных программ тоже просто!

Программисты, прочитав массу статей о том, как все хорошо в 64-битном и параллельном мирах, но не имея еще практики, обманывают руководство и самих себя о сроках. Руководство обманывает клиентов. Да и само руководство любит считать все простым, так как им кажется, что это позволяет экономить на разработчиках. В результате виноватых нет, но все друг друга обманывают.

Выводы


Уже в процессе написания этого текста я нашел замечательную статью Дейкстры «Два взгляда на программирование» [1], которая во многом пересекается по смыслу с этой статьей. Я процитирую небольшой отрывок, который очень хорошо резюмирует все сказанное выше: «В основном это не вина производителей компьютеров, которые желают вести дела так, будто они продают простейшую продукцию; и не вина руководителей программных проектов, которые предпочитают рассматривать деятельность программистов как простой и предсказуемый процесс; и не вина учебных заведений, которые хотели бы подготовить студентов к достижению гарантированного успеха. Это — следствие комфортной иллюзии, что Человек — лишь сложный автомат, иллюзии, которая, подобно наркотику, приносит своим жертвам кажущееся освобождение от бремени ответственности. Признание программирования серьёзным вызовом интеллекту вернуло бы полный вес этой ноши обратно на их плечи».

Но вес ноши не должен стать причиной, по которой следует продолжать держать глаза закрытыми. От этого теряют все. Нужно принять сложность такой, какая она есть.

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

Незаменимыми помощниками в выходе из кругового «обмана простоты» являются замечательные книги Стива Макконнелла «Сколько стоит программный проект» [2] и «Совершенный код» [3]. И, конечно же, культовая книга Фредерика Брукса «Мифический человек-месяц, или как создаются программные комплексы» [4].

Библиографический список

1. Эдсгер Дейкстра. Два взгляда на программирование. URL. http://www.inr.ac.ru/~info21/pdf/dijkstra.pdf
2. Макконнелл С. Сколько стоит программный проект. — М.: «Русская Редакция», СПб.: Питер, 2007. — 297 с.: ил.
3. Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ.- М.: Издательство «Русская редакция», СПб.: Питер, 2007.- 896 с.: ил.
4. Фредерик Брукс. Мифический человеко-месяц или как создаются программные комплексы. — Пер. с англ. — СПб.: Символ-Плюс, 1999, — 304 с.: ил.
Tags:
Hubs:
+65
Comments 30
Comments Comments 30

Articles

Information

Website
www.intel.ru
Registered
Founded
Employees
5,001–10,000 employees
Location
США
Representative
Анастасия Казантаева