Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Вебинар: Базовые сценарии интеграции SAST решения в legacy-проект на примере PVS-Studio - 18.04
В статье рассматривается проблема превышения сроков создания программ, как результат самообмана, что программирование это просто, и даже еще проще.
Срыв сроков разработки программного обеспечения является привычным явлением в практике создания программных продуктов. Это явление вредно для всех участников процесса, начиная от рядовых разработчиков, вынужденных работать в состоянии аврала, и кончая руководством и заказчиками, вынужденных мириться с отставаниями и дополнительными затратами.
Причин для такого явления множество, но в этой статье я хочу высказать мнение, что основной причиной является распространенная вера, что разработка программного обеспечения это просто. Сразу подчеркну интересный момент. В целом все понимают, что создание программ - достаточно трудоемкий процесс, но как только дело доходит до обсуждения или презентаций, каждый, преследуя свои интересы, начинает говорить, что все сложности в прошлом и вот теперь-то, используя новую технологию / язык программирования / методологию, все станет легко и просто. Это повторяется вновь и вновь многие годы. В целом же улучшений нет, и сроки по-прежнему срываются. Именно причины этих явлений и их последствия хочется обсудить в этой статье.
Я буду исходить не из общих рассуждений, а из личного опыта. Я занимаюсь созданием статических анализаторов кода Viva64 и VivaMP для проверки программ, написанных для 64-битых систем или созданных с использованием технологии OpenMP. В таких программах возникает ряд паттернов ошибок, которые, тем не менее, достаточно просто выловить анализом исходного кода программ. Но суть не в этом. Дело в том, что, участвуя в продвижении этих инструментов, я столкнулся с большим сопротивлением, вызванным тем, что использование 64-битных технологий и OpenMP преподносится как крайне простая вещь. В результате этой уверенности возникает необходимость преодолевать огромное сопротивление людей, считающих, что никаких проблем нет и быть не может. Я как бы оказался врагом их спокойному миру. Аналогичная картина, конечно же, наблюдается и с другими технологиями, но в статье я буду говорить о технологиях OpenMP и 64-битных программах как о наиболее мне знакомых.
Убеждение, что все просто, не удивительно. Кругом описывают, как легко вы можете сделать свою программу 64-битной и сразу получить прирост производительности и огромный объем доступной памяти. Описывается, как, используя OpenMP, вы легко превратите свой код в параллельный. Кругом статьи, содержащие тезисы в духе "достаточно перекомпилировать приложение", "простой расстановкой директив OpenMP". И на этом прекрасном празднике жизни я хожу с плакатом, с крупными заголовками статей "20 ловушек переноса Си++ - кода на 64-битную платформу", "32 подводных камня OpenMP при программировании на Си++". При этом я чувствую себя вредным противным старикашкой, который всем недоволен и постоянно на все ворчит. Именно это странное ощущение и сопротивление "евангелистам простоты" и заставило меня задуматься.
Возникла мысль, что возможно на самом деле не прав я. Нужно вместе со всеми говорить как все просто. И что с нашими-то инструментами все просто совсем. Так просто, что дальше некуда. Но что-то не так. Возникает противоречие. Я хорошо представляю положение дел и уверен в существовании трудностей, ожидающих программистов при осваивании параллельных технологий и 64-битных систем с большим объемом памяти. Нет этой простоты. Это обман. А обман вреден. Он вреден мне, как лицу, заинтересованному в продвижении своих инструментов. Он вреден руководителю, который не может корректно спрогнозировать сроки. И конечно он вреден программисту, которого ждет разочарование в новых технологиях и сверхурочное время работы. Поэтому я решил остаться на своих позициях и попробую также изменить вашу точку зрения.
Меня еще можно попробовать убедить, что создание 64-битных программ не так сложно, что ряд программ может быть пересобран для 64-битных систем без исправлений. А ошибки могут быть автоматически найдены и исправлены с использованием разных методик. Хотя и это будет не просто, так как я имею опыт, говорящий о сложности этих процессов и о том, как легко ошибиться в оценке сроков в несколько раз.
Но когда так же преподносится и параллельное программирование, это уже вредительство. Это комплексная и слишком сложная задача, которая не может быть решена путем простой расстановки директив OpenMP вокруг циклов или использования какой-то библиотеки. Но именно так это и преподносится. Массе разработчиков, которые еще не изучали вопросы создания параллельных алгоритмов, внушают, что задумываться об этом не нужно и положение исправит OpenMP или какая-то другая технология. Из таких статей кажется простым и понятным, как распараллелить любую программу. Но популяризация того, что не под силу читателю самому заранее проделать и проверить, создает только иллюзию понимания. Быть может, она обогащает его словарь и как-то расширяет круг его мышления, но при этом она же сеет ненужную иллюзию понимания там, где настоящего понимания и знания нет.
Это не значит, что технология OpenMP или любая другая плоха. Они замечательны. Но нужно понять, что они могут, а чего нет. Не надейтесь легко распараллелить свои существующие программы. Скорее всего, для этого потребуется создание новых алгоритмов и преобразование структур данных и механизмов работы с ними. Если хотите убедиться, то попробуйте сами быстро сесть и распараллелить алгоритм сортировки массива, который все писали в школе и институте. Если не получится, то посмотрите параллельную сортировку Бэтчера. Не просто? Конечно, непросто. Этот пример сделан для того, чтобы показать какого рода трудности вам следует ожидать даже с привычными алгоритмами, используемыми в ваших программах. Но этого мало. Вы, наверное, используете в своих программах на языке Си++ итераторы в циклах? А вы знаете, что в популярных статьях об OpenMP, когда показывают примеры с распараллеливанием for, вас забывают предупредить, что итераторы в нем использовать нельзя? Индексами должны быть простые типы данных (например, int). То есть, планируя время на переделку алгоритмов, учтите, что вам может потребоваться еще и изменить структуры данных, и методы работы с ними. А все это дополнительное время и усилия.
Нет злодеев, которые хотят обмануть вас и внушить вам, что все просто. Но есть различные интересы, которые приводят к взаимному обману. Тот, кто продвигает 64-битные аппаратные платформы и операционные системы, естественно, заинтересован убеждать, что перенести на них ваши приложения крайне просто. Это понятно. Переход на 64-битные системы и так затянулся и если сказать, что есть сложности, это может продлить переход еще на несколько лет.
Производители параллельных систем рекламируют различные программные технологии и библиотеки, убеждая, что все станет параллельным почти само. Те, кто создают эти библиотеки/технологии, стараются убедить программистов, что их библиотека/технология - самая лучшая, так как является самой простой. И тут происходит печальная путаница. Тот факт, что библиотека проста и удобна (например, по моему мнению, OpenMP проста и удобна), вовсе не означает, что и создание параллельных программ тоже просто!
Программисты, прочитав массу статей о том, как все хорошо в 64-битном и параллельном мирах, но не имея еще практики, обманывают руководство и самих себя о сроках. Руководство обманывает клиентов. Да и само руководство любит считать все простым, так как им кажется, что это позволяет экономить на разработчиках. В результате виноватых нет, но все друг друга обманывают.
Уже в процессе написания этого текста я наткнулся на замечательную статью Дейкстры "Два взгляда на программирование", которая очень пересекается по смыслу с этой статьей. Я процитирую небольшой отрывок, который очень хорошо резюмирует все сказанное ранее: "В основном это не вина производителей компьютеров, которые желают вести дела так, будто они продают простейшую продукцию; и не вина руководителей программных проектов, которые предпочитают рассматривать деятельность программистов как простой и предсказуемый процесс; и не вина учебных заведений, которые хотели бы подготовить студентов к достижению гарантированного успеха. Это - следствие комфортной иллюзии, что Человек - лишь сложный автомат, иллюзии, которая, подобно наркотику, приносит своим жертвам кажущееся освобождение от бремени ответственности. Признание программирования серьёзным вызовом интеллекту вернуло бы полный вес этой ноши обратно на их плечи".
Но вес ноши не должен стать причиной, по которой следует продолжать держать глаза закрытыми. От этого теряют все. Нужно принять сложность такой, какая она есть.
Выводом из всего этого должен стать более критический взгляд на возможности новейших технологий. Новые средства и методики полезны, но они никогда не могли и, возможно, не смогут заменить сам процесс разработки программного обеспечения, состоящего из множества этапов и элементов. В первую очередь необходимо учиться и совершенствовать процесс разработки, а уже потом выбирать для реализации проекта новые удобные технологии.
Незаменимыми помощниками в выходе из кругового обмана простоты являются такие замечательные книги Стива Макконнелла "Сколько стоит программный проект" и "Совершенный код". И, конечно же, культовая книга Фредерика Брукса "Мифический человек-месяц или как создаются программные комплексы".
Желаю вам скорейшего выздоровления, успехов в оценке сложности программных проектов и завершения их в требуемые сроки!
0
0
0
0