Компания
166,79
рейтинг
15 июня 2010 в 09:33

Разное → Самообман простоты


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


Введение


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

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

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


Я буду исходить не из общих рассуждений, а из личного опыта. Я занимаюсь созданием инструмента для программистов 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 с.: ил.
Автор: @Andrey2008
Intel
рейтинг 166,79

Комментарии (30)

  • +6
    Тот мужык на балконе щекочет самоубийцу?
    • +8
      это грабитель, просто он лез в квартиру — попой к верху… но тут его поймали…
      • +3
        Муж и сосед застукали полосатого любовника?
    • +3
      Это не самоубийца. Мужики кондиционер ремонтируют, а тот на балконе его надежно держит.
      • +5
        Я что-то не вижу на нем ни ремня, ни веревки, так что о надежности тут лучше не говорить. Тот что слева очень потешно держится за свитер, была бы голова держался б за ремень на штанах.
      • 0
        держит и приговаривает полосатому: И все-то ты в трудах, все в трудах, великий государь, аки пчела
  • +1
    А корень всего зла — нежелание (или неспособность) смотреть больше чем на один шаг вперёд, и шире чем на одно дерево посереди леса :)
    • +2
      отчасти это не желание а не умение. Это опять таким совсем не тривиальная задача посмотреть на много шагов вперед, и далеко не все способны это осуществлять.
  • +4
    Как тонко Вы подобрали аватар к топику.
    • +33
      Это в компании Intel проводят тренинг на доверие сотрудников друг к другу
  • +1
    Изложено в приятном стиле, с удовольствием прочитал. Может быть следует в аннотацию добавить упоминание про параллельное программирование, 64 бита и т.д. — на примере чего Вы раскрываете тему статьи?
  • 0
    кажется нужно больше времени уделять сну, или если не его времени то качеству, раз пять перечитывал название топика всё время мерещилось Самообман простАты о_0
    • +1
      Зато как интригующе. :))
      • +3
        И картинка как раз в тему
  • +2
    Замечательная статья. Все очень грамотно написано.
    Сразу вспоминаются времена, когда мы программировали под MPI, пытались предсказать развитие лесных пожаров.
    Пол беды это сделать.
    Нужно еще ехать в Киев и объяснять людям (в институте Кибернетики), какая польза будет от таких программ для их кластера…
    Еще раз спасибо за статью!
  • +2
    Ну в 64 битностью понятно, кто пишет новые программы для 32бит only большие ССЗБ, а тем, кому выпала доля тащить старье просто не повезло. Но вот с распараллеливанием на С++ действительно все не удобно, по мне так в таких случаях лучше использовать какой-нибудь эрланг.
  • +3
    Очень, очень похоже на статью Дейкстры. Впрочем, вижу, что об этом Вы уже написали. :)

    Даже если не программировать на Си++, и не заниматься 64-х битными программами, все равно программирование — это сложно, и дело тут и в людях, и в инструментах.

    Мне кажется, что мы просто еще не доросли до серьезных вещей, а то, что есть сейчас, представляется этаким «каменным веком», иными словами, программированию до серьезной дисциплины еще пилить и пилить.
  • –3
    То что вы описали, это маркетинг чистой воды. Именно так производители систем продают свой товар — переход на 64 облегчит вам жизнь, вы можете пользоваться огромными массивами памяти и параллельными вычислениями. А что пытаетесь доказать вы, 64 это сложно, для параллельных вычислений оно не годится и остальные компании просто врут, а я честный. Так вы свой продукт не продадите :) Почитайте книжки по маркетингу и продажам, потому что создавать продукт и продавать это разные вещи, зачастую очень даже разные.
    • +2
      Не все под словом продать подразумевают впарить.
  • 0
    Посоветуйте, пожалуйста, современную литературу (или статьи) про ловушки 64-битной архитектуры и подводные камни OpenMP.
  • 0
    Вам бы еще раскрыть главный императив программирования от МакКоннела здесь, была бы конфета:)
  • +2
    Ещё, как всегда, разработчики переоценивают свои силы и недооценивают сложность задачи. Менеджмент закладывается, что на этот раз уж точно выпустим вовремя и не делает поправки и так далее по цепочке. В итоге традиционные сдвиги сроков.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Как же я с Вами согласен, особенно по поводу создания проблем на пустом месте и борьбы с ними.
      Участвую в небольшом проекте, так мне уже месяц пытаюсь насильственно продать код с 10ю уровнями вложенности в функциях…
      • +1
        А как вам создание объекта вызовом 7 (семи!) конструкторов (хотя уровня наследования всего 3)? :)
        • 0
          Проблема в том, что таким людям доверяют участвовать в хоть сколько нибудь серьёзных проектах, после чего они (проекты) падают под своим весом.
        • 0
          7 конструкторов — это уже целое конструкторское бюро получается…
          • 0
            Конструкторское бюро по вызову: 7 конструкторов приедут и создадут Ваш объект.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное