Интересная статья про тенденции в разработке: Статья
Надо только бесплатно зарегистрироваться

Семь проблем программной инженерии
Александр Прозоров

21.11.2005

Автор статьи постарался назвать ключевые проблемы современной программной инженерии своими именами и дать пищу для ума тем, кто отвечает за важные решения, влекущие за собой значительные последствия. А при построении сложных программных или иных технологических систем дело обстоит именно так.
Новояз вместо устоявшейся терминологии
Стремление к смене терминологического базиса, обусловленное заботами о доминировании в конкурентной среде, вылилось в такое повсеместное явление, как брэндирование знаний — создание благозвучного названия продукта либо услуги на основе яркой научной идеи, концепции, метода или технологии. Лейблы-«брэнды» постоянно сменяют друг друга, что создает видимость быстрого развития производителей и предлагаемых ими продуктов. Частая смена наименований и сознательно порождаемая сложность постижения сути идей, концепций и методов, лежащих в их основе, порождает волну потребительского непонимания. А оно необходимо для навязывания пользователям продуктов и технологий путем формирования у них определенных стереотипов.

Решая реальные задачи в области программной инженерии, постоянно приходится сталкиваться с последствиями брэндирования. Так, имеются сообщества, изучающие примерно одни и те же проблемы, но использующие собственную терминологию — Rational Unified Process и Microsoft Solutions Framework. Некоторые теоретические сообщества для скорейшего получения практических результатов стремятся к излишней специализации — в ущерб комплексному исследованию проблем. Этим отличается, к примеру, школа «экстремального программирования». Программы, основанные на теориях разных школ, страдают терминологической и концептуальной несовместимостью. Обучение чаще всего осуществляется партнерами вендоров, цель которых — продать продукт, а не сформировать широкий кругозор на основе тщательного анализа конкурирующих теорий. В процессе обучения формируются классы специалистов, ритуально следующих за отдельным теоретическим течением. Их кругозор определяется границами и структурой теории и поддерживающих ее инструментов.

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

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

создание моды на какие-то конкретные формы, способствующие формированию подсознательной готовности к чему-то более новому и дорогому;
плавная замена термина «успешное решение» термином «продуктивное решение», который переносит успехи внедрения на будущее время, делая их потенциальными;
переход от услуги «решения проблем» к «инструменту, открывающему широкие возможности решения проблем», то есть манипуляция разделением ответственности за результаты использования конкретного решения;
снижение информативности общедоступных материалов о функциях инструментальных средств, ведущее к усложнению «объективного анализа» функциональности.
Количество вместо качества
Удивительно, но качество информационных систем все чаще измеряют численно — мегабайтами, мегагерцами и прочими показателями, напрямую не имеющими отношения к качеству. Целенаправленно отвергнуто диалектическое разделение на качество и количество, в соответствии с которым количество измеряемо и принципиально рационально, а качество измерению не подлежит и имеет иррациональный характер. Сложно не прийти в замешательство от такого рода заявлений: «Новая версия системы стала в два раза качественней только потому, что в нее добавлен новый интерфейс, интегрированный с Microsoft Explorer».

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

Иные «научные» критерии уводят в противоположную от качества сторону. Как-то Джеймс Максвелл сказал: «Наука внушает к себе настолько большое уважение, что самое абсурдное мнение может быть принято, если оно изложено языком, напоминающим какую-нибудь известную научную фразу». Например, можно упомянуть вычисление коэффициента материальной мотивации программиста путем суммирования произведенных им строк кода за единицу времени.

Часто применяются критерии, основанные на высказывании влиятельного или авторитетного лица, например, на заявлении главы известной компании о выходе самой качественной версии очень популярной операционной системы. Имеются критерии, основанные на господствующих в культуре предпочтениях и ограничивающие продукт каким-то конкретным культурным наследием, скажем: «Java — наилучшая платформа систем электронной коммерции».

«Лучшие практики» вместо персонифицированного решения
Самые активные сторонники «лучших практик» зачастую стараются свести разговор о целесообразности того или иного решения к ответам на риторические вопросы: «Ведь это уже работает?» («Да»), «Зачем изобретать велосипед?» («Незачем»). Недосказанность, не до конца изложенные факты не смущают, когда есть вера в абсолютность и чудодейственность шаблонных решений типовых задач. При этом чрезвычайно сложно поколебать чью-то твердую уверенность, ведь для достижения понимания чего-либо человек должен, помимо всего прочего, пытаться слушать.

Можно привести следующие примеры «лучших практик»:

необоснованное применение дорогой корпоративной системы вместо недорогой системы уровня отдела;
использование формального подхода для построения ядра сложной системы, который задает линейную декомпозицию требуемых функций в архитектуру, вместо системного подхода, учитывающего потенциальные изменения функций системы и предъявляемых к ней требований;
необоснованное применение конфигурируемой логики вместо обычной — жесткой, дешевой и быстрой;
необоснованное использование асинхронной коммуникации между модулями вместо более надежной синхронной;
необоснованное применение распределенной архитектуры вместо более простой в реализации и эксплуатации монолитной.
Возможности инструмента вместо условий задачи
Хорошей аналогией высказывания «язык определяет сознание» применительно к программной инженерии является сентенция «инструмент определяет сознание». Многие профессиональные разработчики формируют свой кругозор в рамках методологического инструментария только одного поставщика, призванного решать прикладные задачи строго определенным образом. Показательны рост функциональных возможностей и, главное, снижение сложности использования инструментария для решения типовых задач. Помимо снижения стоимости разработки это косвенным образом ведет к снижению качества программных систем и, следовательно, к повышению стоимости их эксплуатации вследствие роста числа сбоев и ошибок. Такое циклическое сцепление явлений основано на порочном круге: снижается престиж профессии программиста и разрушается цикл преемственности (см. рис.).

Программисты, имеющие значительный опыт и высокую квалификацию, при помощи более легкого в использовании инструментария быстрее решают стоящие перед ними задачи. Сокращение цикла разработки ведет к ускорению карьерного роста опытных разработчиков, а в результате требуются новые программисты взамен ушедших на повышение. Однако базовые навыки снижаются (ведь инструмент стал «дружелюбнее»). Новички находятся в затруднительном положении: как приобрести разносторонний практический опыт, если инструмент этого уже не позволяет (он более специализирован), а на решение задачи отпущено очень мало времени? Формируется спрос на еще более «дружелюбный» инструмент. Многие навыки опытных разработчиков за ненадобностью отмирают, а у новых программистов они так и не успевают сформироваться. Подросшая в статусе, но не в навыках, программистская поросль уходит «наверх», оставляя вакантные места для нового набора, и ситуация повторяется.

Все это приводит к весьма нежелательным последствиям.

Разработчик интерпретирует задачу только в терминах своего инструментария и способен решить ее только в рамках своего понимания, границы которого определяются инструментарием.
Рост простоты использования инструмента ведет к эквивалентному снижению его гибкости. Этот рост осуществляется преимущественно за счет углубления специализации, а не за счет расширения навыков и кругозора разработчика.
Чем больше различие между шаблонным решением из библиотеки инструмента и оптимальным решением задачи, тем больше труда требуется разработчику для борьбы с самим инструментом и его безграмотностью.
Чем меньше навыков у разработчика и сложнее задача борьбы с инструментом, тем менее итоговое решение соответствует оптимальному.
Конвейерный подход вместо руки мастера
Чрезмерное увлечение упрощением задач отмечал еще Эдгстер Дейкстра в предисловии к «Дисциплине программирования»: «Посвятив немало лет своей научной жизни тому, чтобы прояснить задачи программиста и сделать их более подвластными нашему интеллекту, я с удивлением (и раздражением) обнаружил, что мое стремление внести ясность приводит к систематическим обвинениям во ‘внесении трудностей в программирование’. Но эти трудности всегда в нем были, и только сделав их видимыми, мы сможем надеяться, что научимся разрабатывать программы с высокой степенью надежности, а не просто ‘лепить команды’». Трудно сказать лучше.

Давнее стремление уменьшить стоимость создания программного обеспечения за счет снижения требований к разработчикам, которое возможно при облегчении использования инструментов, дает о себе знать. Семена, посеянные в 80-е и 90-е годы, начинают обильно всходить, и это не может не настораживать. Чтобы увидеть эти всходы, достаточно вспомнить о подростках, способных в процессе самоутверждения наносить огромные убытки при помощи нескольких десятков строк кода на макроязыке. Есть несколько причин для беспокойства, связанных с «безальтернативностью» конвейерного подхода к разработке программ.

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

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

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

Эту тему хорошо раскрывает Фредерик Брукс в работе «Мифический человеко-месяц», которой вскоре исполнится 30 лет. Весьма любопытно, что за годы, прошедшие с выхода книги, описываемая в ней ситуация не только не улучшилась, но и значительно ухудшилась. Отгородившись от действительности новомодными теориями и инструментами, руководители программных проектов пребывают в глубоком заблуждении об отсутствии серьезной связи между персоналиями и их рабочими часами. Такие руководители не осознают, что если одному квалифицированному программисту для решения логически сложной задачи требуется 40 часов, то пяти «эквивалентным» разработчикам порой необходимы отнюдь не восемь, а вдвое, а то и втрое больше. Не исключено, что задача и вовсе не будет выполнена, поскольку программисты просто не смогут договориться.

В-четвертых, по мере выхода человека на определенный уровень знаний и опыта у него не только появляются дополнительные возможности решения сложных задач, но и существенно повышается самооценка. Опытные специалисты требовательны как к уровню оплаты своего труда, так и к той атмосфере вовлеченности, которую конвейерный подход с его «уравниловкой» (разработчик — лишь винтик в большом механизме) принципиально не может дать. Следовательно, существенно ослабевают стимулы появления подобных специалистов «внутри», а мотивировать их «извне», кроме денег, банально нечем. Массовость конвейера автоматически подразумевает снижение значения персоналий, что сильно бьет по профессионализму вовлеченных в процесс исполнителей.

Излишняя специализация ИТ-менеджеров
В конечном счете, смысл понятия «специализация» сводится к формированию наиболее полных знаний и навыков в конкретной области в ущерб более широким. Иными словами, специализация предполагает сужение кругозора исследователя с целью более глубокого погружения в предметную область. Как показывает опыт автора, самыми сложными, но наиболее важными функциями менеджера являются верная идентификация проблемы и ее «перевод» в задачу (или ряд взаимосвязанных задач), имеющую конкретное решение. Кроме того, менеджер должен передавать задачи на исполнение подчиненным и контролировать их исполнение. Имея кругозор специалиста, менеджер находится во власти своей предметной области, что мешает ему быть объективным по отношению к проблемам, находящимся вне этой области. Но если проблема идентифицируется лишь в рамках определенной специализации, нет надежды на верный результат: она неизбежно идентифицируется неверно.

Это приводит к следующим последствиям:

управляемое информационное поле становится «лоскутным», появляются «оппортунистические», с точки зрения менеджмента, настроения;
менеджмент способен вести диалог только на своем языке, в рамках своей культурной среды (специальности), игнорируя или отчуждая носителей иных взглядов;
в зависимости от агрессивности менеджмента оппортунистические островки «зачищаются» либо изолируются;
появляется или усиливается текучка кадров;
продвижение по службе осуществляется на основе приверженности индивидуума господствующим взглядам;
игнорируются или, в лучшем случае, неверно интерпретируются проблемы, не входящие в «свою» предметную область, накапливается багаж нерешенных хронических проблем.
Как результат, выстраиваемая менеджментом инфраструктура несет на себе неизгладимые следы господствующих взглядов.

Александр Прозоров (prozoroff@mail.ru) — специалист по стратегии развития ИТ группы компаний «Ист Лайн» (Москва).


--------------------------------------------------------------------------------

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

Растет стоимость программ. Во-первых, она, как правило, значительно выше затрат разработчика. Во-вторых, сами затраты могут быть существенно снижены путем отказа от некоторых «фундаментальных» мифов и применения методик исследования предметных областей (проектирования, разработки и тестирования), «очищенных» от этих мифов. В частности, можно возвратить человека-мастера в процесс решения задачи.

Растет стоимость интеграции. Основной вклад в этот рост дает отсутствие поддержки производителями концепции открытых систем: архитектура многих промышленных систем закрыта, что существенно осложняет интеграцию заказчиками продуктов разных производителей. Отсутствие поддержки открытых систем необходимо поставщикам для навязывания своих решений. Оно легитимируется с помощью мифа о том, что «по-настоящему интегрированные системы возможны только в том случае, если они построены из продуктов одного поставщика».

Растет «тяжеловесность». Для их нормального функционирования все больше необходима поддержка значительного количества вычислительных, технических, людских и иных ресурсов. «Картельный союз» производителей программного обеспечения и аппаратуры вынуждает конечного пользователя тратить все больше средств: ИТ-бюджеты компаний растут гораздо быстрее, чем отдача от выполненных при помощи ИТ бизнес-задач.

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

Растет опасность фатальных ошибок. Снижение надежности программ переходит из разряда негативных факторов в разряд катастрофических. Вероятность ошибки, способной привести к техногенным катастрофам национальных масштабов, не уменьшается. В таких условиях «аутизм» по отношению к качеству программного обеспечения, демонстрируемый многими разработчиками, из разряда халатности переходит в разряд преступных действий.

Да и по-сути мир катится непонятно куда: предположим я захочу написать какое-нибудь серьезное относительно низкоуровневое приложение под наши любимые винды.Ну пусть, предположим, СУБД. Так а на чем его писать. На C# - вряд ли летать будет. 6 вижи прикроют и точно поддерживать не будут.Какие другие компиляторы-не ясно, да и вряд ли будут поддерживаться:дот нет рулит Таким образом, внутрисистемные фичи будут доступны по договоренности с Microsoft Oracl'ам и прочим зубрам...

Остается полу-самопальный Линукс со своим gcc

Прикроют наверняка из-за "небезопасного кода".А то как же дот-нет использовать.

А по поводу ERP - я ничего и не говорю, с ними и так все ясно. СУБД - это не БД: это довольно системная вещь, где все-таки нужны такие вещи как экономия памяти и прочая оптимизация.

ПО поводу устойчивой группы-2 человека - несколько потенциально разных интересов - повод для конфликта

Пример промышленной СУБД на Java, плиз... Быстро работать будет наверняка... Я к тому, что увеличивающееся количество уровней абстракции (промежуточных слоев) в программировании может довести ситуацию до абсурда, а не облегчить разработку как это изначально позиционируется + создаст много искусственных проблем.